lkml.org 
[lkml]   [2010]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 6)
    From
    On Mon, May 17, 2010 at 11:39 AM, Felipe Balbi <me@felipebalbi.com> wrote:
    > Hi,
    >
    > On Mon, May 17, 2010 at 11:26:59AM -0700, Brian Swetland wrote:
    >> We (Google) would like to allow completely open app distribution with
    >> minimal hurdles, and avoid the walled garden approach.  Toward this
    >> goal we're not even requiring the use of a central app store for
    >> distribution.
    >
    > I understand that, but still we should be telling developers what
    > they're doing wrong so that they can improve themselves as professionals
    > and still make the final device better.

    I agree. Which is why we develop tools to help developers understand
    what their apps are doing.

    >> For a large majority of apps, running in the background while the
    >> device is asleep (screen off) is not essential, they don't request the
    >> "keep device awake" permission, never hold a wakelock, etc.  Those
    >> that do need to do this have the permission, may hold suspend
    >> blockers, and are accounted for.
    >
    > but can anyone write an app that holds a suspend_blocker ?? If so, then
    > your goal is already broken, right ? I mean, if anyone can keep a
    > suspend_blocker held forever, you'll never ever sleep, right ? While
    > with runtime, if you keep the keypad open, only the keypad and the paths
    > directly related to it (probably the i2c controller and the power domain
    > where the i2c controller sits) will be kept alive, no ?

    No, you'll never suspend, which is different from never going to the
    lowest CPU power state. On shipping Android devices we aggressively
    completely power down the CPU in idle whenever we can (based on
    latency requirements generally). We power off peripherals whenever
    they're not in use.

    This is why I've stated previously that I don't think runtime PM and
    opportunistic suspend are competitive features. Everyone who cares
    about minimizing power should want runtime pm or at least similar
    functionality (our drivers have always powered down peripherals when
    not in use, even while the device is open, etc, prior to the existence
    of runtime PM).

    If your environment is such that going to full suspend will not gain
    you anything, then don't use opportunistic suspend. We find that
    there are savings to be had with this model in Android which is why we
    use it. If you are going to use opportunistic suspend,
    suspend_blockers provide useful functionality.

    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-17 20:49    [W:4.363 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site