Re: [RFC] A New Power Management API

[Todd Poynor <tpoynor@mvista.com>]

David Brownell wrote:
> On Friday 15 April 2005 7:53 pm, Todd Poynor wrote:
>...
>>On the other hand, I've been trying to push them toward a simpler-kernel 
>>model in which all the product-specific logic for placing various 
>>devices in designated power states occurs in a userspace power policy 
>>manager,
> 
> So maybe you have some answers for me about why there should need
> to be *any* notion of exporting device power states.  (Rather than
> not caring, and just requiring driver-internal powers states always
> to become consistent with the upcoming system power state.)
> 
> If one takes the notion of userspace managing those states off the table,
> is there any other motivation to expose those device power states? 

So far as I have been able to determine, the usage you describe, as well 
as straightforward individual device power state management (power this 
device off upon receipt of some event, period of inactivity, etc.) is 
common, although with enough flexibility in creating custom system power 
states and reacting to those states in driver power controller objects, 
the second usage may be covered by the first.  I believe in some cases 
power policy management applications are also examining device power 
state to make policy decisions, but I certainly recommend use of 
kernel-to-userspace notification of power events over such polling.  If 
I recall any other more exotic things I've run across I'll post a 
response later.

> I'm pretty sure that supporting this sort of userspace functionality
> won't really fit into the "simpler kernel" rubric.  If for no other
> reason than the self-evident fact that a kernel exporting such stuff
> must have more code than one not exporting it...

It may not be simpler overall on the kernel side (at least prior to 
being customized for a particular policy, for which the in-kernel 
alternative does add some amount of code).  It does, however, place the 
code implementing custom system power states and associated decisions on 
device power states (which might fall under the general category of 
"policy") in userspace and exports just enough kernel interfaces for 
controlling system and device power behavior to let userspace handle it. 
  As I say, though, the userspace vs. kernel home for this isn't a 
matter of strong preference to me, but have suggested userspace device 
state management as arguably more in keeping with prevailing winds of 
kernel development.

I don't mean to get hung up in the terminology, but I wouldn't call 
relatively infrequent changes to fairly large-grained device power 
states "micro-policy management" either -- there is plenty of room for 
more frequent, possibly finer grained, changes to device power 
characteristics in driver code based on device state or hardware 
capabilities (auto clock gating, power up/down according to app use...), 
the aggressiveness of which may also be a policy consideration to be 
configured, perhaps from userspace (at least MacOS seems to have such 
interfaces).

-- 
Todd