Re: [PATCH 05/13] PM: Add option to disable /sys/power/state interface

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

On Sun, 8 Feb 2009, Arve Hjønnevåg wrote:

> How do you handle devices that should be in a low power mode when
> closed, and a high(er) power mode when open. While adding
> early-suspend hooks to a driver may be ugly, it does not need any more
> support than open and close does.

This illustrates some of the problems of differing outlooks.  In an 
embedded system, the set of devices is limited and the set of available 
power states is known beforehand.  In other settings neither of these 
is true.

Early-suspend is an example of a partially-functional system state.  
In your Android-centric approach, early-suspend is centered around the 
screen.  But other sorts of systems way well have other requirements 
and may want their partially-functional system state to be centered 
around something else.  Or they may want to have more than one 
partially-functional system state.

What we need is a mechanism capable of accomodating all these different
requirements.  Presumably the core kernel would provide the hooks but
the implementation details would be left up to platform-specific code.  
There should be a generic scheme for representing partially-functional
system states, together with a list of devices to be put in low-power
mode for each state and an indication of which low-power mode to use
(since a device can have more than one low-power mode).  Device drivers
should have an interface for going into a particular low-power state.

The extent to which all of this needs to be split between the kernel
and userspace isn't immediately clear.  Latency issues might force a
large part of it to live in the kernel.  On the other hand, if the list
of devices & modes can be pushed out to userspace, then the in-kernel
portion could end up being nothing more than a runtime-PM mechanism of
the sort we have been discussing for years.

Alan Stern