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

[Todd Poynor <tpoynor@mvista.com>]

Nigel Cunningham wrote:
...
> Two way communication between a userspace policy manager and kernel
> drivers is implemented via DBus.
> 
> In this scheme, 'kernel drivers' doesn't just refer to the drivers for
> hardware. It refers to anything remotely power management related,
> including code to implement suspend-to-RAM, to disk or the like, ACPI
> drivers or code to implement system power states.
> 
> The policy manager can enumerate devices and inter-relationships,
> capabilities, settings and status information, set and query policies
> and implementation results. The drivers can notify events. This
> communication doesn't use complicated structures or type definitions.
> Rather, all the nous regarding interpretation of the messages that are
> sent is in the policy manager and the drivers. One driver might say it's
> capable of states called "D0, D1 and D3", another (system) states called
> "Deep Sleep" and "Big Sleep". Nothing but the driver itself and
> userspace manager need to how to interpret & use these states.
> 
> Inter-relationships between drivers are _not_ included in this
> information. The policy manager sets policy, the drivers deal with the
> specifics of implementing it.

This all sounds exactly like the way we're headed as well, so I'm 
definitely interested in anything I can do to help.  Was thinking that 
can start defining kobject_uevent power events and attributes (with 
enough detail that acpid could use it instead of /proc if the ACPI 
drivers were to convert to it).

Capturing the relationships between drivers is difficult.  If nobody's 
already looking into this then I'll take this up soon.

> The userspace manager can in turn [en|dis]able capabilites and send a
> list of run-time states that the driver can move between according to
> its own logic (eg lack of active children) without notifying the
> userspace manager. This would fit in with your power modes above, even
> to the level of "cpu idle".

At dynamicpower.sf.net we do something similar for cpufreq-style scaling 
of platform clocks and voltages, setting up desired policy for various 
platform clocks/voltages according to changes in low-level system state 
(primarily scheduler state) from userspace and then letting the state 
machine run without interaction.  Similar policy objects for devices 
sounds intriguing, although the device-specific nature of event triggers 
probably makes this quite difficult.

Mac OS X support for some of these concepts is documented at 
developer.apple.com, looking for ideas to steal...  Thanks,


-- 
Todd