[alsa-devel] [PATCH] ASoC: WM8962: Set CLKREG_OVD if GP5_FN is not its reset value
According to WM8962 datasheet, the GP5_FN bit of R516 (GPIO 5) depends on the CLKREG_OVD bit of R8 (Clocking2):
"Note that GPIO5 functions are only supported when CLKREG_OVD=1. When CLKREG_OVD=0, the contents of Register R516 must not be changed from the default value."
So set CLKREG_OVD bit before regcache_sync() updates the GP5_FN bit to a non-reset value.
Signed-off-by: Nicolin Chen b42378@freescale.com --- sound/soc/codecs/wm8962.c | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c index 26219ea..9c8fd11 100644 --- a/sound/soc/codecs/wm8962.c +++ b/sound/soc/codecs/wm8962.c @@ -3739,6 +3739,23 @@ static int wm8962_i2c_remove(struct i2c_client *client) }
#ifdef CONFIG_PM_RUNTIME +static void wm8962_check_gp5_fn(struct snd_soc_codec *codec) +{ + int changed; + + /* + * If GP5_FN is not going to be the reset value 0x0, + * need to set CLKREG_OVD bit of Register CLOCKING2 + * before regcache_sync() updates GP5_FN bit to a + * non-reset value. The reset value should be 0x0. + */ + changed = snd_soc_test_bits(codec, WM8962_GPIO_5, + WM8962_GP5_FN_MASK, 0x0); + if (changed) + snd_soc_update_bits(codec, WM8962_CLOCKING2, + WM8962_CLKREG_OVD_MASK, WM8962_CLKREG_OVD); +} + static int wm8962_runtime_resume(struct device *dev) { struct wm8962_priv *wm8962 = dev_get_drvdata(dev); @@ -3756,6 +3773,8 @@ static int wm8962_runtime_resume(struct device *dev)
wm8962_reset(wm8962);
+ wm8962_check_gp5_fn(wm8962->codec); + regcache_sync(wm8962->regmap);
return 0;
On Fri, Jun 07, 2013 at 08:14:18PM +0800, Nicolin Chen wrote:
Please use subject lines appropriate for the thing you're changing.
According to WM8962 datasheet, the GP5_FN bit of R516 (GPIO 5) depends on the CLKREG_OVD bit of R8 (Clocking2):
"Note that GPIO5 functions are only supported when CLKREG_OVD=1. When CLKREG_OVD=0, the contents of Register R516 must not be changed from the default value."
So set CLKREG_OVD bit before regcache_sync() updates the GP5_FN bit to a non-reset value.
You're missing a whole batch of handling of device reset here - look at how we handle things on power on.
On Fri, Jun 07, 2013, Mark Brown wrote:
Please use subject lines appropriate for the thing you're changing.
I'm sorry. I'll pay attention to it next time.
You're missing a whole batch of handling of device reset here - look at how we handle things on power on.
Are you talking about the initial code in wm8962_probe()? But after wm8962_runtime_resume(), register Clocking2 will be reset to its default value without OVD-setting and won't be recovered after regcache_sync() due to volatile_reg. If I'm wrong about it, pls tell me. I'll be happy if this codec driver hasn't this issue.
Thank you.
On Fri, Jun 07, 2013 at 03:33:31PM +0000, Chen Guangyu-B42378 wrote:
On Fri, Jun 07, 2013, Mark Brown wrote:
You're missing a whole batch of handling of device reset here - look at how we handle things on power on.
Are you talking about the initial code in wm8962_probe()? But after wm8962_runtime_resume(), register Clocking2 will be reset to its default value without OVD-setting and won't be recovered after regcache_sync() due to volatile_reg.
The point is that there's more work needed to recover the device state here, you're only doing one of the several things that need to be done after the device has been restored.
On Fri, Jun 07, 2013, Mark Brown wrote:
The point is that there's more work needed to recover the device state here, you're only doing one of the several things that need to be done after the device has been restored.
That's because I'm too scared to put too many code into my single patch :(
Sir, I'm so glad you can fix this issue with such a quick response. I'll test that patch tomorrow moring (midnight here) and give you a feedback.
Thank you so much.
On Fri, Jun 07, 2013 at 04:29:49PM +0000, Chen Guangyu-B42378 wrote:
On Fri, Jun 07, 2013, Mark Brown wrote:
The point is that there's more work needed to recover the device state here, you're only doing one of the several things that need to be done after the device has been restored.
That's because I'm too scared to put too many code into my single patch :(
Ah, OK. In this case you're being too conservative - there's a whole batch of initialistion which is missing, the simplest thing is to pull the lot over since if one bit is missing the others almost certainly are too.
Sir, I'm so glad you can fix this issue with such a quick response. I'll test that patch tomorrow moring (midnight here) and give you a feedback.
Note that I haven't tested that patch at all (well, I compiled it but who knows if it runs or not).
participants (3)
-
Chen Guangyu-B42378 -
Mark Brown -
Nicolin Chen