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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Monday 09 February 2009, Arve Hjønnevåg wrote:
> 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.

I don't really see how the early-suspend helps here.  Can you please explain?

> > 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.

Ah, that's interesting.  So in fact you want some devices to go into low power
states as soon as the screen is off and that's why you fint the early-suspend
useful.  Is this correct?

> > 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.

You can still have it, to some extent, by implementing the routines for getting
and releasing the reference appropriately.

Still, I'm very much interested in your reply to the last paragraph of my
message, the one that you removed.

Thanks,
Rafael