Re: [RFC][PATCH 00/11] Android PM extensions

["Arve Hjønnevåg" <arve@android.com>]

On Mon, Feb 2, 2009 at 7:27 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> If you'd like a way for the kernel to communicate to userspace that the
> last wakelock has been unlocked, you could use a signal or a select.
> But the simplest way would be to make a process block on reading a
> sysfs file until the last wakelock is released.

I do not want the kernel to communicate to userspace that the last
wakelock has been unlocked, I want it to suspend right away. I was
answering your question about why the kernel needs to be involved. Yes
I could add a notification that tells user-space to suspend again, but
it would not offer any additional functionality over my current
solution.

>> Also, what do you mean by a runtime PM interface?
>
> I'm making a distinction between system PM and runtime (also known as
> dynamic) PM.  With system PM the entire system goes into a low-power
> state -- that's what we mean when we talk about suspend or hibernation.
> With runtime PM the system as a whole remains running while selected
> devices are individually put into a low-power state.
>
> For example, right now Linux will put a USB host controller into a
> low-power state if no USB devices are plugged into it.  This runtime PM
> interface is described in Documentation/usb/power-management.txt.  You
> might want to use some of those mechanisms for controlling your
> devices.

OK, but I don't think this affects our use of wakelocks.

> For example, if one process tries to start an auto-suspend, and at the
> same time another process writes "mem" to /sys/power/state?  Then the
> second process should take precedence and the system should go into
> suspend.  When it wakes up again, the first process would still be
> waiting for an auto-suspend to occur.  I suppose the details don't
> matter much because it's not likely to crop up often.

I'll make a change to make any write to /sys/power/state disable
wakelocks. I'll probably also add a config option to remove
/sys/power/state.

Before I post another patch series I have a few questions:
- Should I merge the wakelock and early-suspend api patches with their
implementations? (I initially implemented the api on top of the old
android_power driver, but we not longer use this)
- Once wakelocks are disabled by writing to /sys/power/state, is there
any demand for re-enabling wakelock support?
- Are there any objections to using /sys/power/request_state to
specify the state to enter when all wakelocks unlocked.

-- 
Arve Hjønnevåg