[lkml]   [2005]   [Aug]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] PowerOP 1/3: PowerOP core
    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,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-08-10 02:36    [W:3.487 / U:1.896 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site