[lkml]   [2010]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <> wrote:
    > What I consider plain wrong i to claim that since there are this many units
    > out, some code should be merged.

    I've never suggested that we should get a get-out-of-code-review-free
    card or be automatically merged based on shipping volume.

    Hell, I never thought we should even bother trying to merge wakelocks
    upstream, because I assumed that they'd be hated for not being the
    linux way (tm). Greg KH and others have spent a bunch of time
    shouting at me (or Google) that we should be doing this, and here we
    are giving it a go. At this point we've spent more engineering time
    on revising this one patchset (10 revisions to address various rounds
    of feedback) and discussion of it than we have on rebasing our working
    kernel trees to roughly every other linux release from 2.6.16 to
    2.6.32 (which became much easier after switching to git).

    > A company needs to cut corners sometimes when making a product but this
    > should not affect upstream code.

    I will disagree that wakelocks are "cutting corners" (we certainly
    have some corner cutting code in our trees, because yeah, ship is
    compromise, but I don't believe wakelocks are an example). They're a
    real solution for real problems faced on real devices. Obviously not
    a solution that everyone here likes, and maybe they'll never end up in
    mainline as a result, but so far I haven't seen a counter proposed
    solution that seems to solve the same problem, avoid races, and be
    simpler/cleaner (at least to my eyes).

    >> I am quite willing to state that on both MSM and OMAP based Android
    >> platforms, we've found that the suspend blocker model allows us to
    >> obtain a lower average power draw than if we don't use it -- Mike Chan
    >> provided some numbers earlier in another thread in the trivial device
    >> idle case, the win is of course much larger in the case of several
    >> poorly behaved apps being active.
    > That's very good. But if it is done in a conceptually flawed way, some
    > better solution should be considered for upstream merge.

    How is it flawed? Serious question.


     \ /
      Last update: 2010-05-28 15:29    [W:0.042 / U:26.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site