From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754616Ab0EFREh (ORCPT ); Thu, 6 May 2010 13:04:37 -0400 Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:60028 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751274Ab0EFREg (ORCPT ); Thu, 6 May 2010 13:04:36 -0400 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.181.193.102 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX191r1JsitM8b6qj6fiIW7Oz Date: Thu, 6 May 2010 10:04:21 -0700 From: Tony Lindgren To: Arve =?utf-8?B?SGrDuG5uZXbDpWc=?= Cc: Brian Swetland , Alan Stern , mark gross , markgross@thegnar.org, Len Brown , linux-doc@vger.kernel.org, Kernel development list , Jesse Barnes , Oleg Nesterov , Tejun Heo , Linux-pm mailing list , Wu Fengguang , Andrew Morton Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api. Message-ID: <20100506170420.GB30928@atomide.com> References: <20100505202826.GB7450@linux.intel.com> <20100505234755.GI29604@atomide.com> <20100506000552.GJ29604@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arve Hjønnevåg [100505 21:11]: > On Wed, May 5, 2010 at 5:05 PM, Tony Lindgren wrote: > > * Brian Swetland [100505 16:51]: > >> On Wed, May 5, 2010 at 4:47 PM, Tony Lindgren wrote: > >> > * Brian Swetland [100505 14:34]: > >> >> On Wed, May 5, 2010 at 2:12 PM, Alan Stern wrote: > >> >> >> > >> >> >> Oh, like tell the modem that user mode has handled the ring event and > >> >> >> its ok to un-block? > >> >> > > >> >> > No, that's not how it works.  It would go like this: > >> >> > > >> >> >        The modem IRQ handler queues its event to the input subsystem. > >> >> >        As it does so the input subsystem enables a suspend blocker, > >> >> >        causing the system to stay awake after the IRQ is done. > >> > > >> > How about instead the modem driver fails to suspend until it's done? > >> > > >> > Each driver could have a suspend_policy sysfs entry with options such > >> > as [ forced | safe ]. The default would be forced. Forced would > >> > be the current behaviour, while safe would refuse suspend until the > >> > driver is done processing. > >> > > >> >> >        The user program enables its own suspend blocker before reading > >> >> >        the input queue.  When the queue is empty, the input subsystem > >> >> >        releases its suspend blocker. > >> > > >> > And also the input layer could refuse to suspend until it's done. > >> > > >> >> >        When the user program finishes processing the event, it > >> >> >        releases its suspend blocker.  Now the system can go back to > >> >> >        sleep. > >> > > >> > And here the user space just tries to suspend again when it's done? > >> > It's not like you're trying to suspend all the time, so it should be > >> > OK to retry a few times. > >> > >> We actually are trying to suspend all the time -- that's our basic > >> model -- suspend whenever we can when something doesn't prevent it. > > > > Maybe that state could be kept in some userspace suspend policy manager? > > > >> >> > At no point does the user program have to communicate anything to the > >> >> > modem driver, and at no point does it have to do anything out of the > >> >> > ordinary except to enable and disable a suspend blocker. > >> >> > >> >> Exactly -- and you can use the same style of overlapping suspend > >> >> blockers with other drivers than input, if the input interface is not > >> >> suitable for the particular interaction. > >> > > >> > Would the suspend blockers still be needed somewhere in the example > >> > above? > >> > >> How often would we retry suspending? > > > > Well based on some timer, the same way the screen blanks? Or five > > seconds of no audio play? So if the suspend fails, then reset whatever > > userspace suspend policy timers. > > > >> If we fail to suspend, don't we have to resume all the drivers that > >> suspended before the one that failed?  (Maybe I'm mistaken here) > > > > Sure, but I guess that should be a rare event that only happens when > > you try to suspend and something interrupts the suspend. > > > > This is not a rare event. For example, the matrix keypad driver blocks > suspend when a key is down so it can scan the matrix. Sure, but how many times per day are you suspending? > >> With the suspend block model we know the moment we're capable of > >> suspending and then can suspend at that moment.  Continually trying to > >> suspend seems like it'd be inefficient power-wise (we're going to be > >> doing a lot more work as we try to suspend over and over, or we're > >> going to retry after a timeout and spend extra time not suspended). > >> > >> We can often spend minutes (possibly many) at a time preventing > >> suspend when the system is doing work that would be interrupted by a > >> full suspend. > > > > Maybe you a userspace suspend policy manager would do the trick if > > it knows when the screen is blanked and no audio has been played for > > five seconds etc? > > > > If user space has to initiate every suspend attempt, then you are > forcing it to poll whenever a driver needs to block suspend. Hmm I don't follow you. If the userspace policy daemon timer times out, the device suspends. If the device does not suspend because of a blocking driver, then the timers get reset and you try again based on some event such as when the screen blanks. Regards, Tony