From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Rafael J. Wysocki" Subject: Re: [PATCH 1/3] PM / sleep: New flag to speed up suspend-resume of suspended devices Date: Tue, 18 Feb 2014 14:25:42 +0100 Message-ID: <1916955.HdCFyzXUXW@vostro.rjw.lan> References: <5420830.W4laSGaAU9@vostro.rjw.lan> <21442757.ztmIxNHa8O@vostro.rjw.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7Bit Return-path: In-Reply-To: Sender: linux-pm-owner@vger.kernel.org To: Ulf Hansson Cc: Linux PM list , Alan Stern , Mika Westerberg , Aaron Lu , ACPI Devel Maling List , LKML List-Id: linux-acpi@vger.kernel.org On Tuesday, February 18, 2014 01:59:36 PM Ulf Hansson wrote: > On 17 February 2014 00:50, 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. However, at > > least in some cases, that isn't really necessary, because the wakeup > > settings may not be really different. > > > > The idea here is that subsystems should know whether or not it is > > necessary to reprogram a given device during system suspend and they > > should be able to tell the PM core about that. For this reason, > > modify the PM core so that if the .prepare() callback returns a > > positive value for certain device, the core will set a new > > power.fast_suspend flag for it. Then, if that flag is set, the core > > will skip all of the subsequent suspend callbacks for that device. > > It also will skip all of the system resume callbacks for the device > > during the subsequent system resume and pm_request_resume() will be > > executed to trigger a runtime PM resume of the device after the > > system device resume sequence has been finished. > > > > However, since parents may need to be resumed so that their children > > can be reprogrammed, make the PM core clear power.fast_suspend for > > devices whose children don't have power.fast_suspend set (the > > power.ignore_children flag doesn't matter here, because a parent > > whose children are normally ignored for runtime PM may still need to > > be accessible for their children to be prepare for system suspend > > properly). > > > > Signed-off-by: Rafael J. Wysocki > > --- > > drivers/base/power/main.c | 49 +++++++++++++++++++++++++++++++--------------- > > include/linux/pm.h | 1 > > 2 files changed, 35 insertions(+), 15 deletions(-) > > > > Index: linux-pm/drivers/base/power/main.c > > =================================================================== > > --- linux-pm.orig/drivers/base/power/main.c > > +++ linux-pm/drivers/base/power/main.c > > @@ -478,7 +478,7 @@ static int device_resume_noirq(struct de > > TRACE_DEVICE(dev); > > TRACE_RESUME(0); > > > > - if (dev->power.syscore) > > + if (dev->power.syscore || dev->power.fast_suspend) > > goto Out; > > > > if (!dev->power.is_noirq_suspended) > > @@ -599,7 +599,7 @@ static int device_resume_early(struct de > > TRACE_DEVICE(dev); > > TRACE_RESUME(0); > > > > - if (dev->power.syscore) > > + if (dev->power.syscore || dev->power.fast_suspend) > > goto Out; > > > > if (!dev->power.is_late_suspended) > > @@ -724,6 +724,11 @@ static int device_resume(struct device * > > if (dev->power.syscore) > > goto Complete; > > > > + if (dev->power.fast_suspend) { > > + pm_request_resume(dev); > > + goto Complete; > > So, this will trigger an async request to runtime resume the device. > > At device_complete(), we do pm_runtime_put() to return the reference > we fetched at device_prepare(), thus likely causing the device to be > runtime suspended again. Is that the expected sequence you need? Could > you elaborate why? That pm_runtime_put() will not cause the device to be re-suspended, because it will be executed before the resume scheduled by the pm_request_resume() above. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.