From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756870Ab0EGPzI (ORCPT ); Fri, 7 May 2010 11:55:08 -0400 Received: from mho-01-ewr.mailhop.org ([204.13.248.71]:55963 "EHLO mho-01-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756847Ab0EGPzE (ORCPT ); Fri, 7 May 2010 11:55:04 -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: U2FsdGVkX1+MKbwCHFTthveK3PP2zgiG Date: Fri, 7 May 2010 08:54:55 -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: <20100507155455.GC387@atomide.com> References: <20100505202826.GB7450@linux.intel.com> <20100505234755.GI29604@atomide.com> <20100506000552.GJ29604@atomide.com> <20100506170420.GB30928@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 [100506 17:05]: > 2010/5/6 Tony Lindgren : > > * Arve Hjønnevåg [100505 21:11]: > >> 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? > > > > How many times we successfully suspend is irrelevant here. If the > driver blocks suspend the number of suspend attempts depend on your > poll frequency. I guess what I'm trying to say is that a failed suspend should be a rare event. > >> >> 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. > > > > This retry is what I call polling. You have to keep retrying until you > succeed. Also, using the screen blank timeout for this polling is not > a good idea. You do not want to toggle the screen off and on with with > every suspend attempt. The number of retries depends on the power management policy for your device. And that is often device and use specific. So having to retry suspend should be a rare event. The userspace should mostly know when it's OK to suspend. Regards, Tony