[alsa-devel] [PATCH] ASoC: wm8962: Restore device state after reset in runtime resume
broonie at kernel.org
Mon Jun 10 11:48:26 CEST 2013
On Sat, Jun 08, 2013 at 01:34:58PM +0800, Nicolin Chen wrote:
> On Fri, Jun 07, 2013 at 04:43:17PM +0100, Mark Brown wrote:
> > + /* Ensure we have soft control over all registers */
> > + regmap_update_bits(wm8962->regmap, WM8962_CLOCKING2,
> > + WM8962_CLKREG_OVD, WM8962_CLKREG_OVD);
> On our board this works finely, because our board uses GPIO5 as DMIC_DAT
> function which is suggested by WM8962 datasheet in APPLICATIONS chapter,
> so this case need to set CLKREG_OVD bit. But there is another case, the
> original one, also the driver currently considers, that is, GPIO5 actually
> controls SYSCLK source by its input electric level(logical 0 and 1).
> Pls check the note in WM8962 datasheet, MCLK_SRC bit of R8 (Clocking 2).
No, the driver doesn't support the hardware control configurations at
all - if you look in the probe function you'll see that this code is
also present there. Any system which wants to use the hardware control
would need to add platform data to enable this mode, though it's very
unlikely that this wouild happen and systems that wish to use GPIO5 as
an output need this as the value on power on will be indeterminate.
> > + /* Ensure that the oscillator and PLLs are disabled */
> > + regmap_update_bits(wm8962->regmap, WM8962_PLL2,
> > + WM8962_OSC_ENA | WM8962_PLL2_ENA | WM8962_PLL3_ENA,
> > + 0);
> Not sure if this is gonna be nice, because I have not seen any other
> place enabling either of these three bits if users need one of them.
Again this is to fix interactions with hardware control modes. Since
we're coming out of suspend mode where the device may well have been
powered down we can be confident that nothing is actually using the
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the Alsa-devel