From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754304Ab1GHRVA (ORCPT ); Fri, 8 Jul 2011 13:21:00 -0400 Received: from na3sys009aog111.obsmtp.com ([74.125.149.205]:37441 "EHLO na3sys009aog111.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752005Ab1GHRU6 (ORCPT ); Fri, 8 Jul 2011 13:20:58 -0400 From: Kevin Hilman To: Alan Stern Cc: "Rafael J. Wysocki" , Linux PM mailing list , Greg Kroah-Hartman , Magnus Damm , Paul Walmsley , LKML , , Paul Mundt Subject: Re: [Update][PATCH 6/10] PM / Domains: System-wide transitions support for generic domains (v5) Organization: Texas Instruments, Inc. References: Date: Fri, 08 Jul 2011 10:20:52 -0700 In-Reply-To: (Alan Stern's message of "Fri, 8 Jul 2011 10:37:32 -0400 (EDT)") Message-ID: <87y6088z9n.fsf@ti.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alan Stern writes: > 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. Which on OMAP, is *all* devices, so that's a pretty major limitation. :) >> 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. Like Alan's comment above for (1), I think the same applies for (3) since runtime PM transitions can still happen between .prepare() and .suspend() Kevin >> 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