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

[Brian Swetland <swetland@google.com>]

On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
> Hi,
>
> On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
>> We (Google) would like to allow completely open app distribution with
>> minimal hurdles, and avoid the walled garden approach.  Toward this
>> goal we're not even requiring the use of a central app store for
>> distribution.
>
> I understand that, but still we should be telling developers what
> they're doing wrong so that they can improve themselves as professionals
> and still make the final device better.

I agree.  Which is why we develop tools to help developers understand
what their apps are doing.

>> For a large majority of apps, running in the background while the
>> device is asleep (screen off) is not essential, they don't request the
>> "keep device awake" permission, never hold a wakelock, etc.  Those
>> that do need to do this have the permission, may hold suspend
>> blockers, and are accounted for.
>
> but can anyone write an app that holds a suspend_blocker ?? If so, then
> your goal is already broken, right ? I mean, if anyone can keep a
> suspend_blocker held forever, you'll never ever sleep, right ? While
> with runtime, if you keep the keypad open, only the keypad and the paths
> directly related to it (probably the i2c controller and the power domain
> where the i2c controller sits) will be kept alive, no ?

No, you'll never suspend, which is different from never going to the
lowest CPU power state.  On shipping Android devices we aggressively
completely power down the CPU in idle whenever we can (based on
latency requirements generally).  We power off peripherals whenever
they're not in use.

This is why I've stated previously that I don't think runtime PM and
opportunistic suspend are competitive features.  Everyone who cares
about minimizing power should want runtime pm or at least similar
functionality (our drivers have always powered down peripherals when
not in use, even while the device is open, etc, prior to the existence
of runtime PM).

If your environment is such that going to full suspend will not gain
you anything, then don't use opportunistic suspend.  We find that
there are savings to be had with this model in Android which is why we
use it.  If you are going to use opportunistic suspend,
suspend_blockers provide useful functionality.

Brian