Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757112Ab0FFK62 (ORCPT ); Sun, 6 Jun 2010 06:58:28 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:58811 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755621Ab0FFK60 (ORCPT ); Sun, 6 Jun 2010 06:58:26 -0400 Date: Sun, 6 Jun 2010 12:05:57 +0100 From: Alan Cox To: Florian Mickler Cc: Vitaly Wool , Brian Swetland , Arve =?ISO-8859-14?B?SGr4bm5lduVn?= , Arjan van de Ven , tytso@mit.edu, Peter Zijlstra , "H. Peter Anvin" , LKML , Neil Brown , James Bottomley , Linux PM , Ingo Molnar , Linux OMAP Mailing List , Linus Torvalds , Thomas Gleixner , Felipe Balbi Subject: Re: [linux-pm] suspend blockers & Android integration Message-ID: <20100606120557.72356de9@lxorguk.ukuu.org.uk> In-Reply-To: <20100606124601.2f1f6714@schatten.dmk.lab> References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> <20100604071354.GA14451@elte.hu> <20100604083423.GD15181@elte.hu> <1275653210.27810.39762.camel@twins> <1275731653.27810.41078.camel@twins> <20100605092851.6ee15f13@infradead.org> <20100606124601.2f1f6714@schatten.dmk.lab> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.18.9; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1287 Lines: 32 On Sun, 6 Jun 2010 12:46:01 +0200 Florian Mickler wrote: > On Sun, 6 Jun 2010 12:00:47 +0200 > Vitaly Wool wrote: > > > Even worse, the suspend wakelock will keep the > > whole kernel active, as opposed to powering off unused devices > > separately as it's done in runtime PM. > > That is not true. While the kernel is not suspended it does > runtime pm. On several of our platforms runtime PM already includes suspend so a suspend wakelock does interfere with existing power managemet at that level (not to mention the maintenance mess it causes). This is one of the reasons you want QoS information, it provides parameters by which the power management code can make a decision. Suspend blocksers simply don't have sufficient variety to manage the direction of power policy. If Android chooses to abuse the QoS information for crude suspend blocking then that is fine, it doesn't interfere with doing the job 'properly' on other systems or its use for realtime work on other boxes. Alan -- 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/