Posted May 20, 2010 12:17 UTC (Thu) by iq-0 (subscriber, #36655)
Parent article: Blocking suspend blockers
I'm probably missing some things, but in my view these "suspend blockers" are nothing more than a simple semaphore lock around the "deep suspend" resource. And as such it is nothing more than a very basic synchronization mechanism between a lot of concurrently running processes.
To put it differently: I don't think "suspend blockers" actually add something new, they just move the "device not ready for suspending" synchronized flag out of the driver and into the generic kernel. The "userspace can inhibit suspend" is nothing more than a N-th party acquiring the "lock".
This "lock" would logically be something very close to the device structure used for other stuff (thus the "system" cannot suspend, because a "bus" cannot suspend, because a "device" has the "suspend lock" but the rest can be suspended). So this would effectively be a hierarchical locking scheme where releasing the lock would switch that part of the hierarchy to the default idle state.
This default idle state would for normal (classic PM) probably be simply to let the device be turned on (or put in a shallow power state in laptop mode) and in the aggressive power-save state it would immediately put all resources in that subtree in a deeper power state.
Userspace could simply control this "wanted powerstate" attribute given external observation (how it's done now) and the "locking" would prevent the system from powering down devices that are in a critical region until they're done.
The tricky bits in suspend are normally the interdependencies between devices that are powered down and devices that want to power down. But the "aggressive power-save" state should still inhibit devices (or even wake them) when others really need them (a simple write to disk would probably have to wait, but a read is blocking someone).
There ofcourse always subtle behaviours to take care of, but the general idea of locking could possibly apply to simple suspend as well. And one doesn't really have to write code to put devices in as deep a sleep as possible but the rather easier: don't power down during this critical region.