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

[Brian Swetland <swetland@google.com>]

On Tue, May 4, 2010 at 5:22 PM, Rafael J. Wysocki <rjw@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