From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756173AbZBTL0r (ORCPT ); Fri, 20 Feb 2009 06:26:47 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754546AbZBTL0i (ORCPT ); Fri, 20 Feb 2009 06:26:38 -0500 Received: from yx-out-2324.google.com ([74.125.44.30]:18152 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754318AbZBTL0h convert rfc822-to-8bit (ORCPT ); Fri, 20 Feb 2009 06:26:37 -0500 MIME-Version: 1.0 In-Reply-To: <200902201149.37921.rjw@sisk.pl> References: <200902192215.18365.rjw@sisk.pl> <200902201149.37921.rjw@sisk.pl> Date: Fri, 20 Feb 2009 03:26:36 -0800 Message-ID: Subject: Re: [RFD] Automatic suspend From: =?ISO-8859-1?Q?Arve_Hj=F8nnev=E5g?= To: "Rafael J. Wysocki" Cc: Alan Stern , "Woodruff, Richard" , Arjan van de Ven , Kyle Moffett , Oliver Neukum , Benjamin Herrenschmidt , pm list , LKML , Pavel Machek , Nigel Cunningham , Matthew Garrett , mark gross , Uli Luckas , Igor Stoppa , Brian Swetland , Len Brown Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 20, 2009 at 2:49 AM, Rafael J. Wysocki wrote: > On Friday 20 February 2009, Arve Hjønnevåg wrote: >> On Thu, Feb 19, 2009 at 2:08 PM, Alan Stern wrote: >> >> > It might have to be platform-specific. The Android people seem to have a >> >> > pretty good idea of what criteria will work for them. >> >> >> >> I'd really like to know in what situations Androind is supposed to suspend >> >> automatically. >> > >> > It might be better to ask in what situations Android is _not_ supposed >> > to sleep automatically. In other words, in what situations is a >> > wakelock acquired? Since the whole system is only a phone, this >> > question should have a reasonably well-defined answer. >> >> On an android phone, any code that needs to run when the screen is off >> must hold a wakelock (directly or indirectly). In general if an >> application or the system is processing an event that may cause a user >> notification (new email, incoming phone call, alarm, etc.) it needs to >> prevent suspend. But, we also use wakelocks to upload stats or >> download system updates in the background, and for media player or >> (gps) data logging applications. > > All of this doesn't seem to require wakelocks acuired from kernel space. > What do you need those wakelocks for? Most events do not originate in user-space. Alarms start in our alarm driver which locks a wakelock when its timer interrupt occurs. This wakelock stays locked until the user-space alarm manager calls the driver to wait for the next alarm. I've described how input events are handled before. Without kernel wakelocks, if the user space power manager had already turned off the screen and decided to suspend right before a wakeup key is pressed, then that key could sit in the in-kernel input queue until another key is pressed. Even if the user-space thread read the key event before being frozen, it cannot abort the suspend operation that was already started. -- Arve Hjønnevåg