[alsa-devel] [PATCH] ASoC: wm8962: Restore device state after reset in runtime resume
After the device has been reset we need to repeat the same initialisation we do on probe to make sure that the device is in a known state.
Signed-off-by: Mark Brown broonie@linaro.org --- sound/soc/codecs/wm8962.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index d56dd86..32c2c47 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -3723,6 +3723,21 @@ static int wm8962_runtime_resume(struct device *dev)
wm8962_reset(wm8962);
+ /* SYSCLK defaults to on; make sure it is off so we can safely + * write to registers if the device is declocked. + */ + regmap_update_bits(wm8962->regmap, WM8962_CLOCKING2, + WM8962_SYSCLK_ENA, 0); + + /* Ensure we have soft control over all registers */ + regmap_update_bits(wm8962->regmap, WM8962_CLOCKING2, + WM8962_CLKREG_OVD, WM8962_CLKREG_OVD); + + /* 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); + regcache_sync(wm8962->regmap);
return 0;
On Fri, Jun 07, 2013 at 04:43:17PM +0100, Mark Brown wrote:
- /* SYSCLK defaults to on; make sure it is off so we can safely
* write to registers if the device is declocked.*/- regmap_update_bits(wm8962->regmap, WM8962_CLOCKING2,
WM8962_SYSCLK_ENA, 0);
I think it's really nice to disable SYSCLK_ENA here and let soc-dapm load it up since there's DAPM SUPPLY registered for SYSCLK_ENA bit. Please keep this line here. Thank you.
- /* 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).
And I have to say that WM8962 is so sophisticatedly designed that this CLKREG_OVD bit is pretty hard for software to perfectly control. But my previous patch, at least at the idea of GP5_FN checking before setting CLKREG_OVD bit, does not break the SYSCLK source controlling function. Even if it might be not a qualified one, I think we can still figure out a better solution based on that patch.
- /* 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.
------------------------------------------------------------------------
Allow me to start one more question about power up here, Since we are solving all the resume initial issue in one patch.
I have a concern about an applied patch: commit 52c0eee33 "Don't duplicate bias level management"
This patch removed BIAS generator powering up code. But I found that, at least on our i.MX6 SabreSD board with WM8962 as audio CODEC, these BIAS bits are not being updated by soc-core before starting playback, then "wm8962 0-001a: DC servo timed out" error msg will occur. I checked the regmap of WM8962 and found these bits, STARTUP_BIAS_ENA bit in R28 for example, are still remaining reset value 0x0 -- disabled.
However, if I revert that patch, with my machine driver and my board I can play euphonious music as before. (I'm now mainly using Kernel 3.5)
I traced the soc-core by searching 'idle_bias_off' and didn't found any power-codec-up code in that file. Maybe I'm still missing some parts, so could you please tell me is there anything wrong on my side?
Thank you. And sorry if I opened the Pandora Box because I just asked too many questions :(
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 PLLs.
Hi,
On Fri, Jun 10, Mark Brown wrote:
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 PLLs.
I see your point. Then I think I'm okay with this patch. Please apply this to the manline, it's really helpful. Tested-by: Nicolin Chen b42378@freescale.com
And sir, I'm sorry if I push you. But I'm not sure about my patch: ([PATCH V5] ASoC: fsl: add imx-wm8962 machine driver)
Is there anything essential I need to improve? Please find that thread and append your comments as before.
Thank you. Nicolin Chen
On Mon, Jun 10, 2013 at 11:54:18AM +0000, Chen Guangyu-B42378 wrote:
And sir, I'm sorry if I push you. But I'm not sure about my patch: ([PATCH V5] ASoC: fsl: add imx-wm8962 machine driver)
Is there anything essential I need to improve? Please find that thread and append your comments as before.
I've not looked at it yet, you only posted it late on Friday.
participants (4)
-
Chen Guangyu-B42378 -
Mark Brown -
Mark Brown -
Nicolin Chen