Re: [alsa-devel] [PATCH 1/5] ASoC: wm8731: rework power management
![](https://secure.gravatar.com/avatar/d28dfe03ea754ea1153719f4ced12649.jpg?s=120&d=mm&r=g)
On Wed, Jun 29, 2011 at 08:00:15PM +0200, Nicolas Ferre wrote:
Don't mix multiple changes into a single patch! There's no perceptible code overlap between these so I don't understand why you've merged them, it just makes review harder and the changelog less descriptive.
- preserve crystal oscillator across suspend/resume sequence: enabled by default, it should be kept enabled on resume.
This isn't what your code does...
- if codec is in active state: set the active bit at resume time.
Your changelog doesn't explain what the actual problem is here... I can see it by studying the diff but the changelog makes me think the change is bad as the subsystem shuts everything down before it enters CODEC suspend...
snd_soc_write(codec, WM8731_ACTIVE, 0x0);
snd_soc_write(codec, WM8731_PWR, 0xffff);
/* standby: keep crystal oscillator enabled */
snd_soc_write(codec, WM8731_PWR, 0x00df);
This doesn't keep the crystal oscillator enabled, this forces it on in suspend (and without looking at the datasheet it also changes way more than the one register bit I'd expect to be changed). If the system isn't using the oscillator then that's not good.
I'd expect to see a change to using snd_soc_update_bits() based on your description, or more likely something more involved.
@@ -533,6 +534,8 @@ static int wm8731_suspend(struct snd_soc_codec *codec, pm_message_t state) static int wm8731_resume(struct snd_soc_codec *codec) { wm8731_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
- if (codec->active)
snd_soc_write(codec, WM8731_ACTIVE, 0x0001);
This should be handled as part of the bias level managemnent and cache sync, if the disable happens in bias level management so should the restore.
![](https://secure.gravatar.com/avatar/e0e9f626c149bd6d05ef3609d4df8fb9.jpg?s=120&d=mm&r=g)
Le 29/06/2011 19:11, Mark Brown :
On Wed, Jun 29, 2011 at 08:00:15PM +0200, Nicolas Ferre wrote:
Don't mix multiple changes into a single patch! There's no perceptible code overlap between these so I don't understand why you've merged them, it just makes review harder and the changelog less descriptive.
Ok.
- preserve crystal oscillator across suspend/resume sequence: enabled by default, it should be kept enabled on resume.
This isn't what your code does...
snd_soc_write(codec, WM8731_ACTIVE, 0x0);
snd_soc_write(codec, WM8731_PWR, 0xffff);
/* standby: keep crystal oscillator enabled */
snd_soc_write(codec, WM8731_PWR, 0x00df);
This doesn't keep the crystal oscillator enabled, this forces it on in suspend (and without looking at the datasheet it also changes way more than the one register bit I'd expect to be changed). If the system isn't using the oscillator then that's not good.
I'd expect to see a change to using snd_soc_update_bits() based on your description, or more likely something more involved.
First of all, I experienced issues while not having OSC enabled during suspend/resume cycle. Am I right supposing that, if using oscillator to clock the codec, I have to keep it running during a suspend/resume cycle?
Is something like this sounds like an acceptable option or we need something more sophisticated?
@@ -481,7 +481,10 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_OFF: snd_soc_write(codec, WM8731_ACTIVE, 0x0); - snd_soc_write(codec, WM8731_PWR, 0xffff); + reg = 0xdf; + if (wm8731->sysclk_type == WM8731_SYSCLK_XTAL) + reg |= 1 << 0x5; + snd_soc_update_bits(codec, WM8731_PWR, 0x00ff, reg); regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies), wm8731->supplies); break;
And, yes, there is only 8 bits dedicated to power down control in this register.
Best regards,
![](https://secure.gravatar.com/avatar/e0e9f626c149bd6d05ef3609d4df8fb9.jpg?s=120&d=mm&r=g)
Le 30/06/2011 15:57, Nicolas Ferre :
Le 29/06/2011 19:11, Mark Brown :
On Wed, Jun 29, 2011 at 08:00:15PM +0200, Nicolas Ferre wrote:
Don't mix multiple changes into a single patch! There's no perceptible code overlap between these so I don't understand why you've merged them, it just makes review harder and the changelog less descriptive.
Ok.
- preserve crystal oscillator across suspend/resume sequence: enabled by default, it should be kept enabled on resume.
This isn't what your code does...
snd_soc_write(codec, WM8731_ACTIVE, 0x0);
snd_soc_write(codec, WM8731_PWR, 0xffff);
/* standby: keep crystal oscillator enabled */
snd_soc_write(codec, WM8731_PWR, 0x00df);
This doesn't keep the crystal oscillator enabled, this forces it on in suspend (and without looking at the datasheet it also changes way more than the one register bit I'd expect to be changed). If the system isn't using the oscillator then that's not good.
I'd expect to see a change to using snd_soc_update_bits() based on your description, or more likely something more involved.
First of all, I experienced issues while not having OSC enabled during suspend/resume cycle. Am I right supposing that, if using oscillator to clock the codec, I have to keep it running during a suspend/resume cycle?
Is something like this sounds like an acceptable option or we need something more sophisticated?
@@ -481,7 +481,10 @@ static int wm8731_set_bias_level(struct snd_soc_codec *codec, break; case SND_SOC_BIAS_OFF: snd_soc_write(codec, WM8731_ACTIVE, 0x0);
snd_soc_write(codec, WM8731_PWR, 0xffff);
reg = 0xdf;
if (wm8731->sysclk_type == WM8731_SYSCLK_XTAL)
Actually it is: if... != WM8731_SYSCLK_XTAL
reg |= 1 << 0x5;
snd_soc_update_bits(codec, WM8731_PWR, 0x00ff, reg);
And maybe here a simple snd_soc_write() is sufficient...
regulator_bulk_disable(ARRAY_SIZE(wm8731->supplies), wm8731->supplies); break;
And, yes, there is only 8 bits dedicated to power down control in this register.
Best regards,
![](https://secure.gravatar.com/avatar/d28dfe03ea754ea1153719f4ced12649.jpg?s=120&d=mm&r=g)
On Thu, Jun 30, 2011 at 03:57:12PM +0200, Nicolas Ferre wrote:
Please fix your mailer to line wrap within paragraphs.
First of all, I experienced issues while not having OSC enabled during suspend/resume cycle. Am I right supposing that, if using oscillator to clock the codec, I have to keep it running during a suspend/resume cycle?
No, not at all. What makes you believe that you would you need to do that?
![](https://secure.gravatar.com/avatar/e0e9f626c149bd6d05ef3609d4df8fb9.jpg?s=120&d=mm&r=g)
Le 30/06/2011 17:22, Mark Brown :
On Thu, Jun 30, 2011 at 03:57:12PM +0200, Nicolas Ferre wrote:
Please fix your mailer to line wrap within paragraphs.
First of all, I experienced issues while not having OSC enabled during suspend/resume cycle. Am I right supposing that, if using oscillator to clock the codec, I have to keep it running during a suspend/resume cycle?
No, not at all. What makes you believe that you would you need to do that?
Ok, I re-tested and for sure I was totally wrong! So we forget this part of the patch. I guess that this belief may come from my first implementation on 2.6.35 where OSC was not part of the DAPM... Sory for the noise.
I repost the "active bit" part real-soon-now.
Thanks for your help, best regards,
participants (2)
-
Mark Brown
-
Nicolas Ferre