Re: [PATCH 0/8] Suspend block api (version 6)

[Rafael J. Wysocki]

On Wednesday 05 May 2010, Mark Brown wrote:
> On Tue, May 04, 2010 at 10:23:41PM +0200, Rafael J. Wysocki wrote:
> > On Tuesday 04 May 2010, Kevin Hilman wrote:
> > > Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> 
> > Guys, please.
> 
> > The opportunistic suspend feature is _not_ to replace runtime PM by any means!
> 
> Certainly in my case and I think Kevin's I agree with the need for the
> bodge at the minute if we can get a clearer idea of how it's supposed to
> work.
> 
> > when to put devices into low power states and save energy this way.  Still,
> > even if all subsystems do that 100% efficiently, there may be more savings
> > possible by putting the entire system into a sleep state (like on ACPI-based
> > PCs) and we can reach there by runtime PM alone.
> 
> Right, this is likely to be a win for PCs - for embedded systems we
> rarely have other software to interoperate with so if you can make the
> hardware do it then it's unlikely there would be any fundamental issue
> with Linux doing it at runtime.

Evidently, the Android developers had a problem with that.  Of course, you can
argue that they didn't consider using runtime PM for this purpose, but the real
question is how much time it would take to achieve the same level of energy
saving using runtime PM without opportunistic suspend.

> > > > I'd be a lot more comfortable with this if it came with a mechanism for
> > > > communicating the intended effect of a suspend on a per-device level so
> > > > that the drivers have a clear way of figuring out what to do when the
> > > > system suspends.  If there isn't one we can add subsystem or driver
> > > > specific hooks, of course, but it'd be better to address this at the
> > > > system level.
> 
> > > I agree.
> 
> > I'm not sure.  Why _exactly_ would you need that?
> 
> The use case that causes serious issues with this at the minute in the
> domains I work is this:
> 
> 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,
> which are either integrated or directly connected by analogue or digital
> audio links on the board.  If the user has the phone to their ear and is
> talking away with the screen blanked then the AP is just waiting for
> input, will appear idle and so trigger an opportunistic suspend.  If the
> audio CODEC is managed by Linux (as is standard) then running through
> the suspend process will as things stand cause the audio subsystem to be
> suspended.  Since in the normal course of affairs suspend means power
> down that's what will happen, but this is clearly highly undesirable in
> this situation.

In that case someone (either a driver or, most likely, user space) will need to
keep a suspend blocker active.

> 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.

My understanding is that on Android suspend blockers are used for this
purpose.

> 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.

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).

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/