[lkml]   [2010]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API
    On Sun, 30 May 2010 13:04:10 -0700
    mark gross <> wrote:

    > Low Power Events is a possible alternative to suspend blocker / wake
    > lock API used by Android.

    Here is how I see your proposal. It is of course possible that I
    misunderstood bits, so please correct me where I'm wrong.

    1/ You have introduced a new mechanism for requesting a transition
    to a low power state. This involves writing a number to /dev/lpe_enter.
    It is not clear to me from your text what the magic number really means.
    I think this parallels writing to /sys/power/state, but achieves the same
    result though a different mechanism and adds some extra checking.
    So: I don't understand the numbers, and I don't see why we need a
    second way to request a low power state. Probably I missed something

    2/ Rather than tracking wake-events from the hardware up through possibly
    several kernel modules, you go directly from hardware to user-space so each
    event is potentially presented to user-space twice: once as a "wake up
    from low power state" event and once following the normal path (maybe a
    key-press event, maybe a serial-port event, maybe a network receive event).
    I can see that this is a very tempting approach. It allows all those
    intermediate modules to remain unchanged and that is good.
    However it isn't clear to me that this would be easy for user-space to use
    When an lpe event arrived it would need to wait around for the real event
    to arrive and then process that. I probably wouldn't wait long, but it
    would be an indeterminate wait, and it might not be trivial to determine
    if all events that would cause a wake-up have been consumed as a direct
    mapping from lpe event to normal event may not always be possible.
    Maybe this is more of a theoretical problem and in practice it would be
    easy to get it right - I don't have enough concrete experience to be sure.

    So: I like the idea of leaving the intermediate layers unchanged, but I'm
    not convinced it would work.

    3/ You have created a new mechanism for passing events to user-space. That
    seems unnecessary. We already have the input subsystem which is pretty
    good at communication arbitrary events, and the events you are dealing
    with a very much like input events.

    So I would suggest modifying your proposal to simply create a new 'input'
    device. Any driver that supports wake-from-suspend queues an event to that
    device when a wakeup event occurs. If the device is open and has any queued
    events, then a suspend request such as 'echo mem > /sys/power/state' completes
    without going into full suspend.

    Then you just need to convince us that this mechanism can be used without any
    race problems. If it can, then it would certainly be a simple and
    unobtrusive approach.


     \ /
      Last update: 2010-05-31 02:01    [W:0.023 / U:1.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site