From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 1/3] PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily Date: Fri, 16 May 2014 23:10:30 +0200 Message-ID: <2004121.oyWgtUAlR6@vostro.rjw.lan> References: Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Return-path: Received: from v094114.home.net.pl ([79.96.170.134]:49173 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751969AbaEPUxk (ORCPT ); Fri, 16 May 2014 16:53:40 -0400 In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Alan Stern Cc: Linux PM list , ACPI Devel Maling List , Aaron Lu , Mika Westerberg , Linux Kernel Mailing List , Kevin Hilman , Ulf Hansson On Friday, May 16, 2014 10:27:37 AM Alan Stern wrote: > On Fri, 16 May 2014, Rafael J. Wysocki wrote: > > > From: Rafael J. Wysocki > > > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to > > resume all runtime-suspended devices during system suspend, mostly > > because those devices may need to be reprogrammed due to different > > wakeup settings for system sleep and for runtime PM. > > > > For some devices, though, it's OK to remain in runtime suspend > > throughout a complete system suspend/resume cycle (if the device was in > > runtime suspend at the start of the cycle). We would like to do this > > whenever possible, to avoid the overhead of extra power-up and power-down > > events. > > > > However, problems may arise because the device's descendants may require > > it to be at full power at various points during the cycle. Therefore the > > most straightforward way to do this safely is if the device and all its > > descendants can remain runtime suspended until the complete stage of > > system resume. > > > > To this end, introduce a new device PM flag, power.direct_complete > > and modify the PM core to use that flag as follows. > > > > If the ->prepare() callback of a device returns a positive number, > > the PM core will regard that as an indication that it may leave the > > device runtime-suspended. It will then check if the system power > > transition in progress is a suspend (and not hibernation in particular) > > and if the device is, indeed, runtime-suspended. In that case, the PM > > core will set the device's power.direct_complete flag. Otherwise it > > will clear power.direct_complete for the device and it also will later > > clear it for the device's parent (if there's one). > > > > Next, the PM core will not invoke the ->suspend() ->suspend_late(), > > ->suspend_irq(), ->resume_irq(), ->resume_early(), or ->resume() > > callbacks for all devices having power.direct_complete set. It > > will invoke their ->complete() callbacks, however, and those > > callbacks are then responsible for resuming the devices as > > appropriate, if necessary. For example, in some cases they may > > need to queue up runtime resume requests for the devices using > > pm_request_resume(). > > > > Changelog partly based on an Alan Stern's description of the idea > > (http://marc.info/?l=linux-pm&m=139940466625569&w=2). > > > > Signed-off-by: Rafael J. Wysocki > > Acked-by: Alan Stern > > And likewise for the documentation patches. Thanks a lot!