Problem with snd_soc_suspend

Problem with snd_soc_suspend

[Patrick Lai]

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

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Problem with snd_soc_suspend

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 807 bytes --]

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.

> 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

No, the whole point here is to suspend.  If we did that we'd never
suspend any active streams.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Problem with snd_soc_suspend

[Patrick Lai]

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.

>> 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
>
> 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

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

Re: Problem with snd_soc_suspend

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1562 bytes --]

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.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]