[alsa-devel] [RFC 2.6.38] ASoC: Fix bias power down of non-DAPM codec
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;
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.
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;
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;
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
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.
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
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.
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
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.
participants (5)
-
Jarkko Nikula -
Liam Girdwood -
Mark Brown -
Peter Hsiang -
Vasily Khoruzhick