From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Patrick Lai <plai@codeaurora.org>
Cc: alsa-devel <alsa-devel@alsa-project.org>, Liam Girdwood <lrg@ti.com>
Subject: Re: Problem with snd_soc_suspend
Date: Thu, 17 May 2012 22:46:05 +0100 [thread overview]
Message-ID: <20120517214604.GK26337@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4FB55DDE.30804@codeaurora.org>
[-- 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 --]
prev parent reply other threads:[~2012-05-17 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-14 6:30 Problem with snd_soc_suspend Patrick Lai
2012-05-14 8:34 ` Mark Brown
2012-05-17 20:21 ` Patrick Lai
2012-05-17 21:46 ` Mark Brown [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120517214604.GK26337@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@ti.com \
--cc=plai@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.