Messages in this thread |  | | Date | Tue, 2 Jan 2018 14:26:25 +0100 | From | Greg Kroah-Hartman <> | Subject | Re: [PATCH 0/4] PM / core: Direct handling of DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED |
| |
On Tue, Jan 02, 2018 at 12:32:55PM +0100, Rafael J. Wysocki wrote: > On Sunday, December 10, 2017 12:55:23 AM CET Rafael J. Wysocki wrote: > > Hi All, > > > > This series is a follow-up for > > > > https://marc.info/?l=linux-doc&m=151101644105835&w=2 > > > > Patches[1-3/6] from the above have been reviewed and agreed on, so > > they are in linux-next now and here's a next version of the rest. > > > > Patches [1-2/4] are preparatory. The first one is just really small > > code duplication avoidance on top of this recent fix: > > > > https://patchwork.kernel.org/patch/10097563/ > > > > and the second one simply moves some code to separate functions. > > > > Patch [3/4] causes the PM core to carry out some optimizations for > > drivers of devices with DPM_FLAG_SMART_SUSPEND set whose "late" > > and "noirq" suspend (or equivalent) driver callbacks are invoked > > directly by the core. > > > > The underlying observation is that if the device is suspended (via > > runtime PM) during the "late suspend" phase of a system transition, > > invoking the "late" and "noirq" callbacks from the driver for it is not > > going to make it more suspended, so to speak, so it doesn't make sense to > > invoke them at all. > > > > [That optimization is only done for devices with DPM_FLAG_SMART_SUSPEND > > set, because drivers setting that flag are expected to be prepared for > > skipping their "late" and "noirq" callbacks if the device is already > > suspended.] > > > > Patch [4/4] makes the core do an analogous thing for devices with > > DPM_FLAG_LEAVE_SUSPENDED set whose "noirq" and "early" resume (or > > equivalent) driver callbacks are directly invoked by the core. > > > > In that case the observation is that if such devices can be left in > > suspend after the system transition to the working state, running > > resume callbacks from their drivers is simply not necessary. > > > > Pathes [3-4/4] have been reoredered and reworked a bit since the last > > iteration, so they are regarded as new. > > > > The series is on top of the linux-next branch of the linux-pm.git tree > > that should be merged into linux-next on Monday. > > > > [I have developed debug bus type and driver modules to test that code, > > but they are not ready to be made available at this point.] > > While I acknowledge that Ulf doesn't appear to be convinced by my > arguments, I also see no technical reason why this cannot go in. > > As I said during the discussion, I have tested it and it works for me > as expected. I also need it to make progress on the drivers front. > > Moreover, it should not matter for any drivers that don't set the flags > in question, so the optimizations introduced here are super-easy to avoid > by leaving those flags unset. > > So I'm going to apply the series. > > Greg, please let me know if you have objections.
No objection from me at all, please apply.
thanks,
greg k-h
|  |