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

[Alan Stern <stern@rowland.harvard.edu>]

On Mon, 2 Feb 2009, Uli Luckas wrote:

> On Sunday, 1. February 2009, Alan Stern wrote:
> > Early-suspend seems to be a completely different matter.  In fact it
> > isn't a suspend state at all, as far as I understand it.  It's more
> > like what you get simply by doing a runtime suspend on some collection
> > of devices.  I don't see that the kernel needs to treat it as a special
> > state, and in might be possible to have a user program manage the whole
> > thing -- provided the drivers in question implement runtime power
> > management (as USB has done).
> >
> > Alan Stern
> 
> Except you always want early-suspend and auto-suspend at the same time. The 
> idea is, if all display of system states is off (early-suspend), we can 
> enable or disable the cpu at will (auto-suspend) because nobody will notice. 

Why should the kernel have to get involved?  Why can't userspace manage 
both early-suspend and auto-suspend?

That is, consider the following: Userspace initiates an early-suspend
by using a runtime PM interface to turn off the screen and some other
devices.  After a short time, if they are still off, then userspace can
initiate an auto-suspend by writing "auto-mem" to /sys/power/state.

All the kernel would need to know is the difference between
auto-suspend and normal suspend: one respects wakelocks and the other
doesn't.

Alan Stern