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:50 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? I think for simplicity and maximum flexibility we should just ignore the reason for suspend here, if I'm adding support for this in the drivers the suspend reason is not going to be terribly useful and it makes the feature more widely useful should people come up with other applications. Note that we already have advanced runtime PM for embedded audio which will drive modern CODECs into full off state when the device is idle anyway, independently of any suspend or runtime PM that the system does. Older CODECs need their bias levels maintaining but we can ignore the difference there from this point of view. > Does it know when a call is in progress? Not at present. This is relatively straightforward to add within ASoC, especially for analogue links, if not completely trivial. Digital basebands are a bit more fun but not insurmountable (and need cleaning up anyway, there's some ongoing work which should hit soon). We currently drive everything into off state when we're told to suspend since it's the right thing to do for most non-phone devices. We'll still need to drive some of the system into an off state (eg, some of the drivers in the CPU) even when this is handled. > Does Android use forced suspends? Pass, but it's not been an issue users have raised with me - but then we can't tell why the suspend happens and need to handle opportunistic suspend anyway. > If it does, are they supposed to shut down the codec? I suspect it's a non-issue; if we're not actually using audio then ASoC will drive a modern CODEC into power off anyway as part of its runtime PM. However, I believe some non-Android phone stacks are doing something along that line. -- 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: tytso on 5 May 2010 16:00 Hi Mark, I confess I've completely lost track of (a) what problem you are trying to solve, and (b) how this might relate to some change that you'd like to see in the suspend block API. Could you do a quick summary and recap? I've gone over the entire thread, and it's still not clear what change you're advocating for in suspend blockers. Thanks, regards, - Ted On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote: > On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote: > > On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote: > > > > 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. > > Yes, you can providing we extract a bit more information from the > machine drivers and/or userspace - we already do our power management > based on paths. The implementation I'd do here is to provide a facility > for marking some of the path endpoints as suspend insensitive then on > suspend leave those endpoints in their current state, force the other > endpoints off temporarily and re-run the standard power checks. > > One thing I'll need to have a bit of a think about is if we need to > provide the ability to offer control to userspace for the suspend state > of path endpoints separately to their runtime state; I suspect the > answer is yes. > -- > 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/ -- 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 5 May 2010 16:00 On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote: > On Wed, May 05, 2010 at 03:13:52PM -0400, Alan Stern wrote: > > 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. Yes, you can providing we extract a bit more information from the machine drivers and/or userspace - we already do our power management based on paths. The implementation I'd do here is to provide a facility for marking some of the path endpoints as suspend insensitive then on suspend leave those endpoints in their current state, force the other endpoints off temporarily and re-run the standard power checks. One thing I'll need to have a bit of a think about is if we need to provide the ability to offer control to userspace for the suspend state of path endpoints separately to their runtime state; I suspect the answer is yes. -- 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 16:10 On Wed, 5 May 2010, Matthew Garrett wrote: > 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. It sounds like the problem can be stated simply enough: At the moment, nobody knows when the codec should be powered down! Userspace might have some idea, but even if its ideas are right it has no way of communicating them to the kernel. The power/control sysfs attribute was intended for just that purpose, although it was aimed at runtime PM rather than system PM. Nevertheless, it or something like it could be used. Of course, there would still remain the issue of userspace telling the kernel not to power down the codec while making bouncing cow noises -- but at this point it's not really a kernel problem any more. Alan Stern P.S.: What happens if a suspend occurs while a call is in progress, so the codec is left powered up, and then the call ends? Does the system wake up at that point? Or does it stay suspended with the codec still powered, even though it's not needed any more? -- 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 16:10
On Wed, May 05, 2010 at 08:52:50PM +0100, Mark Brown wrote: > On Wed, May 05, 2010 at 08:22:08PM +0100, Matthew Garrett wrote: > > Perhaps you could infer that from the audio routing setup? I don't know > > enough about embedded codecs. > > Yes, you can providing we extract a bit more information from the > machine drivers and/or userspace - we already do our power management > based on paths. The implementation I'd do here is to provide a facility > for marking some of the path endpoints as suspend insensitive then on > suspend leave those endpoints in their current state, force the other > endpoints off temporarily and re-run the standard power checks. One thing that's been mentioned before is that some vendors can swap the kernel much more easily than they can swap userspace, with the added constraint that they have little control over the bootloader. So if there's a userspace interface, it may well also be helpful to provide a kernel hook to allow the platform setup code to configure things. But otherwise, I think that'd work for audio - the only question is whether we need it to be more generic. -- 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/ |