Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756489Ab0FDPH4 (ORCPT ); Fri, 4 Jun 2010 11:07:56 -0400 Received: from ist.d-labs.de ([213.239.218.44]:53835 "EHLO mx01.d-labs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932163Ab0FDPHy convert rfc822-to-8bit (ORCPT ); Fri, 4 Jun 2010 11:07:54 -0400 Date: Fri, 4 Jun 2010 17:07:38 +0200 From: Florian Mickler To: James Bottomley Cc: Ingo Molnar , Brian Swetland , tytso@mit.edu, Neil Brown , Arve Hj?nnev?g , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , Peter Zijlstra , LKML , Linux OMAP Mailing List , Linux PM , Alan Cox , Linus Torvalds , Peter Zijlstra Subject: Re: suspend blockers & Android integration Message-ID: <20100604170738.75c7436e@schatten.dmk.lab> In-Reply-To: <1275661446.4455.33.camel@mulgrave.site> References: <20100603193045.GA7188@elte.hu> <20100604075722.GA15181@elte.hu> <20100604085513.GE15181@elte.hu> <20100604095917.GA3324@elte.hu> <1275661446.4455.33.camel@mulgrave.site> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1719 Lines: 41 On Fri, 04 Jun 2010 09:24:06 -0500 James Bottomley wrote: > On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote: > > 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). I'd like to know that also. I have a patch to add?pm_qos_add_request_nonblock function, so it is possible to register an pm_qos constraint by passing preallocated memory to it. Notifying should be possible to do from atomic contexts via async_schedule()? The scalability issues of pm_qos can be adressed by using plists for all pm_qos_class'es. Or by having the different pm_qos_class'es provide their own implementations for the update and get operations. Cheers, Flo > > 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/