From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756383Ab0EFTMF (ORCPT ); Thu, 6 May 2010 15:12:05 -0400 Received: from fifo99.com ([67.223.236.141]:33242 "EHLO fifo99.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756027Ab0EFTMB (ORCPT ); Thu, 6 May 2010 15:12:01 -0400 Subject: Re: [linux-pm] [PATCH 1/8] PM: Add suspend block api. From: Daniel Walker To: Tony Lindgren Cc: Matthew Garrett , 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 In-Reply-To: <20100506183605.GF30928@atomide.com> References: <20100505202826.GB7450@linux.intel.com> <20100505234755.GI29604@atomide.com> <20100506134015.GA23426@srcf.ucam.org> <20100506170151.GA30928@atomide.com> <20100506170956.GA28104@srcf.ucam.org> <20100506171453.GC30928@atomide.com> <1273167311.20494.13.camel@c-dwalke-linux.qualcomm.com> <20100506183605.GF30928@atomide.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 06 May 2010 12:11:50 -0700 Message-ID: <1273173110.20494.19.camel@c-dwalke-linux.qualcomm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2010-05-06 at 11:36 -0700, Tony Lindgren wrote: > * Daniel Walker [100506 10:30]: > > On Thu, 2010-05-06 at 10:14 -0700, Tony Lindgren wrote: > > > * Matthew Garrett [100506 10:05]: > > > > On Thu, May 06, 2010 at 10:01:51AM -0700, Tony Lindgren wrote: > > > > > > > > > Or are you suspending constantly, tens of times per minute even if > > > > > there's no user activity? > > > > > > > > In this case you'd be repeatedly trying to suspend until the modem > > > > driver stopped blocking it. It's pretty much a waste. > > > > > > But then the userspace knows you're getting data from the modem, and > > > it can kick some inactivity timer that determines when to try to > > > suspend next. > > > > If the idle thread was doing the suspending then the inactivity timer by > > it's self could block suspend. As long as the idle thread was setup to > > check for timers. I'm sure that _isn't_ the point your trying to make. > > It just makes gobs more sense to me that the idle thread does the > > suspending .. Your idle, so depending on how long your idle then you > > suspend. > > The alternative logic I'm suggesting is get the GUI into idle mode as > soon as possible, then limp along with off-while-idle or > retention-while-idle until some timer expires, then suspend the whole > device. Could you elaborate on "off-while-idle" and "retention-while-idle" ? I'm not sure I follow what you mean. Daniel