[alsa-devel] [PATCH] ASoC: wm8962: Restore device state after reset in runtime resume

[Nicolin Chen]

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 :(