Suspend block api (version 6)
in [Kernel]
|
Prev: mm: fix race between shift_arg_pages and rmap_walk
Next: [PATCH -next] power: fix block_io.c printk warning
From: Mark Brown on 5 May 2010 15:10 On Wed, May 05, 2010 at 02:36:10PM -0400, Alan Stern wrote: > 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? Aside from things where the CODEC is acting as a wake source (for stuff like jack detect) which are obviously already handled it's basically just when you've got an external audio source flowing through the device which is going to continue to function during suspend. Things like FM radios, for example. I'm not aware of non-audio examples that are use case specific and don't just involve utterly ignoring AP suspends. > In short, I'm trying to get at how much information drivers _really_ > need to have about the reason for a system suspend. It's not exactly the *reason* that makes the difference, it's more that this aggressive use of suspend makes much more apparent a problem which might exist anyway for this sort of hardware. When we get runtime PM delviering similar power levels we'll sidestep the problem since we won't need to do a system wide suspend. -- 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 5 May 2010 15:20 On Wed, 5 May 2010, Matthew Garrett wrote: > > 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? Should the audio driver be smart enough to know that the codec needs to remain powered up during every opportunistic suspend? Or only during opportunistic suspends while a call is in progress? Does it know when a call is in progress? Does Android use forced suspends? If it does, are they supposed to shut down the codec? 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: Matthew Garrett on 5 May 2010 15:30 On Wed, May 05, 2010 at 03:20:40PM -0400, Alan Stern wrote: > One the face of it, a runtime-PM solution would dictate that the > codec's driver ought to turn off the codec whenever the driver thinks > it isn't being used. Ergo, if the driver didn't know when a call was > in progress, it would use runtime PM to turn off the codec during a > call. Well, part of the problem is that right now most of our beliefs about imposed constraints tend to be based on what userspace is doing - "Don't power down the audio codec when userspace has it open", for instance. But that goes away with opportunistic suspend. In most cases you don't want the audio codec to stay awake just because userspace was using it to make bouncing cow noises, especially if you've just frozen userspace. So the problem becomes more complicated than it would otherwise be. -- 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: Matthew Garrett on 5 May 2010 15:30 On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote: > Should the audio driver be smart enough to know that the codec needs to > remain powered up during every opportunistic suspend? > > Or only during opportunistic suspends while a call is in progress? The latter is obviously preferable... > Does it know when a call is in progress? Perhaps you could infer that from the audio routing setup? I don't know enough about embedded codecs. > Does Android use forced suspends? No. -- 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 5 May 2010 15:30
On Wed, 5 May 2010, Mark Brown wrote: > > In short, I'm trying to get at how much information drivers _really_ > > need to have about the reason for a system suspend. > > It's not exactly the *reason* that makes the difference, it's more that > this aggressive use of suspend makes much more apparent a problem which > might exist anyway for this sort of hardware. Then the underlying problem should be solved -- hopefully in a nice, system-independent way. But I'm still trying to understand exactly what that underlying problem _is_. That means understanding when the codec needs to be shut down and when it doesn't, and knowing how much of this information is available to the driver. > When we get runtime PM delviering similar power levels we'll sidestep > the problem since we won't need to do a system wide suspend. One the face of it, a runtime-PM solution would dictate that the codec's driver ought to turn off the codec whenever the driver thinks it isn't being used. Ergo, if the driver didn't know when a call was in progress, it would use runtime PM to turn off the codec during a call. For this reason I don't see how using runtime PM instead of suspend blockers would solve anything. 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/ |