[lkml]   [2010]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] suspend blockers & Android integration
    On Thu, 10 Jun 2010, Arve Hjønnevåg wrote:

    > > You've lost me.  If the power manager is sitting inside a select/poll,
    > > how can it miss the event (given that the event will make data
    > > available to be read on one of the descriptors being polled)?
    > >
    > It cannot sit inside of select/poll all the time.
    > > Or put it another way: With wakelocks, if the app doesn't use a suspend
    > > blocker then once it reads the event data and the timed wakelock is
    > > deactivated, there is nothing to prevent the system from immediately
    > > going into opportunistic suspend.  My scheme can fail in the same way.
    > > Is that what you meant?
    > >
    > No, if an app reads from a file descriptor and block suspend when the
    > read call returns, then suspend is blocked while processing the data.
    > If the driver uses a wakelock with a timeout this will fail if the
    > thread does not get to the suspend block call before the timeout
    > expires, but unrelated events that don't prevent the app from running
    > will not cause any problems.

    Wait a second. Maybe I have misunderstood how timeouts are supposed to
    work with wakelocks. I thought the idea was that the wakelock would be
    released when the timeout expires or the event queue is emptied,
    whichever comes first. Now it sounds like you're saying that the
    wakelock doesn't get released until the timeout expires, even if
    userspace finishes processing all pending events before then.

    > In your scheme the user-space power
    > manager may miss events on this file descriptor since select/poll will
    > not see an event if the app read that event right before the power
    > manager called select/poll.

    If the wakelock is supposed to remain active until the timeout expires
    then you are right. On the other hand, this seems like a rather
    strange and suspicious way of handling wakelocks. Why would you want
    to do it that way?

    > > There's one question that I don't remember ever seeing answered.  To
    > > which kernel drivers do you intend to add suspend blockers?
    > >
    > All drivers that generate wakeup events need to either use suspend
    > blockers directly or call into something else that does. For instance,
    > with the patch to block suspend while input events are queued to
    > user-space, an input driver that fully handles its events in its
    > interrupt handler does not need any additional suspend blockers, but
    > if the driver needs a work function or a timer to run before it
    > reports the event it needs to block suspend until it has reported the
    > event.

    Sure. But specifically, which drivers on Android generate wakeup
    events? And which of them don't fully handle their events in their
    interrupt handlers?

    Maybe another way to put this is: Where in the kernel do you intend to
    add suspend blockers?

    Alan Stern

    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: 2010-06-11 16:35    [W:0.021 / U:11.476 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site