lkml.org 
[lkml]   [2010]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 0/8] Suspend block api (version 6)
    From
    On Mon, May 3, 2010 at 5:09 PM, Arve Hjønnevåg <arve@android.com> wrote:
    > On Mon, May 3, 2010 at 4:37 PM, Kevin Hilman
    >>
    >> In addition, it will likely cause duplicate work to be done in
    >> drivers.  Presumably, PM aware drivers will want to know if the system
    >> is in opportunistic mode.  For example, for many drivers, doing
    >> runtime PM may not be worth the effort if the system is in
    >> opportunistic mode.
    >
    > Why? If a device is not in use it should be off regardless of what
    > state the rest of the system is in.
    >
    >> This last point is especially troubling.  I don't find it a comforting
    >> path to go down if the drivers have to start caring about which PM
    >> policy is currently in use.

    I'll echo Arve here -- all drivers should seek to be in the lowest
    power state possible at all times. We've never suggested that
    suspend_block is a substitute for that.

    Suspend blockers give us some flexibility on systems where runtime pm
    will not get us all the way there. If you can meet your power needs
    without needing suspend blockers, awesome, you don't need them on that
    platform. The patchset Arve sent out makes this feature an
    off-by-default kernel configuration option that compiles out to no-ops
    when disabled.

    In our experience, periodic timers and polling, both userspace side
    and kernelside make suspend blockers a win even on platforms like OMAP
    which have pretty flexible hardware power management. Going to low
    power states in idle results in higher average power consumption than
    going to the same states in full suspend, at least on Android devices
    shipping today.

    Brian
    --
    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-04 02:45    [W:4.177 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site