Re: [linux-pm] PowerOP 1/3: PowerOP core

[Todd Poynor <tpoynor@mvista.com>]

Geoff Levand wrote:

> I'm wondering if anything could be gained by having the whole 
> struct powerop_point defined in asm/powerop.h, and treat it as an 
> opaque structure at this level.  That way, things other than just 
> ints could be passed between the policy manager and the backend, 
> although I guess that breaks the beauty of the simplicity and would 
> complicate the sys-fs interface, etc.  I'm interested to hear your 
> comments.

Making the "operating point" data structure entirely platform-specific 
should be OK.  There's a little value to having generic pieces handle 
some common chores (such as the sysfs interfaces), but even for integers 
decimal vs. hex formatting is nicer depending on the type of value. 
Since most values that have been managed using similar interfaces thus 
far have been flags, register values, voltages, etc. using integers has 
worked well and nicely simplified the platform backend, but if there's a 
need for other data types then should be doable.

> Another point is that a policy manager would need to poll the system 
> and/or get events and then act.  Your powerop work here only provides 
> a (one way) piece of the final action.  Any comments regarding a more 
> general interface?

What's discussed here is probably the bottommost layer of a power 
management software stack: to read and write the platform-specific 
system power parameters, optionally arranged into a mutually-consistent 
set called an "operating point".  Power policy management is a large, 
thorny topic that I wasn't trying to tackle now.

So far as kernel-to-userspace event notification goes (assuming the 
power policy manager is in userspace, which is certainly where I'd 
recommend), ACPI has a procfs-based communication channel but the 
kobject_uevent stuff looks like the way I'd go, and it's somewhere on my 
list to come up with a patch that does that as well.

If these general ideas of arbitrary platform power parameters and 
operating points are deemed worthy of continued consideration, I'll 
propose what I view is the next step: interfaces to create and activate 
operating points from userspace.

At that point it should be possible to write power policy management 
applications for systems that can benefit from this generalized notion 
of operating points: create the operating points that match the system 
usage models (in the case of many embedded systems, the system is some 
mode with different power/performance characteristics such as audio 
playback vs. mobile phone call in progress) and power needs (e.g., low 
battery strength vs. high strength) and activate operating points based 
on events received (new app running, low battery warning, etc.).

Any opinions on all that?  Thanks,

-- 
Todd