> This patch series adds a suspend-block api that provides the same> functionality as the android wakelock api. This version fixes a race> in suspend blocking work, has some documentation changes and> opportunistic suspend now uses the same workqueue as runtime pm.

Earlier this month, several folks intersted in embedded PM had a BoFas part of the Embedded Linux Conference[1] in San Francisco. Many ofus had concerns about wakelocks/suspend-blockers and I wanted to sharesome of mine here, since I don't know if embedded folks (other thanGoogle) were included in discussions during the LF Collab summmit.

I hope other embedded folks will chime in here as well. My backgroundis in embedded as one of the kernel developers on the TI OMAP SoCs,and I work primarily on PM stuff.

My comments are not about this implementation of suspend blockers inparticular, but rather on the potential implications of suspendblockers in general.

Suspend blockers vs runtime PM------------------------------My primary concern is that suspend blockers attempt to address thesame problem(s) as runtime PM, but with a very different approach.Suspend blockers use one very large hammer whereas runtime PM handsout many little hammers. Since I believe power management to be aproblem of many little nails, I think many little hammers are bettersuited for the job.

And with the addition of suspend blockers we have something inbetween. In my simple world, I think of suspend_blockers as static PMwith a retrofit of some basic dynamic capabilities. In my view, apoor man's dynamic PM.

The current design of suspend blockers was (presumably) taken due tomajor limitations and/or problems in dynamic PM when it was designed.However, since then, some very signifcant improvements in dynamic PMhave come along, particularily in the form of runtime PM. What Istill feel is missing from this discussion are details about why theissues addressed by suspend blockers cannot be solved with runtime PM.

It seems to me the keypad/screen example given in the doc can veryeasily be solved with runtime PM. The goal of that example is thatthe keypad not turn on the screen unless a specific key is pressed.That is rather easy to accomplish using runtime PM:

1. system is idle, all devices/drivers runtime suspended (display and keypad drivers are both runtime suspended)- keypress triggers wakeup ->runtime_resume() of keypad (screen is still runtime suspended)- key press trickles up to userspace- keypad driver is done, goes idle and is runtime supended- userspace decides whether or not to turn on screen based on key- if not, goto 1, (display is still runtime suspended)- if so, start using display and it will be runtime resumed

I realize this keypad example was only one example usage of suspendblockers, but I suspect the others would be solved similarily usingruntime PM.

But anyways, to get back to the main point:

I feel the main problems tackled by _kernel_ suspend blockers (as Iunderstand them) are the same problems already addressed by runtimePM. First and formost, both have the same guiding principle:

- keep device PM independent of other devices (e.g. don't wake up screen just because keypad was pressed)

- wakeups/events can be handled in a device specific way, without affecting other devices or rest of the system, unless desired

So, the goals are the same, but the approaches are different. RuntimePM makes each of the drivers and subsystems do the work, where suspendblockers just forces the issue from on high. IMHO, the more flexibleand generic approach of runtime PM is more suited to a general purposekernel than the one-big-hammer approach currently taken by suspendblockers.

What about PM aware drivers?----------------------------All of this brings up a second major concern regarding how to write PMaware drivers.

At least from the kernel perspective, both suspend blockers andruntime PM have the same goal. Given that, which framework should thedriver writer target? Both? Seems like duplicate effort. Usingsuspend blockers assumes the system is in opportunitstic suspend modeand (at least in the keypad example given) assumes a suspend-blockeraware userspace (Android.) Without both, targeted power savings willnot be acheived.

To me, runtime PM is a generic and flexible approach that can be usedwith any userspace. Driver writers should not have to care whetherthe system is in "opportunistic" mode or about whether userspace issuspend blocker capable. They should only have to think about whenthe device is (or should be) idle.

From my experience with OMAP, we *really* do not want to care aboutwhat userspace is or isn't capable of, or what suspend-mode the kernelis in. Among other things, the OMAP linux kernel is used in the NokiaN900 (Maemo), the Motorola Droid (Android) and the Palm Pre (webOS).Comments on the future of each SW stack aside, we really want to runthe same kernel and drivers across all of those platforms as well aswhatever comes next.

What about dumb or untrusted apps?---------------------------------------In my view, the truly significant difference between suspend blockersand runtime PM is what happens to userspace. So far, to me the onlycompelling argument for suspend blockers is the goal of forciblyshutting down userspace and thus forcing the system into idle(although drivers could still reject a suspend request.)

Again, since suspend blockers were designed, there have been majorefforts to track and fix userspace as well as underlying timer issues(deferrable timers, coalescing, timer slack ...) that led tounnecessary wakeups from userspace. Wouldn't it be better to spendour collective efforts in continuing in that direction instead of justhiding the underlying problems by forcing suspend? Fixing the rootcauses will be better for everyone, not just those using Android.

And if untrusted userspace apps remain as the major problem, maybe weshould aim for a solution directly targetting that problem. I'm justshooting from the hip now, but maybe containing (cgroups?) untrustedprocesses together into a set that could be frozen/idled so that runtime PMwould be more effective would be a workable solution?

Anyways, that's enough rambling for now. I hope that sheds some lighton the concerns I have with suspend blockers.