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

Pavel Machek
2009-02-09T09:09:35Z

> 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 put the device to low power mode when its close() is called, and I
pull it back up when open() is called....? Every well-behaved driver
should do that, even on PC.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html