Re: [linux-pm] [PATCH] Custom power states for non-ACPI systems

[David Brownell]

On Thursday 03 March 2005 8:49 pm, Nigel Cunningham wrote:
> > 
> > ... the goal of letting the system use those low
> > power modes more generally, without needing user(space) input to
> > suggest that now would be a good time to conserve more milliWatts.
> > 
> > Of course, on systems that don't swap (or swsusp) there may be
> > dozens of different low-power "standby" states.  I'm not sure it
> > helps to try labeling them all through /sys/power/files.
> 
> It seems to make a lot of sense to me for us to make a split between
> capability/implementation and policy, and move the policy stuff to
> userspace. 

But what's a "policy"?  And what's its scope?  When the device drivers
can cheaply turn their clocks on/off depending on whether their hardware
is in use, there's little point in having control knobs for that.  And
considering debug and testing, such knobs create pain and trouble.

Yet each different clock that can be gated creates a different family of
such low power "standby" states... all subtly different combinations
of active clocks.  I counted over six dozen clocks on one SOC; do the
math, it's hard to justify userspace caring about that many states!!
(Some characteristics may matter though, e.g. whether the 48 MHz PLL
is currently active or not.  If not, more aggressive power saving modes
might be available.)

There's a cost to having userspace make decisions.  When that cost can
exceed the power savings, it's probably best not to get it involved.

There are policy decisions that probably make sense in userspace,
like "backlight off"; and ones that certainly don't make sense there
(like IMO almost all clock gating decisions).


> Drivers could also interact with each other to communicate status
> changes (eg USB drivers notify parent HUB of their removal).

Actually it works the other way around:  hub status change events
are used to detect device removal, then the device gets told.
I think most hotpluggable busses work that way:  PCMCIA/CF, MMC,
CardBus, FireWire, PCI Hotplug, and so on.


> This is, of 
> course, the more complicated bit. Since this is the implementation (and
> not policy), however, userspace doesn't need to be involved. This
> separation should simplify things. My USB hub driver knows what its
> children are via the driver model. It doesn't need to receive a message
> from userspace to tell it to sleep because it has nothing to do.

Right, but there are important PM scenarios lurking there.  There's the
example of USB mice autosuspending, to enable root hubs to suspend,
allowing DMA to stop, and thus enabling C3 CPU mode, and saving 2 Watts
on top of the power no longer being supplied to that bus-powered mouse.
(And the same could be done for some other USB devices.)  This is,
you'll note, purely device power management ... it's all in the same
ACPI system state, S0.  (Though the mouse can probably be used to wake
the system from S1, S2, or S3 later on ...)

What we've discussed so far is that the only policy setting there
would be a module parameter for the HID driver, saying whether to
start that sequence after N seconds.  For the other drivers, CONFIG_PM
would seem to be enough of a request.


> With an implementation along these lines, I think we'll have a good
> basis for getting runtime power management and system states into a
> usable state.

Using DBUS to allow active policy (re)decisions could work, but I'd
also like to see most PM policies not need to swap in DBUS.  Sysfs
is a fine place to record policy decisions (though the cost of each
new attribute is less memory available for Real Work).

Do you have examples of PM policies where a DBUS agent would need
to make choices on the fly?  

- Dave


> 
> Regards,
> 
> Nigel
> -- 
> Nigel Cunningham
> Software Engineer, Canberra, Australia
> http://www.cyclades.com
> Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028;  Mob: +61 (417) 100 574
> 
> Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de
> 
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/