From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [linux-pm] Runtime PM discussion notes Date: Mon, 11 Jul 2011 04:32:12 -0700 Message-ID: <20110711113212.GW5783@atomide.com> References: <201106232234.21930.rjw@sisk.pl> <20110709040622.GH26900@sirena.org.uk> <20110711095812.GT5783@atomide.com> <20110711110435.GF5092@opensource.wolfsonmicro.com> <20110711111424.GV5783@atomide.com> <20110711112619.GH5092@opensource.wolfsonmicro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-04-ewr.mailhop.org ([204.13.248.74]:26113 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752568Ab1GKLcX (ORCPT ); Mon, 11 Jul 2011 07:32:23 -0400 Content-Disposition: inline In-Reply-To: <20110711112619.GH5092@opensource.wolfsonmicro.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Mark Brown Cc: Paul Walmsley , Arve Hj?nnev?g , "Rafael J. Wysocki" , Alan Stern , linux-pm@lists.linux-foundation.org, linux-omap@vger.kernel.org, Magnus Damm , Kevin Hilman * Mark Brown [110711 04:21]: > On Mon, Jul 11, 2011 at 04:14:24AM -0700, Tony Lindgren wrote: > > * Mark Brown [110711 03:59]: > > > > Right, but it can be interesting to tell the PMIC that we went into this > > > mode. Possibly cpuidle will end up doing this as a result of signals > > > generated as the CPU core goes down, but at that point it's just s2ram > > > by another name. > > > All PMIC devices should be shut down when not in use, so I don't know > > what else you would configure in the PMIC. Maybe you have something else > > there to configure? Just curious what kind of mess you have to deal with > > compared to the mess I need to deal with :) > > The interesting bits are things like being able to kill lots of the SoC > core supplies when the RAM is in retention mode - the CPU needs to go > through its shutdown procedures. I see. I've seen cases these are pre-programmed to the PMIC and then automatically triggered based on some event like WFI. > > Also, hitting deeper sleep states from idle is not same as suspend to ram. > > With suspend to ram the system timer is killed while timers behave in a > > normal way when hitting deeper sleep states from idle. > > Actually, it just occurred to me that if we're waiting for a system > timer and can hand that off to a suitable timer in the PMIC then we can > do a suspend to RAM for the deep idle state from the hardware point of > view. Cool, it would be nice to have a Linux generic way for programming a separate hardware wake-up timer. Not RTC, but some more accurate timer that might be too slow to access for general purpose usage. Regards, Tony