Adam - Nice stuff. A few comments. First, a question: Is it safe to assume that PMU devices (like these: http://www.dialog-semiconductor.com/template.php?page_id=62) would fall under the category of Power Resources? if so, we may need to consider some more advanced hooks than just on/off. Secondly, I have some comments regarding the system states, especially the last three. While those three states are important, right off the bat I can think of several scenarios where additional power states could be imagined. I fear that if we hard code these states, then every individual with a slightly different usage model on a given platform would have to patch the kernel accordingly. This isn't such a far fetched scenario on an embedded platform. 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. 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 that way we could keep things simple for for the laptop / desktop folks while still providing a bit of flexibility on the embedded side of things. Regards, Jordan -- Jordan Crouse Senior Linux Engineer AMD - Personal Connectivity Solutions Group <www.amd.com/embeddedprocessors>
