lkml.org 
[lkml]   [2010]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [linux-pm] [PATCH 1/8] PM: Add suspend block api.
    From
    2010/5/6 Tony Lindgren <tony@atomide.com>:
    > * Arve Hjønnevåg <arve@android.com> [100505 21:11]:
    >> On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren <tony@atomide.com> wrote:
    >> > * Brian Swetland <swetland@google.com> [100505 16:51]:
    >> >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren <tony@atomide.com> wrote:
    >> >> > * Brian Swetland <swetland@google.com> [100505 14:34]:
    >> >> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
    >> >> >> >>
    >> >> >> >> Oh, like tell the modem that user mode has handled the ring event and
    >> >> >> >> its ok to un-block?
    >> >> >> >
    >> >> >> > No, that's not how it works.  It would go like this:
    >> >> >> >
    >> >> >> >        The modem IRQ handler queues its event to the input subsystem.
    >> >> >> >        As it does so the input subsystem enables a suspend blocker,
    >> >> >> >        causing the system to stay awake after the IRQ is done.
    >> >> >
    >> >> > How about instead the modem driver fails to suspend until it's done?
    >> >> >
    >> >> > Each driver could have a suspend_policy sysfs entry with options such
    >> >> > as [ forced | safe ]. The default would be forced. Forced would
    >> >> > be the current behaviour, while safe would refuse suspend until the
    >> >> > driver is done processing.
    >> >> >
    >> >> >> >        The user program enables its own suspend blocker before reading
    >> >> >> >        the input queue.  When the queue is empty, the input subsystem
    >> >> >> >        releases its suspend blocker.
    >> >> >
    >> >> > And also the input layer could refuse to suspend until it's done.
    >> >> >
    >> >> >> >        When the user program finishes processing the event, it
    >> >> >> >        releases its suspend blocker.  Now the system can go back to
    >> >> >> >        sleep.
    >> >> >
    >> >> > And here the user space just tries to suspend again when it's done?
    >> >> > It's not like you're trying to suspend all the time, so it should be
    >> >> > OK to retry a few times.
    >> >>
    >> >> We actually are trying to suspend all the time -- that's our basic
    >> >> model -- suspend whenever we can when something doesn't prevent it.
    >> >
    >> > Maybe that state could be kept in some userspace suspend policy manager?
    >> >
    >> >> >> > At no point does the user program have to communicate anything to the
    >> >> >> > modem driver, and at no point does it have to do anything out of the
    >> >> >> > ordinary except to enable and disable a suspend blocker.
    >> >> >>
    >> >> >> Exactly -- and you can use the same style of overlapping suspend
    >> >> >> blockers with other drivers than input, if the input interface is not
    >> >> >> suitable for the particular interaction.
    >> >> >
    >> >> > Would the suspend blockers still be needed somewhere in the example
    >> >> > above?
    >> >>
    >> >> How often would we retry suspending?
    >> >
    >> > Well based on some timer, the same way the screen blanks? Or five
    >> > seconds of no audio play? So if the suspend fails, then reset whatever
    >> > userspace suspend policy timers.
    >> >
    >> >> If we fail to suspend, don't we have to resume all the drivers that
    >> >> suspended before the one that failed?  (Maybe I'm mistaken here)
    >> >
    >> > Sure, but I guess that should be a rare event that only happens when
    >> > you try to suspend and something interrupts the suspend.
    >> >
    >>
    >> This is not a rare event. For example, the matrix keypad driver blocks
    >> suspend when a key is down so it can scan the matrix.
    >
    > Sure, but how many times per day are you suspending?
    >

    How many times we successfully suspend is irrelevant here. If the
    driver blocks suspend the number of suspend attempts depend on your
    poll frequency.

    >> >> With the suspend block model we know the moment we're capable of
    >> >> suspending and then can suspend at that moment.  Continually trying to
    >> >> suspend seems like it'd be inefficient power-wise (we're going to be
    >> >> doing a lot more work as we try to suspend over and over, or we're
    >> >> going to retry after a timeout and spend extra time not suspended).
    >> >>
    >> >> We can often spend minutes (possibly many) at a time preventing
    >> >> suspend when the system is doing work that would be interrupted by a
    >> >> full suspend.
    >> >
    >> > Maybe you a userspace suspend policy manager would do the trick if
    >> > it knows when the screen is blanked and no audio has been played for
    >> > five seconds etc?
    >> >
    >>
    >> If user space has to initiate every suspend attempt, then you are
    >> forcing it to poll whenever a driver needs to block suspend.
    >
    > Hmm I don't follow you. If the userspace policy daemon timer times
    > out, the device suspends. If the device does not suspend because of
    > a blocking driver, then the timers get reset and you try again based
    > on some event such as when the screen blanks.
    >

    This retry is what I call polling. You have to keep retrying until you
    succeed. Also, using the screen blank timeout for this polling is not
    a good idea. You do not want to toggle the screen off and on with with
    every suspend attempt.

    --
    Arve Hjønnevåg
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2010-05-07 02:13    [W:4.621 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site