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

On Sat, Jan 07, 2006 at 11:20:13AM +0100, Pavel Machek wrote:

On So 07-01-06 02:58:51, Adam Belay wrote:

quoted

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.

quoted

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.

quoted

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.

quoted

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