[RFC 2.6.38] ASoC: Fix bias power down of non-DAPM codec

[RFC 2.6.38] ASoC: Fix bias power down of non-DAPM codec

[Jarkko Nikula]

Currently bias of non-DAPM codec will be powered down (standby/off) whenever
there is a stream stop. This is wrong in simultaneous playback/capture since
the bias is put down immediately after stopping the first stream.

Fix this by using the codec->active count when figuring out the needed bias
level after stream stop.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
---
RFC since does this look a valid fix and how to deal with 2.6.37? I think
patching the .37 first will result in bisect build errors in mainline when
later merging upcoming .38 changes. Would it be better to patch .37 after
it's released?
---
 sound/soc/soc-dapm.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 9af2d8a..b521a13 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -981,6 +981,9 @@ static int dapm_power_widgets(struct snd_soc_dapm_context *dapm, int event)
 		case SND_SOC_DAPM_STREAM_RESUME:
 			sys_power = 1;
 			break;
+		case SND_SOC_DAPM_STREAM_STOP:
+			sys_power = !!dapm->codec->active;
+			break;
 		case SND_SOC_DAPM_STREAM_SUSPEND:
 			sys_power = 0;
 			break;
-- 
1.7.2.3

Re: [RFC 2.6.38] ASoC: Fix bias power down of non-DAPM codec

[Mark Brown]

On Fri, Dec 10, 2010 at 06:23:41PM +0200, Jarkko Nikula wrote:
> Currently bias of non-DAPM codec will be powered down (standby/off) whenever
> there is a stream stop. This is wrong in simultaneous playback/capture since
> the bias is put down immediately after stopping the first stream.
> 
> Fix this by using the codec->active count when figuring out the needed bias
> level after stream stop.
> 
> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
> ---
> RFC since does this look a valid fix and how to deal with 2.6.37? I think
> patching the .37 first will result in bisect build errors in mainline when
> later merging upcoming .38 changes. Would it be better to patch .37 after
> it's released?

Better to get a patch in there first, then deal with the merge up to
2.6.38.  Stuff like this really does make me think we should just make
DAPM mandatory.  I should have some time to look at this very soon.

[PATCH 2.6.37] ASoC: Fix bias power down of non-DAPM codec

[Jarkko Nikula]

Currently bias of non-DAPM codec will be powered down (standby/off) whenever
there is a stream stop. This is wrong in simultaneous playback/capture since
the bias is put down immediately after stopping the first stream.

Fix this by using the codec->active count when figuring out the needed bias
level after stream stop.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
---
 sound/soc/soc-dapm.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 75ed649..c721502 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -944,6 +944,9 @@ static int dapm_power_widgets(struct snd_soc_codec *codec, int event)
 		case SND_SOC_DAPM_STREAM_RESUME:
 			sys_power = 1;
 			break;
+		case SND_SOC_DAPM_STREAM_STOP:
+			sys_power = !!codec->active;
+			break;
 		case SND_SOC_DAPM_STREAM_SUSPEND:
 			sys_power = 0;
 			break;
-- 
1.7.2.3

[RFC 2.6.38] ASoC: Fix build error caused by merging a fix for 2.6.37 into 2.6.38

[Jarkko Nikula]

Fix "ASoC: Fix bias power down of non-DAPM codec" for 3.6.37 will cause a
build error when merging into ASoC for-2.6.38. Fix the issue by doing a
change that commit ce6120c "ASoC: Decouple DAPM from CODECs" would do.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
---
Ideally this would be squashed in ce6120c "ASoC: Decouple DAPM from CODECs".
---
 sound/soc/soc-dapm.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index 45e6a11..b521a13 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -982,7 +982,7 @@ static int dapm_power_widgets(struct snd_soc_dapm_context *dapm, int event)
 			sys_power = 1;
 			break;
 		case SND_SOC_DAPM_STREAM_STOP:
-			sys_power = !!codec->active;
+			sys_power = !!dapm->codec->active;
 			break;
 		case SND_SOC_DAPM_STREAM_SUSPEND:
 			sys_power = 0;
-- 
1.7.2.3

Re: [RFC 2.6.38] ASoC: Fix build error caused by merging a fix for 2.6.37 into 2.6.38

[Liam Girdwood]

On Fri, 2010-12-10 at 20:54 +0200, Jarkko Nikula wrote:
> Fix "ASoC: Fix bias power down of non-DAPM codec" for 3.6.37 will cause a
> build error when merging into ASoC for-2.6.38. Fix the issue by doing a
> change that commit ce6120c "ASoC: Decouple DAPM from CODECs" would do.
> 
> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
> ---
> Ideally this would be squashed in ce6120c "ASoC: Decouple DAPM from CODECs".
> ---

Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: [RFC 2.6.38] ASoC: Fix build error caused by merging a fix for 2.6.37 into 2.6.38

[Mark Brown]

On Fri, Dec 10, 2010 at 08:54:49PM +0200, Jarkko Nikula wrote:
> Fix "ASoC: Fix bias power down of non-DAPM codec" for 3.6.37 will cause a
> build error when merging into ASoC for-2.6.38. Fix the issue by doing a
> change that commit ce6120c "ASoC: Decouple DAPM from CODECs" would do.

Applied, thanks.

Re: [PATCH 2.6.37] ASoC: Fix bias power down of non-DAPM codec

[Liam Girdwood]

On Fri, 2010-12-10 at 20:53 +0200, Jarkko Nikula wrote:
> Currently bias of non-DAPM codec will be powered down (standby/off) whenever
> there is a stream stop. This is wrong in simultaneous playback/capture since
> the bias is put down immediately after stopping the first stream.
> 
> Fix this by using the codec->active count when figuring out the needed bias
> level after stream stop.
> 
> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
-- 
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk

Re: [PATCH 2.6.37] ASoC: Fix bias power down of non-DAPM codec

[Mark Brown]

On Fri, Dec 10, 2010 at 08:53:55PM +0200, Jarkko Nikula wrote:
> Currently bias of non-DAPM codec will be powered down (standby/off) whenever
> there is a stream stop. This is wrong in simultaneous playback/capture since
> the bias is put down immediately after stopping the first stream.
> 
> Fix this by using the codec->active count when figuring out the needed bias
> level after stream stop.
> 
> Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>

Applied, thanks.

tabs versus space fill

[Peter Hsiang]

I noticed that in the latest version of the kernel (next), the formatting of the soc sound driver file max98088.c had been changed.  Someone had changed all the tabs to space-fill.  I thought the kernel coding standard encourages the use of tabs.  Is the use of space-fill the new formatting preference for the kernel?

I did not see this patch change on alsa-devel list.  
How do I find out where and when this was changed?

Thanks,

Peter

Re: tabs versus space fill

[Vasily Khoruzhick]

On Friday 10 December 2010 23:25:10 Peter Hsiang wrote:

> I did not see this patch change on alsa-devel list.
> How do I find out where and when this was changed?

Use 'git blame'

Regards
Vasily

Re: tabs versus space fill

[Mark Brown]

On Fri, Dec 10, 2010 at 01:25:10PM -0800, Peter Hsiang wrote:

[Please fix to word wrap within paragraphs, I've reflowed the text below.]

> I noticed that in the latest version of the kernel (next), the
> formatting of the soc sound driver file max98088.c had been changed.
> Someone had changed all the tabs to space-fill.  I thought the kernel
> coding standard encourages the use of tabs.  Is the use of space-fill
> the new formatting preference for the kernel?

No, everything should use raw tabs.

> I did not see this patch change on alsa-devel list.  
> How do I find out where and when this was changed?

There's been no change in the kernel here - looking at the original mail
from you adding the driver that used spaces rather than tabs.  I expect
that this was caused by a configuration issue in your mail system which
caused it to rewrite the content, either the user agent or something on
the server side.