From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [RFC][PATCH 00/11] Android PM extensions Date: Sun, 1 Feb 2009 13:30:03 +0100 Message-ID: <200902011330.03579.rjw@sisk.pl> References: <20090131074743.GA13633@bulgaria.corp.google.com> <200902010232.22055.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: Arve =?iso-8859-1?q?Hj=F8nnev=E5g?= Cc: Brian Swetland , linux-pm@lists.linux-foundation.org, Nigel Cunningham List-Id: linux-pm@vger.kernel.org On Sunday 01 February 2009, Arve Hj=F8nnev=E5g wrote: > On Sat, Jan 31, 2009 at 5:32 PM, Rafael J. Wysocki wrote: > >> > If incoming calls are supposed to wake up the system, then there are= two > >> > possibilities: > >> > - the already started suspend sequence may be aborted and the system= may be put > >> > into the low power state, > >> > >> I assume you mean high power state not low power state, or does low > >> power state mean early-suspend state. If so, locking a wakelock will > >> accomplish this. > > > > Actually, I meant the working state. Aborting suspend sequence always = means > > go back to the working state. > > > > Also, I think the device that detected the incoming call should abort t= he > > suspend sequence by refusing to suspend. > > > >> > - the system may be suspended and then immediately woken up. > >> > >> If you mean this as a general strategy, and not a specific outcome, > >> then it does not always work (for the reasons I have already stated). > > > > I meant a specific outcome. > > > > It may be impossible to abort suspend if the call comes in sufficiently > > late. > = > In that case, why are you against using wakelocks to abort the suspend > sequence? It covers the case where the driver knows that a call is > coming in, without any confusion about when the abort condition > clears. And, it avoids the overhead of freezing every process for an > operation that is doomed to fail. I'm not really against (yet), I'm only trying to clearly understand the benefit. The problem pointed out by Alan is real, the user expects the system to sus= pend as soon as the button is pressed and wakelocks may get in the way. Your example is also good, but I think the problem in your example (phone call coming in while suspending) may be resolved without wakelocks. Moreov= er, it is a general problem of a wake-up event coming in while suspending and it requires a general solution independent of wakelocks. Thanks, Rafael