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

From: Rafael J. Wysocki
Date: Mon May 17 2010 - 16:21:09 EST

On Monday 17 May 2010, Brian Swetland wrote:
> On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote:
> > 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.

And as I said, I regard this as a legitimate approach to power management.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at