From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) Date: Wed, 02 Jun 2010 18:03:38 -0500 Message-ID: <1275519818.2799.527.camel@mulgrave.site> References: <20100527232357.6d14fdb2@lxorguk.ukuu.org.uk> <20100601135102.GA8098@srcf.ucam.org> <1275426085.21962.967.camel@mulgrave.site> <201006020024.14220.rjw@sisk.pl> <1275431816.21962.1108.camel@mulgrave.site> <1275451342.21962.1777.camel@mulgrave.site> <1275491111.2799.110.camel@mulgrave.site> <20100602214748.7742e3ae@schatten.dmk.lab> <1275511271.2799.516.camel@mulgrave.site> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from cantor.suse.de ([195.135.220.2]:53410 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933161Ab0FBXDs (ORCPT ); Wed, 2 Jun 2010 19:03:48 -0400 In-Reply-To: Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Arve =?ISO-8859-1?Q?Hj=F8nnev=E5g?= Cc: tytso@mit.edu, Neil Brown , felipe.balbi@nokia.com, LKML , Florian Mickler , Peter Zijlstra , mark.gross@intel.com, Thomas Gleixner , Linux OMAP Mailing List , Linux PM , Alan Cox On Wed, 2010-06-02 at 15:27 -0700, Arve Hj=C3=B8nnev=C3=A5g wrote: > On Wed, Jun 2, 2010 at 1:41 PM, James Bottomley wrote: > > On Wed, 2010-06-02 at 21:47 +0200, Florian Mickler wrote: > >> On Wed, 02 Jun 2010 10:05:11 -0500 > >> James Bottomley wrote: > >> > >> > On Tue, 2010-06-01 at 21:41 -0700, Arve Hj=C3=B8nnev=C3=A5g wrot= e: > >> > > No, they have to be two separate constraints, otherwise a cons= traint > >> > > to block suspend would override a constraint to block a low po= wer idle > >> > > mode or the other way around. > >> > > >> > Depends. If you block the system from going into low power idle= , does > >> > that mean you still want it to be fully suspended? > >> > > >> > If yes, then we do have independent constraints. If not, they h= ave a > >> > hierarchy: > >> > > >> > * Fully Interactive (no low power idle or suspend) > >> > * Partially Interactive (may go into low power idle but no= t > >> > suspend) > >> > * None (may go into low power idle or suspend) > >> > > >> > Which is expressable as a ternary constraint. > >> > > >> > James > >> > > >> > >> But unblocking suspend at the moment is independent to getting idl= e. > >> If you have the requirement to stay in the highest-idle level (i.e= =2E > >> best latency you can get) that does not (currently) mean, that you= can > >> not suspend. > > > > I don't understand that as a reason. If we looks at this a qos > > constraints, you're saying that the system may not drop into certai= n low > > power states because it might turn something off that's currently b= eing > > used by a driver or a process. Suspend is certainly the lowest sta= te of > > that because it turns everything off, why would it be legal to drop= into > > that? >=20 > Because the driver gets called on suspend which gives it a change to > stop using it. >=20 > > > > I also couldn't find this notion of separation of idleness power fr= om > > suspend blocking in the original suspend block patch set ... if you= can > > either tell me where it is, or give me an example of the separated = use > > cases, I'd understand better. > > >=20 > The suspend block patchset only deals with suspend, not low power idl= e > modes. The original wakelock patchset had two wakelock types, idle an= d > suspend. OK, so that explains why I didn't see it ... > >> To preserve that explicit fall-through while still having working > >> run-time-powermanagement I think the qos-constraints need to be > >> separated. > > > > OK, as above, why? or better yet, just give an example. > > >=20 > The i2c bus on the Nexus One is used by the other core to turn off th= e > power you our core when we enter the lowest power mode. This means > that we cannot enter that low power mode while the i2c bus is active, > so we block low power idle modes. At some point we also tries to bloc= k > suspend in this case, but this caused a lot of failed suspend attempt= s > since the frequency scaling code would try to ramp up while freezing > processes which in turn aborted the process freezing attempts. OK, so this is a device specific power constraint state. I suppose it makes sense to have a bunch of those, because the device isn't necessarily going to know what idle power mode it can't go into, so the cpu govenor should sort it out rather than have the device specify a minimum state. =20 James -- To unsubscribe from this list: send the line "unsubscribe linux-omap" i= n the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html