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

[Brian Swetland <swetland@google.com>]

On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
> On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
>>
>> In addition, it will likely cause duplicate work to be done in
>> drivers.  Presumably, PM aware drivers will want to know if the system
>> is in opportunistic mode.  For example, for many drivers, doing
>> runtime PM may not be worth the effort if the system is in
>> opportunistic mode.
>
> Why? If a device is not in use it should be off regardless of what
> state the rest of the system is in.
>
>> This last point is especially troubling.  I don't find it a comforting
>> path to go down if the drivers have to start caring about which PM
>> policy is currently in use.

I'll echo Arve here -- all drivers should seek to be in the lowest
power state possible at all times.  We've never suggested that
suspend_block is a substitute for that.

Suspend blockers give us some flexibility on systems where runtime pm
will not get us all the way there. If you can meet your power needs
without needing suspend blockers, awesome, you don't need them on that
platform.  The patchset Arve sent out makes this feature an
off-by-default kernel configuration option that compiles out to no-ops
when disabled.

In our experience, periodic timers and polling, both userspace side
and kernelside make suspend blockers a win even on platforms like OMAP
which have pretty flexible hardware power management.  Going to low
power states in idle results in higher average power consumption than
going to the same states in full suspend, at least on Android devices
shipping today.

Brian