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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |