Re: [RFC] A New Power Management API

[Todd Poynor <tpoynor@mvista.com>]

Adam Belay wrote:
> On Fri, 2005-04-15 at 09:50 -0600, Jordan Crouse wrote:
...
>>This is where I see the policy managers taking a greater role.  In
>>addition to the hard coded states (the first five you defined sound fine
>>to me), the user would define a number of pseudo system states as well
>>as define the translation tables for device states under those pseudo
>>states. Each pseudo state would be registered with the PM core and
>>assigned a unique identifier.
> 
> 
> That's an interesting idea.  How would the sysfs interface work?  In
> general, it's challenging to allow the user to define policy
> configuration settings on a per-system-state basis.
> 
> 
>>We would then define a system state flag, say
>>PM_SYSTEM_STATE_PSEUDO, which would prompt a driver to query its policy
>>manager to get the translation for the right device state.  Those
>>devices that don't understand or care about user defined power
>>states would simply ignore the flag.
> 
> 
> I think the policy manager would directly request for a change of the
> state.  Then the driver would handle *suspend.  Although the policy
> manger is code included with the driver, I'd like it to handle any
> decisions.  So it would be the policy manager's job to notice something
> like PM_SYSTEM_STATE_PSEUDO.

As a real-life embedded systems example, I have periodic conversations 
with some folks who design Linux-based mobile phones, and they have 
recently asked for the addition of features that I figure can be 
addressed by approximately just this.

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, and: (a) most drivers take no additional action at system 
suspend, leaving the policy-manager-set power state in place, with some 
exceptions for drivers necessary to run the system right up until sleep 
time; (b) most drivers do nothing at system resume other than those 
needed to get the system up and running (for a mobile phone, say, at 
least mtd subsystem and flash chip driver) and then let userspace policy 
manager decide what power state to place all the devices in.  Their 
products tend to do highly customized things like power back up a small 
subset of devices that were on prior to the sleep, or briefly power up 
previously-off devices to check to see if any important changes in the 
environent occurred during the sleep, etc.

I think either way will work fine for what they're trying to do, am open 
to discuss the merits of either approach.  If anyone has any comments on 
the simplistic kernel method it's appreciated.  Thanks,

-- 
Todd