Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932414Ab0FDOYS (ORCPT ); Fri, 4 Jun 2010 10:24:18 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52840 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932384Ab0FDOYP (ORCPT ); Fri, 4 Jun 2010 10:24:15 -0400 Subject: Re: suspend blockers & Android integration From: James Bottomley To: Ingo Molnar Cc: Brian Swetland , tytso@mit.edu, Neil Brown , Arve Hj?nnev?g , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , Linus Torvalds , Peter Zijlstra In-Reply-To: <20100604095917.GA3324@elte.hu> References: <20100603193045.GA7188@elte.hu> <20100604075722.GA15181@elte.hu> <20100604085513.GE15181@elte.hu> <20100604095917.GA3324@elte.hu> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 Jun 2010 09:24:06 -0500 Message-ID: <1275661446.4455.33.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2328 Lines: 48 On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote: > * Brian Swetland wrote: > > On Fri, Jun 4, 2010 at 1:55 AM, Ingo Molnar wrote: > > > * Brian Swetland 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-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/