linux-kernel - RE: [PATCH] ASoC: da7219: remove SRM lock check retry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AM5PR1001MB0994EB497D3BC7D0F4C6FD9080420@AM5PR1001MB0994.EURPRD10.PROD.OUTLOOK.COM>
Date:   Tue, 3 Dec 2019 09:46:03 +0000
From:   Adam Thomson <Adam.Thomson.Opensource@...semi.com>
To:     Brent Lu <brent.lu@...el.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
CC:     Support Opensource <Support.Opensource@...semi.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] ASoC: da7219: remove SRM lock check retry

On 03 December 2019 07:31, 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.

We can potentially reduce the timings here for something shorter although I'd
need to speak with the HW team as to what, if any reduction is feasible. However
this is not a real fix as there's potential for audible noises when you don't
enable WCLK first. As far as I can tell the Intel platforms are capable of
enabling clocks early, as can be seen in this board file with early SCLK enable:

https://elixir.bootlin.com/linux/latest/source/sound/soc/intel/boards/kbl_rt5663_max98927.c#L99

I think there's a need to find some method to enable the WCLK signal otherwise
there's the potential for audible artefacts when SRM finally locks which is not
going to be pleasant.

> 
> Signed-off-by: Brent Lu <brent.lu@...el.com>
> ---
>  sound/soc/codecs/da7219.c | 3 ++-
>  sound/soc/codecs/da7219.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/codecs/da7219.c b/sound/soc/codecs/da7219.c
> index f83a6ea..042e701 100644
> --- a/sound/soc/codecs/da7219.c
> +++ b/sound/soc/codecs/da7219.c
> @@ -833,7 +833,8 @@ static int da7219_dai_event(struct snd_soc_dapm_widget
> *w,
>  				srm_lock = true;
>  			} else {
>  				++i;
> -				msleep(50);
> +				if (i < DA7219_SRM_CHECK_RETRIES)
> +					msleep(50);
>  			}
>  		} while ((i < DA7219_SRM_CHECK_RETRIES) && (!srm_lock));
> 
> diff --git a/sound/soc/codecs/da7219.h b/sound/soc/codecs/da7219.h
> index 88b67fe..3149986 100644
> --- a/sound/soc/codecs/da7219.h
> +++ b/sound/soc/codecs/da7219.h
> @@ -770,7 +770,7 @@
>  #define DA7219_PLL_INDIV_36_TO_54_MHZ_VAL	16
> 
>  /* SRM */
> -#define DA7219_SRM_CHECK_RETRIES	8
> +#define DA7219_SRM_CHECK_RETRIES	1
> 
>  /* System Controller */
>  #define DA7219_SYS_STAT_CHECK_RETRIES	6
> --
> 2.7.4