Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys interface

[Adam Belay <ambx1@neo.rr.com>]

On Sat, Jan 07, 2006 at 11:20:13AM +0100, Pavel Machek wrote:
> On So 07-01-06 02:58:51, Adam Belay wrote:
> > The driver core can provide some infustructure, but let's leave the states
> > up to the drivers.  Afterall, some drivers might only be interested in "on"
> > during runtime.  Also, drivers might support some sort of partial-off
> > but not "off".
> 
> Then they map "off" to "as much off as I can". Big deal.

Yes, but it may not be the kernel's place to make this generalization.

> 
> > And no, this does not allow us to experiment with PCI power
> > management.
> 
> Well, suse was already doing experiments with 2.6.14 sysfs...

Sure one can see how much power is saved by entering D3, but than can
even be done through userspace.  I think it's more important to
experiment with schemes that will actually be useful and reliable to the
end user.

> 
> > Also there's nothing "runtime" about the PCMCIA PM API.  It's much more
> > like calling ->remove() as it disabled the device all together.  
> 
> It looks enough runtime to me.

As was already discussed, we don't want to modify every userspace
application to check if the device it needs is "on" (resumed) or
"off" (suspended).  It's just two painful with third party apps etc.
Therefore, the kernel needs to handle this more seemlessly.  In my
opinion, this is what runtime power management is all about, saving
power without getting in the user's way.

> 
> > I'm more
> > interested in saving power without crippling functionality.
> 
> You are on wrong mailing list, then. Seriously. If you can save power
> without affecting functionality, then just doing, you don't need any
> userland interface.

Cool it, affecting functionality and disabling it are not the same
thing.  I'm fairly certain this mailing list is interested in exploring
more than suspend/resume (i.e. "on" and "off"), even if it can be hacked
to happen during runtime.

This issue depends on the platform and device class.  Some device
classes will have more user initiated power transitions than others.
With that in mind, even drivers with exclusively kernel-space control
will want to export knobs and tunables for timeout values etc.  A
userland interface if important regardless of kernel-side
implementation.

-Adam