From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alan Stern Subject: Re: [Update][PATCH 6/10] PM / Domains: System-wide transitions support for generic domains (v5) Date: Fri, 8 Jul 2011 10:37:32 -0400 (EDT) Message-ID: References: <201107081124.17463.rjw@sisk.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <201107081124.17463.rjw@sisk.pl> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-pm-bounces@lists.linux-foundation.org Errors-To: linux-pm-bounces@lists.linux-foundation.org To: "Rafael J. Wysocki" Cc: linux-sh@vger.kernel.org, Greg Kroah-Hartman , LKML , Linux PM mailing list List-Id: linux-pm@vger.kernel.org On Fri, 8 Jul 2011, Rafael J. Wysocki wrote: > On Friday, July 08, 2011, Kevin Hilman wrote: > > "Rafael J. Wysocki" writes: > > > > > From: Rafael J. Wysocki > > > > > > Make generic PM domains support system-wide power transitions > > > (system suspend and hibernation). Add suspend, resume, freeze, thaw, > > > poweroff and restore callbacks to be associated with struct > > > generic_pm_domain objects and make pm_genpd_init() use them as > > > appropriate. > > > > > > The new callbacks do nothing for devices belonging to power domains > > > that were powered down at run time (before the transition). > > > > Thinking about this some more, how is a driver supposed to reconfigure > > wakeups during suspend if it has already been runtime suspended? > > If the device belongs to a PM domain that has been powered off, it > won't be notified. > > > For example, assume a device where device_may_wakeup() == false. This > > means wakeups during *suspend* are disabled, but wakeups wakeups are > > assumed to enabled when it is runtime suspended. > > > > So now, assume this device is RPM_SUSPENDED, it has wakeups *enabled*, > > and then system suspend comes along. > > > > With this current patch, the driver will never receive any callbacks, so > > it can never disable its wakeups. > > > > Am I missing something? > > As I said above, this only happens with devices that belog to PM domains > that were powered off before system suspend has started, so the problem > is limited to devices that wakeup is signaled on behalf of even when they > have no power. > > So this is a limitation, but not affecting all platforms. > > There are a few ways to avoid this limitation I can think of: > (1) Add a "make me operational during system suspend" flag to struct dev_pm_info > and run pm_runtime_resume() on such devices from the core (either dpm_prepare() > core, or pm_genpd_prepare()). What's to prevent the device from being runtime-suspended again before the wakeup setting can be changed? > (2) Add a "my .prepare() is safe to run if device is not accessible" flag to > struct dev_pm_info and make pm_genpd_prepare() execute .prepare() for such > devices regardless of whether or not their PM domains are off. > (3) Call .prepare() from all drivers unconditionally during system suspend > (and probably .complete() too) in the hope they won't access inaccessible > devices. > Probably, there's more. In the PM domain's suspend code, do a runtime resume if the wakeup setting needs to be changed, rather than simply skipping over the device. > In any case I think it's material for future work. Alan Stern