[lkml]   [2010]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/8] PM: Opportunistic suspend support.
    On Tue, 25 May 2010, Dmitry Torokhov wrote:

    > > > What you describe can be done in userspace though, via a "suspend manager"
    > > > process. Tasks reading input events will post "busy" events to stop the
    > > > manager process from sending system into suspend. But this can be confined to
    > > > Android userspace, leaving the kernel as is (well, kernel needs to be modified
    > > > to not go into suspend with full queues, but that is using existing kernel
    > > > APIs).
    > >
    > > I think that could be made to work. And it might remove the need for
    > > the userspace suspend-blocker API, which would be an advantage. It
    > > could even remove the need for the opportunistic-suspend workqueue --
    > > opportunistic suspends would be initiated by the "suspend manager"
    > > process instead of by the kernel.
    > >
    > > However you still have the issue of modifying the kernel drivers to
    > > disallow opportunistic suspend if their queues are non-empty. Doing
    > > that is more or less equivalent to implementing kernel-level suspend
    > > blockers. (The suspend blocker approach is slightly more efficient,
    > > because it will prevent a suspend from starting if a queue is
    > > non-empty, instead of allowing the suspend to start and then aborting
    > > it partway through.)
    > >
    > > Maybe I'm missing something here... No doubt someone will point it out
    > > if I am.
    > >
    > Well, from my perspective that would limit changes to the evdev driver
    > (well, limited input core plumbing will be needed) but that is using the
    > current PM infrastructure. The HW driver changes will be limited to what
    > you described "type 2" in your other e-mail.
    > Also, not suspending while events are in progress) is probably
    > beneficial for platforms other than Android as well. So unless I am
    > missing something this sounds like a win.

    I agree that simplifying the user API would be an advantage. Instead
    of the full-blown suspend-blocker interface, we would need only a way
    to initiate an opportunistic suspend. For example:

    echo opportunistic >/sys/power/state

    Alan Stern

     \ /
      Last update: 2010-05-25 21:07    [W:0.021 / U:52.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site