[<prev] [next>] [day] [month] [year] [list]
Message-ID: <VI1PR0402MB3342492AE94B24C7E92F1ABDE3D30@VI1PR0402MB3342.eurprd04.prod.outlook.com>
Date: Thu, 23 Apr 2020 07:38:04 +0000
From: "S.j. Wang" <shengjiu.wang@....com>
To: Charles Keepax <ckeepax@...nsource.cirrus.com>
CC: "lgirdwood@...il.com" <lgirdwood@...il.com>,
"broonie@...nel.org" <broonie@...nel.org>,
"perex@...ex.cz" <perex@...ex.cz>,
"tiwai@...e.com" <tiwai@...e.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"allison@...utok.net" <allison@...utok.net>,
"info@...ux.net" <info@...ux.net>,
"patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ASoC: wm8962: restore the CLOCKING2 register in resume
>
> On Tue, Apr 21, 2020 at 08:02:15PM +0800, Shengjiu Wang wrote:
> > The CLOCKING2 is a volatile register, but some bits should be restored
> > when resume, for example SYSCLK_SRC. otherwise the output clock is
> > wrong
> >
> > Signed-off-by: Shengjiu Wang <shengjiu.wang@....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 d9d59f45833f..6e96c0c5ad2a 100644
> > --- a/sound/soc/codecs/wm8962.c
> > +++ b/sound/soc/codecs/wm8962.c
> > @@ -82,6 +82,7 @@ struct wm8962_priv { #endif
> >
> > int irq;
> > + u32 regcache_clocking2;
> > };
> >
> > /* We can't use the same notifier block for more than one supply and
> > @@ -3813,6 +3814,10 @@ static int wm8962_runtime_resume(struct
> device
> > *dev)
> >
> > regcache_sync(wm8962->regmap);
> >
> > + regmap_update_bits(wm8962->regmap, WM8962_CLOCKING2,
> > + WM8962_SYSCLK_SRC_MASK,
> > + wm8962->regcache_clocking2);
> > +
>
> I wonder if it might just be better to make the register non-volatile? From
> looking through the datasheet I am guessing this is volatile for the
> CLASSD_CLK_DIV bits, which are controlled by the chip itself. But the
> datasheet claims these are read only and protected by the security key, and
> they are not read by the driver at all.
>
> Thanks,
> Charles
>
Use non-volatile also can fix the issue, I will send v2 for it
Best regards
Wang shengjiu
Powered by blists - more mailing lists