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: Brian Swetland on 4 May 2010 21:20 On Tue, May 4, 2010 at 5:22 PM, Rafael J. Wysocki <rjw(a)sisk.pl> 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. > > Suspend really is a sledgehammer thing. Either you suspend the whole system > or you don't suspend at all. You can prevent opportunistic suspend from > happening using suspend blockers (that's what they are for), but that's pretty > much everything you can do about it. If you want power savings while some > parts of the system are active, use runtime PM for that. > > What I'd use opportunistic suspend for is not the saving of energy when there's > a call in progress, because in that case some parts of the system need to be > active, but to save energy when the device is completely idle, ie. the user > interface is not used, music is not played "in the background" etc. (my phone > is in such a state 90% of the time at least). We actually do use opportunistic suspend for cases like this on Android today. It mostly comes down to a question of latency for return from full suspend. For example: Some MSM7201 based devices typically resume from power collapse in 3-5ms, but absolute worst case (because the L1 radio services are higher priority than the wake-the-apps-cpu services) is ~90ms. On these devices we hold a suspend_blocker while playing audio. Before discovery of this we went into full suspend while playing audio which worked fine, but in certain network conditions we would drop buffers if we could not wake fast enough. So, it's somewhat system dependent, but it can be very helpful in a lot of cases. Brian -- 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 07:10 On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote: > On Wednesday 05 May 2010, Mark Brown wrote: > > On a mobile phone when the system is in a voice call the data flow for > > the call is entirely handled outside the CPU (normally referred to as > > Applications Processor or AP here) by the baseband and audio CODEC, > In that case someone (either a driver or, most likely, user space) will need to > keep a suspend blocker active. That is not actually what Android systems are doing, and if it is what's supposed to happen then I'd really expect to see a patch to ASoC as part of this series which shows how this is supposed to be integrated - it's the sort of thing I'd expect to see some kernel space management for. Honestly I don't think that's a very good solution for actual systems, though. A part of the reasoning behind designing systems in this way is allowing the AP to go into the lowest possible power state while on a voice call so it doesn't seem at all unreasonable for the system integrator to expect that the AP will be driven into the standard low power state the system uses for it during a call and in a system using opportunistic suspend that's suspend mode. > > 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. > Suspend really is a sledgehammer thing. Either you suspend the whole system > or you don't suspend at all. You can prevent opportunistic suspend from > happening using suspend blockers (that's what they are for), but that's pretty > much everything you can do about it. If you want power savings while some > parts of the system are active, use runtime PM for that. On the one hand that's the answer that works well with the existing Linux design here so great. On the other hand as discussed above that doesn't match so well with user expectations. > What I'd use opportunistic suspend for is not the saving of energy when there's > a call in progress, because in that case some parts of the system need to be > active, but to save energy when the device is completely idle, ie. the user > interface is not used, music is not played "in the background" etc. (my phone > is in such a state 90% of the time at least). Remember that even in your full system suspend the system is not actually fully idle - the baseband is still sitting there looking after itself, keeping the phone on the network. The only difference between on call and off call from the point of view of the Linux system is that there is an active audio path which happens to have been set up by the Linux system. -- 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: Brian Swetland on 5 May 2010 08:10 On Wed, May 5, 2010 at 4:06 AM, Mark Brown <broonie(a)opensource.wolfsonmicro.com> wrote: > On Wed, May 05, 2010 at 02:22:30AM +0200, Rafael J. Wysocki wrote: >> On Wednesday 05 May 2010, Mark Brown wrote: > >> > On a mobile phone when the system is in a voice call the data flow for >> > the call is entirely handled outside the CPU (normally referred to as >> > Applications Processor or AP here) by the baseband and audio CODEC, > >> In that case someone (either a driver or, most likely, user space) will need to >> keep a suspend blocker active. > > That is not actually what Android systems are doing, and if it is what's > supposed to happen then I'd really expect to see a patch to ASoC as part > of this series which shows how this is supposed to be integrated - it's > the sort of thing I'd expect to see some kernel space management for. > > Honestly I don't think that's a very good solution for actual systems, > though. A part of the reasoning behind designing systems in this way is > allowing the AP to go into the lowest possible power state while on a > voice call so it doesn't seem at all unreasonable for the system > integrator to expect that the AP will be driven into the standard low > power state the system uses for it during a call and in a system using > opportunistic suspend that's suspend mode. Yup. And that's exactly what happens on the platforms we've shipped on so far -- the apps side of the world fully suspends while in a voice call. Some events (prox sensor, buttons, modem sending a state notification) will wake it up, of course. I haven't spent much time looking at alsa/asoc yet, but it's on my list for 2010 -- I'm hoping to migrate the very simple audio drivers I wrote for the msm platform originally to actually be alsa drivers as part of the general "try to use existing interfaces if they fit" plan we've been working toward. The suspend_block system gets us what we need today (well what we needed three years ago too!) to ship and hit reasonable power targets on a number of platforms. There's been a lot of various handwaving about "android kernel forks" and what have you, but here we are again, trying to work out perhaps the only "new subsystem" type change that our driver code depends on (almost all other contentious stuff is self contained and you can take or leave it). Our hope here is to get something out there in the near term so that the various drivers we maintain would "just work" in mainline (your choice of if you use suspend_block or not -- it's designed to be an option) and we can move forward. If in the future runtime power management or other systems completely obsolete suspend_blockers, awesome, we remove 'em. Brian -- 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 10:00 On Wed, May 05, 2010 at 05:00:33AM -0700, Brian Swetland wrote: > I haven't spent much time looking at alsa/asoc yet, but it's on my > list for 2010 -- I'm hoping to migrate the very simple audio drivers I > wrote for the msm platform originally to actually be alsa drivers as > part of the general "try to use existing interfaces if they fit" plan > we've been working toward. Yup, that'd be good - even with the AP/CP/CODEC SoCs like the MSM devices we really need to get ASoC integration since systems are being built hanging external components such as speaker drivers off the line outputs, and some of those have registers so really do benefit from the sequencing, automated PM and so on that ASoC offers. There was some work on MSM ASoC support posted last year back but there were a number of review issues with it. Daniel Walker also talked about submitting stuff just before Christmas, quite possibly independently of the other work which looked like a community effort, but I've not seen anything through from that yet. > The suspend_block system gets us what we need today (well what we > needed three years ago too!) to ship and hit reasonable power targets > on a number of platforms. There's been a lot of various handwaving > about "android kernel forks" and what have you, but here we are again, > trying to work out perhaps the only "new subsystem" type change that > our driver code depends on (almost all other contentious stuff is self > contained and you can take or leave it). > Our hope here is to get something out there in the near term so that > the various drivers we maintain would "just work" in mainline (your > choice of if you use suspend_block or not -- it's designed to be an > option) and we can move forward. If in the future runtime power > management or other systems completely obsolete suspend_blockers, > awesome, we remove 'em. Like I've said a few times here I broadly agree with your goals - they seem to be a reasonable solution to the engineering problems we face presently, even though they're not where we actually want to be. What I do miss from the current proposal is more consideration of how things that do need to ignore the suspend should integrate. 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. This hasn't been a pressing issue while the Android code is out of tree since we can just say it's an out of tree patch that has a different design approach to current mainline and it's fairly straightforward for users to introduce suitable system-specific changes. Once it's mainline and part of the standard Linux PM toolkit then obviously subsystems and drivers need to support opportunistic suspend properly in mainline. -- 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 11:40
On Wed, 5 May 2010, Mark Brown wrote: > Now, the solution here if we're going to use opportunistic suspend like > this is to provide some method for the audio subsystem to figure out > that the system doesn't actually want it to suspend when it gets told do > do so. Like I say ideally we'd provide some standard interface in the > PM subsystem for userspace to communicate this to subsystems and drivers > so that we've got a joined up story when people run into issues in cases > like this, though obviously if this goes in then we'll have to put in > something subsystem or driver specific for affected areas. I know what > I'd implement generically for audio, but I've held back since the option > is fairly messy when not used in conjunction with a deliberate choice to > use opportunistic suspend and I was expecting a standard mechanism to > slot into to provide control for userspace. > > 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? 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/ |