Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933305Ab0HEO35 (ORCPT ); Thu, 5 Aug 2010 10:29:57 -0400 Received: from smtp-out.google.com ([216.239.44.51]:27387 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756867Ab0HEO3y (ORCPT ); Thu, 5 Aug 2010 10:29:54 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=lbVJ3HXjD+8samg6sF9WfJR6eex6vPGx24dJKUx3mPTeK2o5qM2JgWe8cu8o5ckaD L009aPir4y+6wg0CaKP+Q== MIME-Version: 1.0 In-Reply-To: References: <20100801054816.GI2470@linux.vnet.ibm.com> <20100804205654.GA4986@srcf.ucam.org> <201008050220.51805.rjw@sisk.pl> <20100805134057.GB20565@srcf.ucam.org> Date: Thu, 5 Aug 2010 07:29:51 -0700 Message-ID: Subject: Re: Attempted summary of suspend-blockers LKML thread From: Brian Swetland To: david@lang.hm Cc: Matthew Garrett , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "Rafael J. Wysocki" , "Paul E. McKenney" , Arjan van de Ven , linux-pm@lists.linux-foundation.org, linux-kernel@vger.kernel.org, pavel@ucw.cz, florian@mickler.org, stern@rowland.harvard.edu, peterz@infradead.org, tglx@linutronix.de, alan@lxorguk.ukuu.org.uk Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1538 Lines: 32 On Thu, Aug 5, 2010 at 7:22 AM, wrote: > > Ok, it is now sounding to me like there are two different (but somewhat > related) purposes that wakelocks are being used for > > 1. deciding if the system should go to sleep now or not (what most of the > discussion has been about) > > 2. narrowing the race between going to sleep and wakeup events. > > I'm not sure it's possible to completely eliminate the race, even with > wakelocks there is some time between the time you last check if the wakelock > is set and when the hardware finishes responding to your commands to go to > sleep (Unless you can set a level-based interrupt that will wake you up as > soon as you finish going to sleep) The transition into sleep is race-free in the wakelock model -- either the wakeup event happens during the kernel suspend (and grabs a wakelock), in which case suspend is aborted (and not attempted again until there are once again no more wakelocks held), or the system fully suspends to its lowest power mode until a wakeup event brings it back out again. Entry to lowest power mode must abort if a wakeup event/interrupt occurs while it's in process -- exactly how the handoff happens here is hardware dependent but in practice this is doable on just about any modern system. Brian -- 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/