From: Mark Brown on
On Wed, May 05, 2010 at 11:35:56AM -0400, Alan Stern wrote:
> On Wed, 5 May 2010, Mark Brown wrote:

> > In other words, the issue is that we run into situations where we need
> > an element of suspend control to go along with the opportunistic suspend
> > in order to allow some elements to be kept running - since suspend
> > blocking is taken suspend suppression seems like a reasonable term.

> Android must already include some solution to this problem. Why not
> use that solution more generally?

Not so much; at least for audio it's being handled with platform
specific bodges as far as I've seen so far. If there had been a
standard way of doing this I'd have expected to see it in this patch
series. The Google systems all use Qualcomm chipsets which aren't
affected by this since the audio CODEC is hidden from Linux and none of
the audio actually uses ALSA at all in the BSPs I looked at.

It's entirely possible I'm missing something here, everything I know has
come from either talking to users or trawling code on the internet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:

> If the conclusion is that we don't have anything generic within the
> kernel then it'd be good to at least have this explicitly spelled out so
> that we're clear what everyone thinks is going on here and how things
> are supposed to work. At the minute it doesn't feel like we've had the
> discussion so we could end up working at cross purposes. I don't want
> to end up in the situation where I have to work around the APIs I'm
> using without the relevant maintainers having sight of that since that
> not only am I likely to be missing some existing solution to the problem
> but is also prone to causing problems maintaining the underlying API.

We seem to have ended up managing most of our PM infrastructure
iteratively. If the concern is more about best practices than intrinsic
incompatibilities, I'd lean towards us being better off merging this now
and then working things out over the next few releases as we get a
better understanding of the implications. The main thing that we have to
get right in the short term is the userspace API - everything else is
easier to fix up as we go along.

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on
On Wed, 5 May 2010, Matthew Garrett wrote:

> On Wed, May 05, 2010 at 02:56:22PM +0100, Mark Brown wrote:
>
> > If the conclusion is that we don't have anything generic within the
> > kernel then it'd be good to at least have this explicitly spelled out so
> > that we're clear what everyone thinks is going on here and how things
> > are supposed to work. At the minute it doesn't feel like we've had the
> > discussion so we could end up working at cross purposes. I don't want
> > to end up in the situation where I have to work around the APIs I'm
> > using without the relevant maintainers having sight of that since that
> > not only am I likely to be missing some existing solution to the problem
> > but is also prone to causing problems maintaining the underlying API.
>
> We seem to have ended up managing most of our PM infrastructure
> iteratively. If the concern is more about best practices than intrinsic
> incompatibilities, I'd lean towards us being better off merging this now
> and then working things out over the next few releases as we get a
> better understanding of the implications. The main thing that we have to
> get right in the short term is the userspace API - everything else is
> easier to fix up as we go along.

This particular question could use a little more discussion. I'm
interested to know, for example, under what conditions you would or
would not want to shut down an autonomous codec while going into system
suspend on a cell phone.

Clearly if there's a call in progress you don't want to shut the codec
down. Are there any other circumstances? Would they vary according to
whether the suspend was forced or opportunistic?

In short, I'm trying to get at how much information drivers _really_
need to have about the reason for a system suspend.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on
On Wed, May 05, 2010 at 06:33:37PM +0100, Matthew Garrett wrote:

> We seem to have ended up managing most of our PM infrastructure
> iteratively. If the concern is more about best practices than intrinsic
> incompatibilities, I'd lean towards us being better off merging this now
> and then working things out over the next few releases as we get a
> better understanding of the implications. The main thing that we have to
> get right in the short term is the userspace API - everything else is
> easier to fix up as we go along.

Right, the big issue for me is that there's likely to be some form of
userspace API visible for controlling this. I think I can keep it
mostly in-kernel for audio (by providing new APIs to mark some inputs
and outputs as being live during suspend) but need to check.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Matthew Garrett on
On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote:

> This particular question could use a little more discussion. I'm
> interested to know, for example, under what conditions you would or
> would not want to shut down an autonomous codec while going into system
> suspend on a cell phone.
>
> Clearly if there's a call in progress you don't want to shut the codec
> down. Are there any other circumstances? Would they vary according to
> whether the suspend was forced or opportunistic?

Yeah, ok. We probably do need to figure this out.

(Cc:ing Rebecca to see how this got handled on Droid)

The current state of affairs is that a system suspend request is
expected to put the device in as low a power state as possible given the
required wakeup events. Runtime power management is expected to put the
device in as low a power state as possible given its usage constraints.
If opportunistic suspend does the former then it'll tear down devices
that may be in use, but we don't have any real way to indicate usage
constraints other than the phone app taking a wakelock - and that means
leaving userspace running during calls, which seems excessive.

Mark's right in that the only case I can think of that's really relevant
right now is the audio hardware, so the inelegant solution is that this
is something that could be provided at the audio level. Is this
something we want a generic solution for? If so, what should it look
like?

--
Matthew Garrett | mjg59(a)srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/