[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20221107101010.GD10437@ediswmail.ad.cirrus.com>
Date: Mon, 7 Nov 2022 10:10:10 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: Chancel Liu <chancel.liu@....com>
CC: <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
<tiwai@...e.com>, <luca.ceresoli@...tlin.com>, <ojeda@...nel.org>,
<cmo@...exis.com>, <u.kleine-koenig@...gutronix.de>,
<xiaolei.wang@...driver.com>, <steve@....org>,
<chi.minghao@....com.cn>, <patches@...nsource.cirrus.com>,
<alsa-devel@...a-project.org>, <linux-kernel@...r.kernel.org>,
<shengjiu.wang@....com>
Subject: Re: [PATCH] ASoC: wm8962: Wait for updated value of WM8962_CLOCKING1
register
On Mon, Nov 07, 2022 at 02:38:18PM +0800, Chancel Liu wrote:
> DSPCLK_DIV field in WM8962_CLOCKING1 register is used to generate
> correct frequency of LRCLK and BCLK. Sometimes the read-only value
> can't be updated timely after enabling SYSCLK. This results in wrong
> calculation values. Delay is introduced here to wait for newest value
> from register. The time of the delay should be at least 500~1000us
> according to test.
>
> Signed-off-by: Chancel Liu <chancel.liu@....com>
> ---
> sound/soc/codecs/wm8962.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
> index b4b4355c6728..563843565f68 100644
> --- a/sound/soc/codecs/wm8962.c
> +++ b/sound/soc/codecs/wm8962.c
> @@ -2503,6 +2503,14 @@ static void wm8962_configure_bclk(struct snd_soc_component *component)
> snd_soc_component_update_bits(component, WM8962_CLOCKING2,
> WM8962_SYSCLK_ENA_MASK, WM8962_SYSCLK_ENA);
>
> + /* DSPCLK_DIV field in WM8962_CLOCKING1 register is used to generate
> + * correct frequency of LRCLK and BCLK. Sometimes the read-only value
> + * can't be updated timely after enabling SYSCLK. This results in wrong
> + * calculation values. Delay is introduced here to wait for newest
> + * value from register. The time of the delay should be at least
> + * 500~1000us according to test.
> + */
> + msleep(1);
This looks reasonable but for a 1ms delay we should really be
using usleep_range rather than msleep.
Thanks,
Charles
Powered by blists - more mailing lists