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. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
