Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

[Brian Swetland]

On Fri, May 28, 2010 at 6:32 AM, Igor Stoppa <igor.stoppa@xxxxxxxxx> 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.

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