Re: [PATCH] implement pm_ops.valid for everybody

Guennadi Liakhovetski
2007-03-23T21:08:04Z

On Fri, 23 Mar 2007, David Brownell wrote:

> On Thursday 22 March 2007 11:46 pm, Guennadi Liakhovetski wrote:
> > On Thu, 22 Mar 2007, David Brownell wrote:
> >
> > > So the fundamental definition needs to be in relative terms,
> > > because platform-specific differences otherwise make trouble.
> >
> > What if we define system-wide and per device power states in terms of
> > time? Time needed for the system / device to become fully operational
> > again? And you'd need a user-space calibration daemon...
>
> So if you take two otherwise identical systems and clock one slower
> than the other, then "standby" may become "suspend-to-RAM"?
>
> Yuck. No. Speed is only a factor in that STR is likely slower.

I'm just trying to think about it from the user perspective. As a user I
want - save the system save some power but be ready again when I need it
_not_ _later_ than, 10 sec after wakeup. I don't care how it is called. I
want to save as much power as possible and I want a certain wakeup time.
Yes, if one system in your example is clocked slower, then yes, saying "I
want it back up and running 5 seconds after wakeup" will for one of them
mean "standby" for another one "str". As a user I don't care whatsoever
what PCI state you drive my eth card into. I want it back in 5 seconds.

Similarly for single devices: I don't need wlan now, but when I need it I
want it to be available in less than 2 seconds.

And if I say 10 minutes hibernate it.

If I say "don't care about time, save maximum power" - similarly.

And I may say "I want it wakeable from eth" or "from modem" take that into
account too.

Those would be policies to be implemented in the user space. The kernel
might just present a single numerical per-device parameter "wakeup
responsiveness", and a way to do this system-wide.

Thanks
Guennadi
---
Guennadi Liakhovetski