[alsa-devel] [PATCH] ASoC: Consider the codec->active also when changing bias level
Take into account the codec->active (playback/capture activity) when changing the bias level.
Fixes the following scenario: if during active playback/capture the DAPM routes has been modified in a way, that there will be no complete route (for example muting the output) DAPM would set the codec into BIAS_STANDBY, which could disable the clocks from the codec (codec is master), which breaks the playback with error since the clocks are missing from the serial bus and no data is shifted out/in.
With this patch during active use (playback/capture) the DAPM will not set the bias to STANDBY, thus keeping the playback/capture running. When no playback/capture is running, the DAPM will handle the complete paths in a same way it used to: setting the bias to ON/STANDBY based on complete paths.
Signed-off-by: Peter Ujfalusi peter.ujfalusi@nokia.com --- 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 9babda5..567be82 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -977,7 +977,7 @@ static int dapm_power_widgets(struct snd_soc_codec *codec, int event) continue;
power = w->power_check(w); - if (power) + if (power || codec->active) sys_power = 1;
if (w->power == power)
On Mon, Sep 28, 2009 at 12:38:08PM +0300, Peter Ujfalusi wrote:
Fixes the following scenario: if during active playback/capture the DAPM routes has been modified in a way, that there will be no complete route (for example muting the output) DAPM would set the codec into BIAS_STANDBY, which could disable the clocks from the codec (codec is master), which breaks the playback with error since the clocks are missing from the serial bus and no data is shifted out/in.
This is only helping because the clocks generation is controlled by the bias level configuration. That's not really the way things are supposed to work - I'd rather see a different fix that explicitly represents whatever the requirement is for controlling the clocks. Turning on the clocks based on the bais level will generally result in them being turned on too much which will waste power.
I suspect you want to use AIF widgets and make the PLL a supply for them and any other things that need the PLL, and we should make arrangements to ensure that the AIF widget is enabled whenever the interface is live and the CODEC is master.
On Monday 28 September 2009 14:17:36 ext Mark Brown wrote:
On Mon, Sep 28, 2009 at 12:38:08PM +0300, Peter Ujfalusi wrote:
Fixes the following scenario: if during active playback/capture the DAPM routes has been modified in a way, that there will be no complete route (for example muting the output) DAPM would set the codec into BIAS_STANDBY, which could disable the clocks from the codec (codec is master), which breaks the playback with error since the clocks are missing from the serial bus and no data is shifted out/in.
This is only helping because the clocks generation is controlled by the bias level configuration. That's not really the way things are supposed to work - I'd rather see a different fix that explicitly represents whatever the requirement is for controlling the clocks. Turning on the clocks based on the bais level will generally result in them being turned on too much which will waste power.
I suspect you want to use AIF widgets and make the PLL a supply for them and any other things that need the PLL, and we should make arrangements to ensure that the AIF widget is enabled whenever the interface is live and the CODEC is master.
I see. So there is no mechanism in place which would keep the serial interface up when there is an ongoing playback/capture regardless of the DAPM routing?
On the other hand it also make sense to set the codec bias level to ON state, when there is ongoing playback/capture. Or not, not sure about it.
I have solved the problem for now without this patch, right now the kernel version that I'm using is 2.6.31, so I don't have the AIF widget to play with...
Thanks, Péter
On Tue, Sep 29, 2009 at 09:13:13AM +0300, Peter Ujfalusi wrote:
I see. So there is no mechanism in place which would keep the serial interface up when there is an ongoing playback/capture regardless of the DAPM routing?
Not in 2.6.31. Going forward the AIF widgets are the way to deal with this.
On the other hand it also make sense to set the codec bias level to ON state, when there is ongoing playback/capture. Or not, not sure about it.
Not really - the digital parts of the system are not generally sensitive to the quality of their supplies in the way that the analogue parts are.
participants (2)
-
Mark Brown -
Peter Ujfalusi