Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 3 Dec 2019 13:57:17 +0000
From:   Mark Brown <broonie@kernel.org>
To:     Brent Lu <brent.lu@intel.com>
Cc:     alsa-devel@alsa-project.org,
        Support Opensource <support.opensource@diasemi.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Jaroslav Kysela <perex@perex.cz>,
        Takashi Iwai <tiwai@suse.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: da7219: remove SRM lock check retry
Message-ID: <20191203135717.GH1998@sirena.org.uk>
References: <1575358265-17905-1-git-send-email-brent.lu@intel.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="jRdC2OsRnuV8iIl8"
Content-Disposition: inline
In-Reply-To: <1575358265-17905-1-git-send-email-brent.lu@intel.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


--jRdC2OsRnuV8iIl8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Dec 03, 2019 at 03:31:05PM +0800, Brent Lu wrote:

> For platforms not able to provide WCLK in the PREPARED runtime state, it
> takes 400ms for codec driver to print the message "SRM failed to lock" in
> the da7219_dai_event() function which is called when DAPM widgets are
> powering up. The latency penalty to audio input/output is too much so the
> retry (8 times) and delay (50ms each retry) are removed.

> Another reason is current Cold output latency requirement in Android CDD is
> 500ms but will be reduced to 200ms for 2021 platforms. With the 400ms
> latency it would be difficult to pass the Android CTS test.

Adam pointed out some specific problems this causes here but at a
higher level this commit message isn't great since it just says
"I don't like these delays so I made them shorter" which doesn't
really explain what the delays are doing or why it's OK to make
them shorter - there are plenty of audio devices which require
longer ramp times than people would like out there but there's
usually good solid reasons why the delays have to be there.

--jRdC2OsRnuV8iIl8
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl3mabYACgkQJNaLcl1U
h9Alvgf+O6LAdo281NDSae5rpCvfsxmLKh9POrtFw+1BQ0Sj8NX6kAjrShi6x//G
pXpypd9N3ikWjox5Fakw7VK1jz5QWUSdGR2PooLz1l8yJiu8KS13BAzZ128+9wzx
xAHMDv4Y4bEAUF6etkVz+C4cjjrvpPoJls41Fkd+mgUf4YJoSI1/2vaveJsh3SFZ
MqqGaxVSJF6Y8NkCiCi1iuwMJ54NEj0StvAJs/DoaC9QAgCKMJBN3A3mbtDvZrWD
efAisKVDhkz+xa6BUV+jW57SnSmFWvTY5zWBLCJGgnCHh2NWURd3nmEuV4kwtDdC
Svgjke4iToZwagfrdJkWbA4FqfAuMQ==
=jUTM
-----END PGP SIGNATURE-----

--jRdC2OsRnuV8iIl8--