Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755474Ab0FDMHW (ORCPT ); Fri, 4 Jun 2010 08:07:22 -0400 Received: from bombadil.infradead.org ([18.85.46.34]:45542 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753511Ab0FDMHT convert rfc822-to-8bit (ORCPT ); Fri, 4 Jun 2010 08:07:19 -0400 Subject: Re: suspend blockers & Android integration From: Peter Zijlstra To: Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= Cc: Ingo Molnar , tytso@mit.edu, Brian Swetland , Neil Brown , Thomas Gleixner , "Rafael J. Wysocki" , Alan Stern , Felipe Balbi , LKML , Florian Mickler , Linux OMAP Mailing List , Linux PM , Alan Cox , James Bottomley , Linus Torvalds , Kevin Hilman , "H. Peter Anvin" , Arjan van de Ven In-Reply-To: References: <20100603193045.GA7188@elte.hu> <20100603231153.GA11302@elte.hu> <20100603232302.GA16184@elte.hu> <20100604071354.GA14451@elte.hu> <20100604083423.GD15181@elte.hu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Fri, 04 Jun 2010 14:06:50 +0200 Message-ID: <1275653210.27810.39762.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2290 Lines: 52 On Fri, 2010-06-04 at 01:56 -0700, Arve Hjønnevåg wrote: > On Fri, Jun 4, 2010 at 1:34 AM, Ingo Molnar wrote: > > > > * Arve Hj?nnev?g wrote: > > > >> > [...] > >> > > >> > Why do you need to track input wakeups? It's rather fragile and rather > >> > unnecessary [...] > >> > >> Because we have keys that should always turn the screen on, but the problem > >> is not specific to input events. If we enabled a wakeup event it usually > >> means we need this event to always work, not just when the system is fully > >> awake or fully suspended. > > > > Hm, i cannot follow that generic claim. Could you please point out the problem > > to me via a specific example? Which task does what, what undesirable thing > > happens where, etc. > > > > We have many wakeup events, and some of them are invisible to the > user. For instance on the Nexus One wake up every 10 minutes monitor > the battery health. > If the user presses a key right after this work > has finished and we did not block suspend until userspace could > process this key event, we risk suspending before we could turn the > screen on, which to the user looks like the key did not work. > Another > example, the user pressed the power key which turns the screen off and > allows suspend. We initiate suspend and a phone call comes in. If we > don't block suspend until we processed the incoming phone call > notification, the phone may never ring (some devices will send a new > message every few seconds for this, so on those devices it would just > delay the ringing). Right, so in the proposed scheme all these tasks would be executed by trusted processes, and trusted processes will never get frozen and so will never be delayed in processing these events. Only untrusted code will be frozen. And trusted processes are reliable for thawing the untrusted processes and delivering events to it. Trusted processes are assumed to be sane and idle when there is nothing for them to do, allowing the machine to go into deep idle states. -- 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/