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

Arve Hjønnevåg
2009-02-08T23:58:12Z

On Sun, Feb 8, 2009 at 3:40 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Sunday 08 February 2009, Brian Swetland wrote:
>> Out of curiosity, do these changes provide a model where the system can
>> be in suspend 99+% of the time, waking up for specific events
>> (voice/data telephony, user interaction, etc), and rapidly returning to
>> suspend when the processing required is complete?
>
> The changes I was referring to above were rather related to the "normal"
> suspend (ie. the one happening as a result of writing "mem" into
> /sys/power/state). Namely, we believe that for some devices it is not
> necessary or even desirable to allow the driver to perform all of the power
> management operations by itself. For example, we are going to make the PCI
> PM core (which in fact is the PCI bus type driver) handle the saving and
> restoration of PCI devices' configuration registers as well as putting the
> devices into low power states and back into the full power state. We can do
> that, because in the "normal" suspend code path the suspend routines of a
> driver are executed by the appropriate bus type's suspend routines and not
> directly by the PM core. The "early suspend" mechanism seems to go round this
> by calling directly into device drivers.

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.

> Also, please observe that if there is a mechanism allowing us to put individual
> devices, or entire subsystems (such as a bus with devices attached to it), into
> low power states at run time, without placing the entire system in a sleep
> state, and put them back into the full power state as needed, we won't need
> anything like the "early suspend" introduced by this series of patches.

While early-suspend is not needed, it is still convenient on an
embedded device where some drivers are clearly only used when the
screen is on.

> As far as the wakelocks are concerned, the goal they are designed to achieve is
> quite simple: you want to prevent suspend from happening in certain situations.
> In principle, one flag is sufficient for that. Still, there are many code
> paths that might set and unset this flag and it would have been bad if the flag
> had been set by one code path and then immediately unset by another one.
> To prevent this from happening one can use a reference count with the rule that
> suspend can only happen if it is equal to zero.

We also want accountability.

--
Arve Hjønnevåg