On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote: > * Brian Swetland <swetl...@google.com> wrote: > > On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar <mi...@elte.hu> wrote: > > > * Brian Swetland <swetl...@google.com> wrote: [...] > > > In any case, this is not to suggest that the suspend-blocker bits are > > > 'impossible' to merge. I just say that if you start with your most > > > difficult feature you should not be surprised to be on the receiving end > > > of a 1000+ mails flamewar on lkml ;-) > > > > Yeah, I do understand that we're not making it easy for ourselves here. I > > think we hit the point where Rafael and Matthew signed off on things and > > thought "aha, linux-pm maintainers are happy, now we're getting somewhere" > > only to realize the light at the end of the tunnel was a bit further out > > than we anticipated ^^ > > That's a well-known problem on lkml: the light at the end of the tunnel was > the other train ;-) > > Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be > crystalising out today. Everyone seems to agree now that the main usecases > are > indeed useful and need handling one way or another - the rest is really just > technological discussions how to achieve the mostly-agreed-upon end goal.
It's still not clear to me whether everyone's revolving around to using the current suspend block API because it's orthogonal to all other mechanisms and is therefore separate from the kernel (and can be compiled out if you don't want it). Or whether re-expressing what the android drivers want (minimum idle states and suspend block) in pm_qos terms which others can use is the way to go. I think the latter, but I'd like to know what other people think (because I'm not wedded to this preference). > The worst situation are features where one side says 'we dont need this kind > of functionality at all' - IMO auto/opportunistic-suspend isnt in that > situation, fortunately. Great ... because deprecating the problem has been one of the persistent memes by some people on this huge thread. James -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
