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

Uli Luckas
2009-02-02T16:24:29Z

On Monday, 2. February 2009, Alan Stern wrote:
> 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.
>
Actually i don't know. Arve?
Things would get a lot less complex if we could leave the early suspend stuff
out of the kernel.

Uli

--

------- ROAD ...the handyPC Company - - - ) ) )

Uli Luckas
Head of Software Development

ROAD GmbH
Bennigsenstr. 14 | 12159 Berlin | Germany
fon: +49 (30) 230069 - 62 | fax: +49 (30) 230069 - 69
url: www.road.de

Amtsgericht Charlottenburg: HRB 96688 B
Managing director: Hans-Peter Constien