[alsa-devel] Problem with snd_soc_suspend
Hi,
The CODEC I am working on has multiple digital audio interfaces included in multiple DAI-LINks. DAILINK X has ignore_suspend flag set and DAILINK Y has ignore_suspend flag cleared. The problem I encountered is that as system attempts to enter suspend while DAILINK X is active, snd_soc_suspend() calls snd_soc_dapm_stream_event( SND_SOC_DAPM_STREAM_SUSPEND) on inactive DAILINK Y since DAILINK Y ignore flag is not set. Consequently, CODEC widgets get powered off even though they should remain powered for DAILINK X. Kernel version I am working with is 3.0.
Couple questions with respect to this problem
1. Should soc-core check if CODEC DAI is active beside checking ignore_suspend flag before calling snd_soc_dapm_stream_event()? I checked latest soc-core.c from kernel 3.4 RC7. The logic is the same as 3.0
2. Even if snd_soc_dapm_stream_event() is called, DAPM should not power off widgets that are powered up for DAILINK x. It seems like DAPM has the logic to only power off AIF widget if stream name of widget matches CODEC DAI stream name in soc_dapm_stream_event(). I have not gotten time to debug this problem further. However, is it a known bug on kernel 3.0. If so, has the problem been addressed in more recent kernel?
Thanks Patrick
On Sun, May 13, 2012 at 11:30:29PM -0700, Patrick Lai wrote:
that as system attempts to enter suspend while DAILINK X is active, snd_soc_suspend() calls snd_soc_dapm_stream_event( SND_SOC_DAPM_STREAM_SUSPEND) on inactive DAILINK Y since DAILINK Y ignore flag is not set. Consequently, CODEC widgets get powered off even though they should remain powered for DAILINK X.
This sounds like expected behaviour, if the widgets aren't marked as ignoring suspend then they will be suspended.
- Should soc-core check if CODEC DAI is active beside checking
ignore_suspend flag before calling snd_soc_dapm_stream_event()? I checked latest soc-core.c from kernel 3.4 RC7. The logic is the same as 3.0
No, the whole point here is to suspend. If we did that we'd never suspend any active streams.
On 5/14/2012 1:34 AM, Mark Brown wrote:
On Sun, May 13, 2012 at 11:30:29PM -0700, Patrick Lai wrote:
that as system attempts to enter suspend while DAILINK X is active, snd_soc_suspend() calls snd_soc_dapm_stream_event( SND_SOC_DAPM_STREAM_SUSPEND) on inactive DAILINK Y since DAILINK Y ignore flag is not set. Consequently, CODEC widgets get powered off even though they should remain powered for DAILINK X.
This sounds like expected behaviour, if the widgets aren't marked as ignoring suspend then they will be suspended.
As CODEC is getting more complicated and more widgets would be defined, I don't think it's scalable to mark ignore suspend per widget.
- Should soc-core check if CODEC DAI is active beside checking
ignore_suspend flag before calling snd_soc_dapm_stream_event()? I checked latest soc-core.c from kernel 3.4 RC7. The logic is the same as 3.0
No, the whole point here is to suspend. If we did that we'd never suspend any active streams.
If so, what is purpose of ignore_suspend? My problem is that active stream which has ignore_suspend flag set ends up suspended because an inactive stream without ignore_suspend flag set happens to be using same CODEC but different digital audio interface. I don't think it's the right behavior. DAPM should maintain widget usage reference. Only If all CODEC DAIs that are using given widget are going to suspend should DAPM go ahead power off the widget.
Thanks Patrick
On Thu, May 17, 2012 at 01:21:50PM -0700, Patrick Lai wrote:
On 5/14/2012 1:34 AM, Mark Brown wrote:
This sounds like expected behaviour, if the widgets aren't marked as ignoring suspend then they will be suspended.
As CODEC is getting more complicated and more widgets would be defined, I don't think it's scalable to mark ignore suspend per widget.
You only have to do this for widgets on the edge of the graph, it's just the same input to output algorithm that's applied as normal but with a subset of input and output widgets being considered.
No, the whole point here is to suspend. If we did that we'd never suspend any active streams.
If so, what is purpose of ignore_suspend? My problem is that active stream which has ignore_suspend flag set ends up suspended because an inactive stream without ignore_suspend flag set happens to be using same CODEC but different digital audio interface. I don't think it's the right behavior. DAPM should maintain widget usage reference. Only If all CODEC DAIs that are using given widget are going to suspend should DAPM go ahead power off the widget.
The suspend of the device is somewhat orthogonal to the suspend of the device as a whole - the device as a whole is suspended if there are no active widgets and the widgets will go inactive if they're not part of an active path. You will at the very least always have to mark inputs and outputs that are connected to the DAIs as ignoring suspend, adding something to flag the DAI widgets now we have those should be trivial.
participants (2)
-
Mark Brown -
Patrick Lai