Re: [PATCH] Documentation: fix image_size default value

[Rafael J. Wysocki]

On Saturday, September 1, 2018 6:51:15 AM CEST Vladimir D. Seleznev wrote:
> This commit updates the default value of /sys/power/image_size in
> the documentation.
> 
> Since ac5c24ec1e983313ef0015258fba6f630e54e7cn the `image_size' value is
> set to about 2/5 of RAM, according to kernel/power/snapshot.c:
> 
>   image_size = ((totalram_pages * 2) / 5) * PAGE_SIZE;
> 
> but this change was not reflected everywhere in the documentation.
> 
> Signed-off-by: Vladimir D. Seleznev 
> ---
>  Documentation/ABI/testing/sysfs-power | 2 +-
>  Documentation/power/swsusp.txt| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-power 
> b/Documentation/ABI/testing/sysfs-power
> index 2f813d644c69..18b7dc929234 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -99,7 +99,7 @@ Description:
>   this file, the suspend image will be as small as possible.
>  
>   Reading from this file will display the current image size
> - limit, which is set to 500 MB by default.
> + limit, which is set to around 2/5 of available RAM by default.
>  
>  What:/sys/power/pm_trace
>  Date:August 2006
> diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
> index cc87adf44c0a..236d1fb13640 100644
> --- a/Documentation/power/swsusp.txt
> +++ b/Documentation/power/swsusp.txt
> @@ -56,7 +56,7 @@ If you want to limit the suspend image size to N bytes, do
>  
>  echo N > /sys/power/image_size
>  
> -before suspend (it is limited to 500 MB by default).
> +before suspend (it is limited to around 2/5 of available RAM by default).
>  
>  . The resume process checks for the presence of the resume device,
>  if found, it then checks the contents for the hibernation image signature.
> 

Applied, thanks!

Re: [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

[Rafael J. Wysocki]

On Wed, May 23, 2018 at 3:34 AM, Dou Liyang  wrote:
> At 05/22/2018 09:47 AM, Dou Liyang wrote:
>>
>>
>>
>> At 05/19/2018 11:06 PM, Thomas Gleixner wrote:
>>>
>>> On Tue, 20 Mar 2018, Dou Liyang wrote:
>>>
 ACPI driver should make sure all the processor IDs in their ACPI
 Namespace
 are unique for CPU hotplug. the driver performs a depth-first walk of
 the
 namespace tree and calls the acpi_processor_ids_walk().

 But, the acpi_processor_ids_walk() will return true if one processor is
 checked, that cause the walk break after walking pass the first
 processor.

 Repace the value with AE_OK which is the standard acpi_status value.

 Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for
 processor enumeration")

 Signed-off-by: Dou Liyang 
 ---
   drivers/acpi/acpi_processor.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/acpi/acpi_processor.c
 b/drivers/acpi/acpi_processor.c
 index 449d86d39965..db5bdb59639c 100644
 --- a/drivers/acpi/acpi_processor.c
 +++ b/drivers/acpi/acpi_processor.c
 @@ -663,11 +663,11 @@ static acpi_status __init (acpi_handle handle,
   }
   processor_validated_ids_update(uid);
 -return true;
 +return AE_OK;
   err:
   acpi_handle_info(handle, "Invalid processor object\n");
 -return false;
 +return AE_OK;
>>>
>>>
>>> I'm not sure whether this is the right return value here. Rafael?
>>>
>
> +Cc Rafael's common used email address.
>
> I am sorry, I created the cc list using ./script/get_maintainers.pl ...
> and didn't check it.

No worries, I saw your messages, but thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM: docs: sleep-states: Fix a typo ("includig")

[Rafael J. Wysocki]

On Wednesday, April 25, 2018 12:07:03 PM CEST Jonathan Neuschäfer wrote:
> Signed-off-by: Jonathan Neuschäfer 
> ---
>  Documentation/admin-guide/pm/sleep-states.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/admin-guide/pm/sleep-states.rst 
> b/Documentation/admin-guide/pm/sleep-states.rst
> index 1e5c0f00cb2f..dbf5acd49f35 100644
> --- a/Documentation/admin-guide/pm/sleep-states.rst
> +++ b/Documentation/admin-guide/pm/sleep-states.rst
> @@ -15,7 +15,7 @@ Sleep States That Can Be Supported
>  ==
>  
>  Depending on its configuration and the capabilities of the platform it runs 
> on,
> -the Linux kernel can support up to four system sleep states, includig
> +the Linux kernel can support up to four system sleep states, including
>  hibernation and up to three variants of system suspend.  The sleep states 
> that
>  can be supported by the kernel are listed below.
>  
> 

Applied and pushed for 4.17-rc5, thanks!


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/admin-guide/pm/intel_pstate: fix Active Mode w/o HWP paragraph

[Rafael J. Wysocki]

On Tuesday, May 8, 2018 8:36:44 PM CEST Srinivas Pandruvada wrote:
> On Tue, 2018-05-08 at 17:12 +0200, Juri Lelli wrote:
> > P-state selection algorithm (powersave or performance) is selected by
> > echoing the desired choice to scaling_governor sysfs attribute and
> > not
> > to scaling_cur_freq (as currently stated).
> > 
> > Fix it.
> Thanks for the fix.
> 
> > 
> > Signed-off-by: Juri Lelli <juri.le...@redhat.com>
> > Cc: Jonathan Corbet <cor...@lwn.net>
> > Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com>
> > Cc: Srinivas Pandruvada <srinivas.pandruv...@linux.intel.com>
> > Cc: linux-doc@vger.kernel.org
> > Cc: linux...@vger.kernel.org
> Reviewed-by: Srinivas Pandruvada <srinivas.pandruv...@linux.intel.com>
> 
> 
> > 
> > ---
> >  Documentation/admin-guide/pm/intel_pstate.rst | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/admin-guide/pm/intel_pstate.rst
> > b/Documentation/admin-guide/pm/intel_pstate.rst
> > index d2b6fda3d67b..ab2fe0eda1d7 100644
> > --- a/Documentation/admin-guide/pm/intel_pstate.rst
> > +++ b/Documentation/admin-guide/pm/intel_pstate.rst
> > @@ -145,7 +145,7 @@ feature enabled.]
> >  
> >  In this mode ``intel_pstate`` registers utilization update callbacks
> > with the
> >  CPU scheduler in order to run a P-state selection algorithm, either
> > -``powersave`` or ``performance``, depending on the
> > ``scaling_cur_freq`` policy
> > +``powersave`` or ``performance``, depending on the
> > ``scaling_governor`` policy
> >  setting in ``sysfs``.  The current CPU frequency information to be
> > made
> >  available from the ``scaling_cur_freq`` policy attribute in
> > ``sysfs`` is
> >  periodically updated by those utilization update callbacks too.
> 

Applied and pushed for 4.17-rc5, thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

On Wednesday, November 22, 2017 2:10:51 AM CET Rafael J. Wysocki wrote:
> On Monday, November 20, 2017 2:42:26 PM CET Ulf Hansson wrote:
> > On 18 November 2017 at 15:41, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > >
> > > Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
> > > devices whose "noirq", "late" and "early" driver callbacks are
> > > invoked directly by it.
> > 
> > This indicates that your target for this particular change isn't
> > ACPI/PCI, but instead this aims to be a more generic solution to be
> > able to optimize the resume path for devices.
> > 
> > Assuming, this is the case, I don't think this is good enough as I
> > pointed out [1] earlier. Simply because it isn't as flexible as is
> > required - to really be able cover generic cases.
> 
> I'll go back to that message, but nothing so far has been flexible enough to
> cover everything you can imagine.
> 
> The case this and the next patch cover really is to allow drivers that can be
> used with or without a PM domain to avoid doing any "are we suspended?" type
> of checks in their callbacks.  Actually, the [6/6] is more important from that
> standpoint, but this one also may play the role because of the dependencies
> between devices involved in the handling of LEAVE_SUSPENDED (eg. say a PCI
> parent has a child platform or I2C or similar devices without a PM domain
> and what happens to the child affects the parent).
> 
> > >
> > > Namely, make it skip all of the system-wide resume callbacks for
> > > such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
> > > runtime suspend during the "noirq" phase of system-wide suspend
> > > (or analogous) transitions or the system transition under way is
> > > a proper suspend (rather than anything related to hibernation) and
> > > the device's wakeup settings are compatible with runtime PM (that
> > > is, the device cannot generate wakeup signals at all or it is
> > > allowed to wake up the system from sleep).
> > 
> > As I pointed out by submitting another patch [2], device_may_wakeup()
> > doesn't really tell whether the wakeup is configured as "in-band" or
> > "out-of-band". That knowledge is known by the driver and the subsystem
> > layer - and for that reason I don't think the PM core shall base
> > generic decisions like this on it.
> 
> The "or it is allowed to wake up the system from sleep" case may be overly
> optimistic, but the remaining two (runtime-suspended devices and devices
> that can't generate wakeup signals at all) are quite straightforward to me.

BTW, I'm not sure if the device_may_wakeup() check is really insufficient
in this particular case.

Say the device was not in runtime suspend before, but device_may_wakeup()
returns "true" for it and the system is resuming from suspend.  The device's
state should be suitable to wake up the system in any case, so the "in-band"
vs "out-of-band" difference has had to be taken care of already during system
suspend.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

On Monday, November 20, 2017 2:42:26 PM CET Ulf Hansson wrote:
> On 18 November 2017 at 15:41, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >
> > Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
> > devices whose "noirq", "late" and "early" driver callbacks are
> > invoked directly by it.
> 
> This indicates that your target for this particular change isn't
> ACPI/PCI, but instead this aims to be a more generic solution to be
> able to optimize the resume path for devices.
> 
> Assuming, this is the case, I don't think this is good enough as I
> pointed out [1] earlier. Simply because it isn't as flexible as is
> required - to really be able cover generic cases.

I'll go back to that message, but nothing so far has been flexible enough to
cover everything you can imagine.

The case this and the next patch cover really is to allow drivers that can be
used with or without a PM domain to avoid doing any "are we suspended?" type
of checks in their callbacks.  Actually, the [6/6] is more important from that
standpoint, but this one also may play the role because of the dependencies
between devices involved in the handling of LEAVE_SUSPENDED (eg. say a PCI
parent has a child platform or I2C or similar devices without a PM domain
and what happens to the child affects the parent).

> >
> > Namely, make it skip all of the system-wide resume callbacks for
> > such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
> > runtime suspend during the "noirq" phase of system-wide suspend
> > (or analogous) transitions or the system transition under way is
> > a proper suspend (rather than anything related to hibernation) and
> > the device's wakeup settings are compatible with runtime PM (that
> > is, the device cannot generate wakeup signals at all or it is
> > allowed to wake up the system from sleep).
> 
> As I pointed out by submitting another patch [2], device_may_wakeup()
> doesn't really tell whether the wakeup is configured as "in-band" or
> "out-of-band". That knowledge is known by the driver and the subsystem
> layer - and for that reason I don't think the PM core shall base
> generic decisions like this on it.

The "or it is allowed to wake up the system from sleep" case may be overly
optimistic, but the remaining two (runtime-suspended devices and devices
that can't generate wakeup signals at all) are quite straightforward to me.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Mon, Nov 20, 2017 at 1:25 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 18 November 2017 at 15:31, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
>> code that it is desirable to leave the device in runtime suspend
>> after system-wide transitions to the working state (for example,
>> the device may be slow to resume and it may be better to avoid
>> resuming it right away).
>>
>> Generally, the middle-layer code involved in the handling of the
>> device is expected to indicate to the PM core whether or not the
>> device may be left in suspend with the help of the device's
>> power.may_skip_resume status bit.  That has to happen in the "noirq"
>> phase of the preceding system suspend (or analogous) transition.
>> The middle layer is then responsible for handling the device as
>> appropriate in its "noirq" resume callback which is executed
>> regardless of whether or not the device may be left suspended, but
>> the other resume callbacks (except for ->complete) will be skipped
>> automatically by the core if the device really can be left in
>> suspend.
>>
>> The additional power.must_resume status bit introduced for the
>> implementation of this mechanisn is used internally by the PM core
>> to track the requirement to resume the device (which may depend on
>> its children etc).
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/6] PCI / PM: Support for LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the PCI bus type by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from pci_pm_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
---

v3 -> v4: No changes.

v2 -> v3: Add the Acked-by from Bjorn, no changes in the patch.

---
 Documentation/power/pci.txt |   11 +++
 drivers/pci/pci-driver.c|   19 +--
 2 files changed, 28 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -699,7 +699,7 @@ static void pci_pm_complete(struct devic
pm_generic_complete(dev);
 
/* Resume device if platform firmware has put it in reset-power-on */
-   if (dev->power.direct_complete && pm_resume_via_firmware()) {
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware()) {
pci_power_t pre_sleep_state = pci_dev->current_state;
 
pci_update_current_state(pci_dev, pci_dev->current_state);
@@ -783,8 +783,10 @@ static int pci_pm_suspend_noirq(struct d
struct pci_dev *pci_dev = to_pci_dev(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
 
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_suspend_late(dev, PMSG_SUSPEND);
@@ -838,6 +840,16 @@ static int pci_pm_suspend_noirq(struct d
 Fixup:
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
 
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* pci_pm_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
return 0;
 }
 
@@ -847,6 +859,9 @@ static int pci_pm_resume_noirq(struct de
struct device_driver *drv = dev->driver;
int error = 0;
 
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"
Index: linux-pm/Documentation/power/pci.txt
===
--- linux-pm.orig/Documentation/power/pci.txt
+++ linux-pm/Documentation/power/pci.txt
@@ -994,6 +994,17 @@ into D0 going forward), but if it is in
 the function will set the power.direct_complete flag for it (to make the PM 
core
 skip the subsequent "thaw" callbacks for it) and return.
 
+Setting the DPM_FLAG_LEAVE_SUSPENDED flag means that the driver prefers the
+device to be left in suspend after system-wide transitions to the working 
state.
+This flag is checked by the PM core, but the PCI bus type informs the PM core
+which devices may be left in suspend from its perspective (that happens during
+the "noirq" phase of system-wide suspend and analogous transitions) and next it
+uses the dev_pm_may_skip_resume() helper to decide whether or not to return 
from
+pci_pm_resume_noirq() early, as the PM core will skip the remaining resume
+callbacks for the device during the transition under way and will set its
+runtime PM status to "suspended" if dev_pm_may_skip_resume() returns "true" for
+it.
+
 3.2. Device Runtime Power Management
 
 In addition to providing device power management callbacks PCI device drivers

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 4/6] PM / core: Add helpers for subsystem callback selection

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add helper routines to find and return a suitable subsystem callback
during the "noirq" phases of system suspend/resume (or analogous)
transitions as well as during the "late" phase of system suspend and
the "early" phase of system resume (or analogous) transitions.

The helpers will be called from additional sites going forward.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
---

v3 -> v4: Move forward declarations of two functions to subsequent patches,
  add Reviewed-by from Ulf.

v2 -> v3: No changes.

---
 drivers/base/power/main.c |  188 +++---
 1 file changed, 128 insertions(+), 60 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -539,6 +539,35 @@ bool dev_pm_may_skip_resume(struct devic
return !dev->power.must_resume && pm_transition.event != 
PM_EVENT_RESTORE;
 }
 
+static pm_callback_t dpm_subsys_resume_noirq_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "noirq power domain ";
+   callback = pm_noirq_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "noirq type ";
+   callback = pm_noirq_op(dev->type->pm, state);
+   } else if (dev->class && dev->class->pm) {
+   info = "noirq class ";
+   callback = pm_noirq_op(dev->class->pm, state);
+   } else if (dev->bus && dev->bus->pm) {
+   info = "noirq bus ";
+   callback = pm_noirq_op(dev->bus->pm, state);
+   } else {
+   return NULL;
+   }
+
+   if (info_p)
+   *info_p = info;
+
+   return callback;
+}
+
 /**
  * device_resume_noirq - Execute a "noirq resume" callback for given device.
  * @dev: Device to handle.
@@ -550,8 +579,8 @@ bool dev_pm_may_skip_resume(struct devic
  */
 static int device_resume_noirq(struct device *dev, pm_message_t state, bool 
async)
 {
-   pm_callback_t callback = NULL;
-   const char *info = NULL;
+   pm_callback_t callback;
+   const char *info;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -565,19 +594,7 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
-   if (dev->pm_domain) {
-   info = "noirq power domain ";
-   callback = pm_noirq_op(>pm_domain->ops, state);
-   } else if (dev->type && dev->type->pm) {
-   info = "noirq type ";
-   callback = pm_noirq_op(dev->type->pm, state);
-   } else if (dev->class && dev->class->pm) {
-   info = "noirq class ";
-   callback = pm_noirq_op(dev->class->pm, state);
-   } else if (dev->bus && dev->bus->pm) {
-   info = "noirq bus ";
-   callback = pm_noirq_op(dev->bus->pm, state);
-   }
+   callback = dpm_subsys_resume_noirq_cb(dev, state, );
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -693,6 +710,35 @@ void dpm_resume_noirq(pm_message_t state
dpm_noirq_end();
 }
 
+static pm_callback_t dpm_subsys_resume_early_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "early power domain ";
+   callback = pm_late_early_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "early type ";
+   callback = pm_late_early_op(dev->type->pm, state);
+   } else if (dev->class && dev->class->pm) {
+   info = "early class ";
+   callback = pm_late_early_op(dev->class->pm, state);
+   } else if (dev->bus && dev->bus->pm) {
+   info = "early bus ";
+   callback = pm_late_early_op(dev->bus->pm, state);
+   } else {
+   return NULL;
+   }
+
+   if (info_p)
+   *info_p = info;
+
+   ret

Re: [PATCH v4 0/6] PM / sleep: Driver flags for system suspend/resume (part 2)

[Rafael J. Wysocki]

Hi All,

The following still applies:

> On Wednesday, November 8, 2017 1:41:35 AM CET Rafael J. Wysocki wrote:
> >
> > This is a follow-up for the first part of the PM driver flags series
> > sent previously some time ago with an intro as follows:
> > 
> > On Saturday, October 28, 2017 12:11:55 AM CET Rafael J. Wysocki wrote:
> > > The following part of the original cover letter still applies:
> > > 
> > > On Monday, October 16, 2017 3:12:35 AM CEST Rafael J. Wysocki wrote:
> > > > 
> > > > This work was triggered by attempts to fix and optimize PM in the
> > > > i2c-designware-platdev driver that ended up with adding a couple of
> > > > flags to the driver's internal data structures for the tracking of
> > > > device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> > > > That approach is sort of suboptimal, though, because other drivers will
> > > > probably want to do similar things and if all of them need to use 
> > > > internal
> > > > flags for that, quite a bit of code duplication may ensue at least.
> > > > 
> > > > That can be avoided in a couple of ways and one of them is to provide a 
> > > > means
> > > > for drivers to tell the core what to do and to make the core take care 
> > > > of it
> > > > if told to do so.  Hence, the idea to use driver flags for system-wide 
> > > > PM
> > > > that was briefly discussed during the LPC in LA last month.
> > > 
> > > [...]
> > > 
> > > > What can work (and this is the only strategy that can work AFAICS) is to
> > > > point different callback pointers *in* *a* *driver* to the same routine
> > > > if the driver wants to reuse that code.  That actually will work for PCI
> > > > and USB drivers today, at least most of the time, but unfortunately 
> > > > there
> > > > are problems with it for, say, platform devices.
> > > > 
> > > > The first problem is the requirement to track the status of the device
> > > > (suspended vs not suspended) in the callbacks, because the system-wide 
> > > > PM
> > > > code in the PM core doesn't do that.  The runtime PM framework does it, 
> > > > so
> > > > this means adding some extra code which isn't necessary for runtime PM 
> > > > to
> > > > the callback routines and that is not particularly nice.
> > > > 
> > > > The second problem is that, if the driver wants to do anything in its
> > > > ->suspend callback, it generally has to prevent runtime suspend of the
> > > > device from taking place in parallel with that, which is quite 
> > > > cumbersome.
> > > > Usually, that is taken care of by resuming the device from runtime 
> > > > suspend
> > > > upfront, but generally doing that is wasteful (there may be no real 
> > > > need to
> > > > resume the device except for the fact that the code is designed this 
> > > > way).
> > > > 
> > > > On top of the above, there are optimizations to be made, like leaving 
> > > > certain
> > > > devices in suspend after system resume to avoid wasting time on waiting 
> > > > for
> > > > them to resume before user space can run again and similar.
> > > > 
> > > > This patch series focuses on addressing those problems so as to make it
> > > > easier to reuse callback routines by pointing different callback 
> > > > pointers
> > > > to them in device drivers.  The flags introduced here are to instruct 
> > > > the
> > > > PM core and middle layers (whatever they are) on how the driver wants 
> > > > the
> > > > device to be handled and then the driver has to provide callbacks to 
> > > > match
> > > > these instructions and the rest should be taken care of by the code 
> > > > above it.
> > > > 
> > > > The flags are introduced one by one to avoid making too many changes in
> > > > one go and to allow things to be explained better (hopefully).  They 
> > > > mostly
> > > > are mutually independent with some clearly documented exceptions.
> > > 
> > > but I had to rework the core patches to address the problem pointed with 
> > > the
> > > generic power domains (genpd) framework pointed out by Ulf.
> > > 
> > > Namely, genpd expects its "noirq" 

[PATCH v4 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
instruct the PM core and middle-layer (bus type, PM domain, etc.)
code that it is desirable to leave the device in runtime suspend
after system-wide transitions to the working state (for example,
the device may be slow to resume and it may be better to avoid
resuming it right away).

Generally, the middle-layer code involved in the handling of the
device is expected to indicate to the PM core whether or not the
device may be left in suspend with the help of the device's
power.may_skip_resume status bit.  That has to happen in the "noirq"
phase of the preceding system suspend (or analogous) transition.
The middle layer is then responsible for handling the device as
appropriate in its "noirq" resume callback which is executed
regardless of whether or not the device may be left suspended, but
the other resume callbacks (except for ->complete) will be skipped
automatically by the core if the device really can be left in
suspend.

The additional power.must_resume status bit introduced for the
implementation of this mechanisn is used internally by the PM core
to track the requirement to resume the device (which may depend on
its children etc).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

v3 -> v4: Fix the dev->power.usage_count check added in v3, clarify
  documentation, add comment to explain why the runtime PM status
  is changed in device_resume_noirq() and make the description of
  the NEVER_SKIP flag more precise.

v2 -> v3: Take dev->power.usage_count when updating power.must_resume in
  __device_suspend_noirq().

---
 Documentation/driver-api/pm/devices.rst |   27 ++-
 drivers/base/power/main.c   |   73 +---
 include/linux/pm.h  |   16 +--
 3 files changed, 105 insertions(+), 11 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -556,9 +556,10 @@ struct pm_subsys_data {
  * These flags can be set by device drivers at the probe time.  They need not 
be
  * cleared by the drivers as the driver core will take care of that.
  *
- * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
+ * NEVER_SKIP: Do not skip all system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
+ * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -572,10 +573,14 @@ struct pm_subsys_data {
  * necessary from the driver's perspective.  It also may cause them to skip
  * invocations of the ->suspend_late and ->suspend_noirq callbacks provided by
  * the driver if they decide to leave the device in runtime suspend.
+ *
+ * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that the
+ * driver prefers the device to be left in suspend after system resume.
  */
-#define DPM_FLAG_NEVER_SKIPBIT(0)
-#define DPM_FLAG_SMART_PREPARE BIT(1)
-#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
 
 struct dev_pm_info {
pm_message_tpower_state;
@@ -597,6 +602,8 @@ struct dev_pm_info {
boolwakeup_path:1;
boolsyscore:1;
boolno_pm_callbacks:1;  /* Owned by the PM core 
*/
+   unsigned intmust_resume:1;  /* Owned by the PM core */
+   unsigned intmay_skip_resume:1;  /* Set by subsystems */
 #else
unsigned intshould_wakeup:1;
 #endif
@@ -765,6 +772,7 @@ extern int pm_generic_poweroff_late(stru
 extern int pm_generic_poweroff(struct device *dev);
 extern void pm_generic_complete(struct device *dev);
 
+extern bool dev_pm_may_skip_resume(struct device *dev);
 extern bool dev_pm_smart_suspend_and_suspended(struct device *dev);
 
 #else /* !CONFIG_PM_SLEEP */
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -528,6 +528,18 @@ static void dpm_watchdog_clear(struct dp
 /*- Resume routines -*/
 
 /**
+ * dev_pm_may_skip_resume - System-wide device resume optimization check.
+ *

[PATCH v4 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the ACPI PM domain by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from acpi_subsys_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

v2 -> v4: No changes.

---
 drivers/acpi/device_pm.c |   27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -990,7 +990,7 @@ void acpi_subsys_complete(struct device
 * the sleep state it is going out of and it has never been resumed till
 * now, resume it in case the firmware powered it up.
 */
-   if (dev->power.direct_complete && pm_resume_via_firmware())
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_complete);
@@ -1039,10 +1039,28 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_la
  */
 int acpi_subsys_suspend_noirq(struct device *dev)
 {
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   int ret;
+
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
-   return pm_generic_suspend_noirq(dev);
+   ret = pm_generic_suspend_noirq(dev);
+   if (ret)
+   return ret;
+
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* acpi_subsys_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
+   return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
 
@@ -1052,6 +1070,9 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_no
  */
 int acpi_subsys_resume_noirq(struct device *dev)
 {
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
devices whose "noirq", "late" and "early" driver callbacks are
invoked directly by it.

Namely, make it skip all of the system-wide resume callbacks for
such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
runtime suspend during the "noirq" phase of system-wide suspend
(or analogous) transitions or the system transition under way is
a proper suspend (rather than anything related to hibernation) and
the device's wakeup settings are compatible with runtime PM (that
is, the device cannot generate wakeup signals at all or it is
allowed to wake up the system from sleep).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

v3 -> v4: Rebase on the v4 of patch [1/6], add a forward declaration of
  dpm_subsys_suspend_late_cb() dropped from the [4/6].

v2 -> v3: Rebase on the v3 of patch [1/6].

---
 Documentation/driver-api/pm/devices.rst |9 +
 drivers/base/power/main.c   |   51 
 2 files changed, 55 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -525,6 +525,10 @@ static void dpm_watchdog_clear(struct dp
 #define dpm_watchdog_clear(x)
 #endif
 
+static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p);
+
 /*- Resume routines -*/
 
 /**
@@ -581,6 +585,7 @@ static int device_resume_noirq(struct de
 {
pm_callback_t callback;
const char *info;
+   bool skip_resume;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -594,17 +599,27 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
+   skip_resume = dev_pm_may_skip_resume(dev);
+
callback = dpm_subsys_resume_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
+
+   if (skip_resume)
+   goto Skip;
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
+
+Skip:
dev->power.is_noirq_suspended = false;
 
-   if (dev_pm_may_skip_resume(dev)) {
+   if (skip_resume) {
/*
 * The device is going to be left in suspend, but it might not
 * have been in runtime suspend before the system suspended, so
@@ -617,7 +632,7 @@ static int device_resume_noirq(struct de
dev->power.is_suspended = false;
}
 
- Out:
+Out:
complete_all(>power.completion);
TRACE_RESUME(error);
return error;
@@ -1193,6 +1208,7 @@ static int __device_suspend_noirq(struct
 {
pm_callback_t callback;
const char *info;
+   bool direct_cb = false;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -1212,12 +1228,17 @@ static int __device_suspend_noirq(struct
goto Complete;
 
callback = dpm_subsys_suspend_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
 
-   if (!callback && dev->driver && dev->driver->pm) {
+   direct_cb = true;
+
+   if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
if (error) {
async_error = error;
@@ -1227,13 +1248,33 @@ static int __device_suspend_noirq(struct
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
+   pm_message_t resume_msg = resume_event(state);
+   bool skip_resume;
+
+   if (direct_cb &&
+   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
+   !dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
+   !dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL)) {
+   /*
+* If all of the device driver's "noirq", "late" and
+* "early" callbacks are invoked directly by the core,
+* the decision to allow the device to stay in suspend
+* can be based on its current runtime PM status and its
+* wakeup settings.
+  

[PATCH v4 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks for devices that are in runtime
suspend during the corresponding phases of system-wide suspend
(or analogous) transitions.

The underlying observation is that runtime PM is disabled for
devices during those system-wide suspend phases, so their runtime
PM status should not change going forward and if it has not changed
so far, their state should be compatible with the target system
sleep state.

This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

v3 -> v4: Add a forward declaration of dpm_subsys_suspend_noirq_cb()
  dropped from patch [4/6].

v2 -> v3: No changes.

---
 Documentation/driver-api/pm/devices.rst |   18 
 drivers/base/power/main.c   |   66 +---
 2 files changed, 70 insertions(+), 14 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -525,6 +525,10 @@ static void dpm_watchdog_clear(struct dp
 #define dpm_watchdog_clear(x)
 #endif
 
+static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev,
+pm_message_t state,
+const char **info_p);
+
 static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
pm_message_t state,
const char **info_p);
@@ -532,6 +536,24 @@ static pm_callback_t dpm_subsys_suspend_
 /*- Resume routines -*/
 
 /**
+ * suspend_event - Return a "suspend" message for given "resume" one.
+ * @resume_msg: PM message representing a system-wide resume transition.
+ */
+static pm_message_t suspend_event(pm_message_t resume_msg)
+{
+   switch (resume_msg.event) {
+   case PM_EVENT_RESUME:
+   return PMSG_SUSPEND;
+   case PM_EVENT_THAW:
+   case PM_EVENT_RESTORE:
+   return PMSG_FREEZE;
+   case PM_EVENT_RECOVER:
+   return PMSG_HIBERNATE;
+   }
+   return PMSG_ON;
+}
+
+/**
  * dev_pm_may_skip_resume - System-wide device resume optimization check.
  * @dev: Target device.
  *
@@ -605,6 +627,25 @@ static int device_resume_noirq(struct de
if (callback)
goto Run;
 
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   pm_message_t suspend_msg = suspend_event(state);
+
+   /*
+* If "freeze" callbacks have been skipped during a transition
+* related to hibernation, the subsequent "thaw" callbacks must
+* be skipped too or bad things may happen.  Otherwise, if the
+* device is to be resumed, its runtime PM status must be
+* changed to reflect the new configuration.
+*/
+   if (!dpm_subsys_suspend_late_cb(dev, suspend_msg, NULL) &&
+   !dpm_subsys_suspend_noirq_cb(dev, suspend_msg, NULL)) {
+   if (state.event == PM_EVENT_THAW)
+   skip_resume = true;
+   else if (!skip_resume)
+   pm_runtime_set_active(dev);
+   }
+   }
+
if (skip_resume)
goto Skip;
 
@@ -1231,7 +1272,10 @@ static int __device_suspend_noirq(struct
if (callback)
goto Run;
 
-   direct_cb = true;
+   direct_cb = !dpm_subsys_suspend_late_cb(dev, state, NULL);
+
+   if (dev_pm_smart_suspend_and_suspended(dev) && direct_cb)
+   goto Skip;
 
if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -1245,6 +1289,7 @@ Run:
goto Complete;
}
 
+Skip:
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
@@ -1252,7 +1297,6 @@ Run:
bool skip_resume;
 
if (direct_cb &&
-   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
!dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
!dpm_subsys_resume_noirq_cb(de

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Fri, Nov 17, 2017 at 2:49 PM, Ulf Hansson  wrote:
> [...]
>
>>>
> Second, have you considered setting the default value of
> dev->power.may_skip_resume to true?

 Yes.

> That would means the subsystem
> instead need to implement an opt-out method. I am thinking that it may
> not be an issue, since we anyway at this point, don't have drivers
> using the LEAVE_SUSPENDED flag.

 Opt-out doesn't work because of the need to invoke the "noirq" callbacks.
>>>
>>> I am not sure I follow that.
>>>
>>> Whatever needs to be fixed on the subsystem level, that could be done
>>> before the driver starts using the LEAVE_SUSPENDED flag. No?
>>
>> That requires a bit of explanation, sorry for being overly concise.
>>
>> The core calls ->resume_noirq from the middle layer regardless of
>> whether or not the device will be left suspended, so the
>> ->resume_noirq cannot do arbitrary things to it.  Setting
>> may_skip_resume by the middle layer tells the core that the middle
>> layer is ready for that and is going to cooperate.  If may_skip_resume
>> had been set by default, that piece of information would have been
>> missing.
>
> Huh, I still don't get that. Sorry.
>
> If the "may_skip_resume" is default set to true by the PM core,
> wouldn't that just mean that the middle-layer needs to implement an
> opt-out method, rather than opt-in. In principle to opt-out the
> middle-layer needs to set may_skip_resume to false in suspend_noirq
> phase, no?

Yes, but if the middle-layer doesn't clear it, that may mean two
things.  First, the middle layer is ready and so on.  Good.  Second,
the middle layer is not aware of the whole thing.  Not good.  The core
cannot tell.

In the opt-in case, however, all is clear. :-)

> Then we only need to make sure drivers don't starts use
> LEAVE_SUSPENDED, before we make sure the middle layers is adopted. But
> that should not be a problem.
>
> The benefit would be that those middle layers that can cope with
> LEAVE_SUSPENDED as of today don't need to change.

I'm not sure if that's the case.

The middle layer has to evaluate dev_pm_may_skip_resume() in
->resume_noirq() to check if the device can be left in suspend, as it
cannot determine that in ->suspend_noirq() yet.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Fri, Nov 17, 2017 at 7:11 AM, Ulf Hansson  wrote:
> [...]
>
>>> > +++ linux-pm/include/linux/pm.h
>>> > @@ -559,6 +559,7 @@ struct pm_subsys_data {
>>> >   * NEVER_SKIP: Do not skip system suspend/resume callbacks for the 
>>> > device.
>>> >   * SMART_PREPARE: Check the return value of the driver's ->prepare 
>>> > callback.
>>> >   * SMART_SUSPEND: No need to resume the device from runtime suspend.
>>> > + * LEAVE_SUSPENDED: Avoid resuming the device during system resume if 
>>> > possible.
>>> >   *
>>> >   * Setting SMART_PREPARE instructs bus types and PM domains which may 
>>> > want
>>> >   * system suspend/resume callbacks to be skipped for the device to 
>>> > return 0 from
>>> > @@ -572,10 +573,14 @@ struct pm_subsys_data {
>>> >   * necessary from the driver's perspective.  It also may cause them to 
>>> > skip
>>> >   * invocations of the ->suspend_late and ->suspend_noirq callbacks 
>>> > provided by
>>> >   * the driver if they decide to leave the device in runtime suspend.
>>> > + *
>>> > + * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code 
>>> > that the
>>> > + * driver prefers the device to be left in runtime suspend after system 
>>> > resume.
>>> >   */
>>>
>>> Question: Can LEAVE_SUSPENDED and NEVER_SKIP be valid combination? I
>>> guess not!? Should we validate for wrong combinations?
>>
>> Why not?  There's no real overlap between them.
>
> Except that NEVER_SKIP, documentation wise, tells you that your
> suspend and resume callbacks will never be skipped. :-)

You mean the comment in pm.h I suppose?  Yes, it isn't precise enough.

The proper documentation in devices.rst is less ambiguous, though. :-)

> [...]
>
>>> Second, have you considered setting the default value of
>>> dev->power.may_skip_resume to true?
>>
>> Yes.
>>
>>> That would means the subsystem
>>> instead need to implement an opt-out method. I am thinking that it may
>>> not be an issue, since we anyway at this point, don't have drivers
>>> using the LEAVE_SUSPENDED flag.
>>
>> Opt-out doesn't work because of the need to invoke the "noirq" callbacks.
>
> I am not sure I follow that.
>
> Whatever needs to be fixed on the subsystem level, that could be done
> before the driver starts using the LEAVE_SUSPENDED flag. No?

That requires a bit of explanation, sorry for being overly concise.

The core calls ->resume_noirq from the middle layer regardless of
whether or not the device will be left suspended, so the
->resume_noirq cannot do arbitrary things to it.  Setting
may_skip_resume by the middle layer tells the core that the middle
layer is ready for that and is going to cooperate.  If may_skip_resume
had been set by default, that piece of information would have been
missing.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Fri, Nov 17, 2017 at 12:07 AM, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote:
>> On 12 November 2017 at 01:37, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> >
>> > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> > instruct the PM core and middle-layer (bus type, PM domain, etc.)
>> > code that it is desirable to leave the device in runtime suspend
>> > after system-wide transitions to the working state (for example,
>> > the device may be slow to resume and it may be better to avoid
>> > resuming it right away).
>> >
>> > Generally, the middle-layer code involved in the handling of the
>> > device is expected to indicate to the PM core whether or not the
>> > device may be left in suspend with the help of the device's
>> > power.may_skip_resume status bit.  That has to happen in the "noirq"
>> > phase of the preceding system suspend (or analogous) transition.
>> > The middle layer is then responsible for handling the device as
>> > appropriate in its "noirq" resume callback which is executed
>> > regardless of whether or not the device may be left suspended, but
>> > the other resume callbacks (except for ->complete) will be skipped
>> > automatically by the core if the device really can be left in
>> > suspend.
>> >
>> > The additional power.must_resume status bit introduced for the
>> > implementation of this mechanisn is used internally by the PM core
>> > to track the requirement to resume the device (which may depend on
>> > its children etc).
>> >
>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> > ---
>> >
>> > v2 -> v3: Take dev->power.usage_count when updating power.must_resume in
>> >   __device_suspend_noirq().
>> >
>> > ---

[...]

>> > +   } else {
>> > +   dev->power.must_resume = true;
>> > +   }
>> > +
>> > +   if (dev->power.must_resume)
>> > +   dpm_superior_set_must_resume(dev);
>> >
>> >  Complete:
>> > complete_all(>power.completion);
>> > @@ -1487,6 +1539,9 @@ static int __device_suspend(struct devic
>> > dev->power.direct_complete = false;
>> > }
>> >
>> > +   dev->power.may_skip_resume = false;
>> > +   dev->power.must_resume = false;
>> > +
>>
>> First, these assignment could be bypassed if the direct_complete path
>> is used. Perhaps it's more robust to reset these flags already in
>> device_prepare().
>
> In the direct-complete case may_skip_resume doesn't matter.
>
> must_resume should be set to "false", however, so that parents of
> direct-complete devices may be left in suspend (in case they don't
> fall under direct-complete themselves), so good catch.

Actually, not really.

must_resume for parents/suppliers is not updated if the device has
direct_complete set and the device's own must_resume doesn't matter
then.

So this part is good as is AFAICS.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Thursday, November 16, 2017 4:10:16 PM CET Ulf Hansson wrote:
> On 12 November 2017 at 01:37, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >
> > Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> > instruct the PM core and middle-layer (bus type, PM domain, etc.)
> > code that it is desirable to leave the device in runtime suspend
> > after system-wide transitions to the working state (for example,
> > the device may be slow to resume and it may be better to avoid
> > resuming it right away).
> >
> > Generally, the middle-layer code involved in the handling of the
> > device is expected to indicate to the PM core whether or not the
> > device may be left in suspend with the help of the device's
> > power.may_skip_resume status bit.  That has to happen in the "noirq"
> > phase of the preceding system suspend (or analogous) transition.
> > The middle layer is then responsible for handling the device as
> > appropriate in its "noirq" resume callback which is executed
> > regardless of whether or not the device may be left suspended, but
> > the other resume callbacks (except for ->complete) will be skipped
> > automatically by the core if the device really can be left in
> > suspend.
> >
> > The additional power.must_resume status bit introduced for the
> > implementation of this mechanisn is used internally by the PM core
> > to track the requirement to resume the device (which may depend on
> > its children etc).
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > ---
> >
> > v2 -> v3: Take dev->power.usage_count when updating power.must_resume in
> >   __device_suspend_noirq().
> >
> > ---
> >  Documentation/driver-api/pm/devices.rst |   24 ++-
> >  drivers/base/power/main.c   |   66 
> > +---
> >  drivers/base/power/runtime.c|9 ++--
> >  include/linux/pm.h  |   14 +-
> >  include/linux/pm_runtime.h  |9 ++--
> >  5 files changed, 104 insertions(+), 18 deletions(-)
> >
> > Index: linux-pm/include/linux/pm.h
> > ===
> > --- linux-pm.orig/include/linux/pm.h
> > +++ linux-pm/include/linux/pm.h
> > @@ -559,6 +559,7 @@ struct pm_subsys_data {
> >   * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
> >   * SMART_PREPARE: Check the return value of the driver's ->prepare 
> > callback.
> >   * SMART_SUSPEND: No need to resume the device from runtime suspend.
> > + * LEAVE_SUSPENDED: Avoid resuming the device during system resume if 
> > possible.
> >   *
> >   * Setting SMART_PREPARE instructs bus types and PM domains which may want
> >   * system suspend/resume callbacks to be skipped for the device to return 
> > 0 from
> > @@ -572,10 +573,14 @@ struct pm_subsys_data {
> >   * necessary from the driver's perspective.  It also may cause them to skip
> >   * invocations of the ->suspend_late and ->suspend_noirq callbacks 
> > provided by
> >   * the driver if they decide to leave the device in runtime suspend.
> > + *
> > + * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that 
> > the
> > + * driver prefers the device to be left in runtime suspend after system 
> > resume.
> >   */
> 
> Question: Can LEAVE_SUSPENDED and NEVER_SKIP be valid combination? I
> guess not!? Should we validate for wrong combinations?

Why not?  There's no real overlap between them.

> 
> [...]
> 
> >  /**
> >   * __device_suspend_noirq - Execute a "noirq suspend" callback for given 
> > device.
> >   * @dev: Device to handle.
> > @@ -1127,10 +1161,28 @@ static int __device_suspend_noirq(struct
> > }
> >
> > error = dpm_run_callback(callback, dev, state, info);
> > -   if (!error)
> > -   dev->power.is_noirq_suspended = true;
> > -   else
> > +   if (error) {
> > async_error = error;
> > +   goto Complete;
> > +   }
> > +
> > +   dev->power.is_noirq_suspended = true;
> > +
> > +   if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
> > +   /*
> > +* The only safe strategy here is to require that if the 
&

Re: [PATCH v3 4/6] PM / core: Add helpers for subsystem callback selection

[Rafael J. Wysocki]

On Wed, Nov 15, 2017 at 8:43 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 12 November 2017 at 01:42, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Add helper routines to find and return a suitable subsystem callback
>> during the "noirq" phases of system suspend/resume (or analogous)
>> transitions as well as during the "late" phase of system suspend and
>> the "early" phase of system resume (or analogous) transitions.
>>
>> The helpers will be called from additional sites going forward.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>
> With a minor nitpick, see below, feel free to add:
>
> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
>
>> ---
>>
>> v2 -> v3: No changes.
>>
>> ---
>>  drivers/base/power/main.c |  196 
>> +++---
>>  1 file changed, 136 insertions(+), 60 deletions(-)
>>
>> Index: linux-pm/drivers/base/power/main.c
>> ===
>> --- linux-pm.orig/drivers/base/power/main.c
>> +++ linux-pm/drivers/base/power/main.c
>> @@ -525,6 +525,14 @@ static void dpm_watchdog_clear(struct dp
>>  #define dpm_watchdog_clear(x)
>>  #endif
>>
>> +static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev,
>> +pm_message_t state,
>> +const char **info_p);
>> +
>> +static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
>> +   pm_message_t state,
>> +   const char **info_p);
>> +
>
> There is no need to declare these functions.
>
> Perhaps a following patch in the series need them, but then that
> change should add these or even better (in my opinion) just move the
> implementations and avoid the declarations all together.

Well, all of the changes in this patch are for the benefit of the
subsequent patches. :-)

I just wanted to move additional code churn noise from those patches.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Tuesday, November 14, 2017 5:07:59 PM CET Ulf Hansson wrote:
> On 11 November 2017 at 00:45, Rafael J. Wysocki <raf...@kernel.org> wrote:
> > On Fri, Nov 10, 2017 at 10:09 AM, Ulf Hansson <ulf.hans...@linaro.org> 
> > wrote:
> >> On 8 November 2017 at 14:25, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> >>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >>>
> >>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
> >>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
> >>> code that it is desirable to leave the device in runtime suspend
> >>> after system-wide transitions to the working state (for example,
> >>> the device may be slow to resume and it may be better to avoid
> >>> resuming it right away).
> >>>
> >>> Generally, the middle-layer code involved in the handling of the
> >>> device is expected to indicate to the PM core whether or not the
> >>> device may be left in suspend with the help of the device's
> >>> power.may_skip_resume status bit.  That has to happen in the "noirq"
> >>> phase of the preceding system suspend (or analogous) transition.
> >>> The middle layer is then responsible for handling the device as
> >>> appropriate in its "noirq" resume callback which is executed
> >>> regardless of whether or not the device may be left suspended, but
> >>> the other resume callbacks (except for ->complete) will be skipped
> >>> automatically by the core if the device really can be left in
> >>> suspend.
> >>
> >> I don't understand the reason to why you need to skip invoking resume
> >> callbacks to achieve this behavior, could you elaborate on that?
> >
> > The reason why it is done this way is because that takes less code and
> > is easier (or at least less error-prone, because it avoids repeating
> > patterns in middle layers).
> >
> > Note that the callbacks only may be skipped by the core if the middle
> > layer has set power.skip_resume for the device (or if the core is
> > handling it in patch [5/6], but that's one more step ahead still).
> >
> >> Couldn't the PM domain or the middle-layer instead decide what to do?
> >
> > They still can, the whole thing is a total opt-in.
> >
> > But to be constructive, do you have any specific examples in mind?
> 
> See more below.
> 
> >
> >> To me it sounds a bit prone to errors by skipping callbacks from the
> >> PM core, and I wonder if the general driver author will be able to
> >> understand how to use this flag properly.
> >
> > This has nothing to do with general driver authors and I'm not sure
> > what you mean here and where you are going with this.
> 
> Let me elaborate.
> 
> My general goal is that I want to make it easier (or as easy as
> possible) for the general driver author to deploy runtime PM and
> system-wide PM support - in an optimized manner. Therefore, I am
> pondering over the solution you picked in this series, trying to
> understand how it fits into those aspects.
> 
> Particular I am a bit worried from a complexity point of view, about
> the part with skipping callbacks from the PM core. We have observed
> some difficulties with the direct_complete path (i2c dw driver), which
> is based on a similar approach as this one.

These are resume callbacks, not suspend callbacks.  Also not all of them
are skipped.  That is quite a bit different from skipping *all* callbacks.

Moreover, at the point the core decides to skip the callbacks, the device
*has* *to* be left suspended and there simply is no point in running them
no matter what.

That part of code can be trivially moved to middle layers, but then each
of them will have to do exactly the same thing.  I don't see any reason to
do that and I'm not finding one in your comments.  Sorry.

> Additionally, in this case, to trigger skipping of callbacks to
> happen, first, drivers needs to inform the middle-layer, second, the
> middle layer acts on that information and then informs the PM core,
> then in the third step, the PM core can decide what to do. It doesn't
> sound straight-forward.

It really doesn't work like that.

First, the driver sets the LEAVE_SUSPENDED flag for the core to consume.
The middle layers don't have to look at it at all.

Second, each middle layer sets power.may_skip_resume for devices whose
state after system suspend should match the runtime suspend state.  The
middle layer must know that this is the case to set that bit.  [The core
effectively does that part for devices handled

[PATCH v3 4/6] PM / core: Add helpers for subsystem callback selection

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add helper routines to find and return a suitable subsystem callback
during the "noirq" phases of system suspend/resume (or analogous)
transitions as well as during the "late" phase of system suspend and
the "early" phase of system resume (or analogous) transitions.

The helpers will be called from additional sites going forward.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

v2 -> v3: No changes.

---
 drivers/base/power/main.c |  196 +++---
 1 file changed, 136 insertions(+), 60 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -525,6 +525,14 @@ static void dpm_watchdog_clear(struct dp
 #define dpm_watchdog_clear(x)
 #endif
 
+static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev,
+pm_message_t state,
+const char **info_p);
+
+static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p);
+
 /*- Resume routines -*/
 
 /**
@@ -539,6 +547,35 @@ bool dev_pm_may_skip_resume(struct devic
return !dev->power.must_resume && pm_transition.event != 
PM_EVENT_RESTORE;
 }
 
+static pm_callback_t dpm_subsys_resume_noirq_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "noirq power domain ";
+   callback = pm_noirq_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "noirq type ";
+   callback = pm_noirq_op(dev->type->pm, state);
+   } else if (dev->class && dev->class->pm) {
+   info = "noirq class ";
+   callback = pm_noirq_op(dev->class->pm, state);
+   } else if (dev->bus && dev->bus->pm) {
+   info = "noirq bus ";
+   callback = pm_noirq_op(dev->bus->pm, state);
+   } else {
+   return NULL;
+   }
+
+   if (info_p)
+   *info_p = info;
+
+   return callback;
+}
+
 /**
  * device_resume_noirq - Execute a "noirq resume" callback for given device.
  * @dev: Device to handle.
@@ -550,8 +587,8 @@ bool dev_pm_may_skip_resume(struct devic
  */
 static int device_resume_noirq(struct device *dev, pm_message_t state, bool 
async)
 {
-   pm_callback_t callback = NULL;
-   const char *info = NULL;
+   pm_callback_t callback;
+   const char *info;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -565,19 +602,7 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
-   if (dev->pm_domain) {
-   info = "noirq power domain ";
-   callback = pm_noirq_op(>pm_domain->ops, state);
-   } else if (dev->type && dev->type->pm) {
-   info = "noirq type ";
-   callback = pm_noirq_op(dev->type->pm, state);
-   } else if (dev->class && dev->class->pm) {
-   info = "noirq class ";
-   callback = pm_noirq_op(dev->class->pm, state);
-   } else if (dev->bus && dev->bus->pm) {
-   info = "noirq bus ";
-   callback = pm_noirq_op(dev->bus->pm, state);
-   }
+   callback = dpm_subsys_resume_noirq_cb(dev, state, );
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -686,6 +711,35 @@ void dpm_resume_noirq(pm_message_t state
dpm_noirq_end();
 }
 
+static pm_callback_t dpm_subsys_resume_early_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "early power domain ";
+   callback = pm_late_early_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "early type ";
+   callback = pm_late_early_op(dev->type->pm, state);
+   } else if (dev->class && dev->cl

[PATCH v3 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the ACPI PM domain by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from acpi_subsys_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

v2 -> v3: No changes.

---
 drivers/acpi/device_pm.c |   27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -987,7 +987,7 @@ void acpi_subsys_complete(struct device
 * the sleep state it is going out of and it has never been resumed till
 * now, resume it in case the firmware powered it up.
 */
-   if (dev->power.direct_complete && pm_resume_via_firmware())
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_complete);
@@ -1036,10 +1036,28 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_la
  */
 int acpi_subsys_suspend_noirq(struct device *dev)
 {
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   int ret;
+
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
-   return pm_generic_suspend_noirq(dev);
+   ret = pm_generic_suspend_noirq(dev);
+   if (ret)
+   return ret;
+
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* acpi_subsys_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
+   return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
 
@@ -1049,6 +1067,9 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_no
  */
 int acpi_subsys_resume_noirq(struct device *dev)
 {
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks for devices that are in runtime
suspend during the corresponding phases of system-wide suspend
(or analogous) transitions.

The underlying observation is that runtime PM is disabled for
devices during those system-wide suspend phases, so their runtime
PM status should not change going forward and if it has not changed
so far, their state should be compatible with the target system
sleep state.

This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

v2 -> v3: No changes.

---
 Documentation/driver-api/pm/devices.rst |   18 +
 drivers/base/power/main.c   |   62 
 2 files changed, 66 insertions(+), 14 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -536,6 +536,24 @@ static pm_callback_t dpm_subsys_suspend_
 /*- Resume routines -*/
 
 /**
+ * suspend_event - Return a "suspend" message for given "resume" one.
+ * @resume_msg: PM message representing a system-wide resume transition.
+ */
+static pm_message_t suspend_event(pm_message_t resume_msg)
+{
+   switch (resume_msg.event) {
+   case PM_EVENT_RESUME:
+   return PMSG_SUSPEND;
+   case PM_EVENT_THAW:
+   case PM_EVENT_RESTORE:
+   return PMSG_FREEZE;
+   case PM_EVENT_RECOVER:
+   return PMSG_HIBERNATE;
+   }
+   return PMSG_ON;
+}
+
+/**
  * dev_pm_may_skip_resume - System-wide device resume optimization check.
  * @dev: Target device.
  *
@@ -609,6 +627,25 @@ static int device_resume_noirq(struct de
if (callback)
goto Run;
 
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   pm_message_t suspend_msg = suspend_event(state);
+
+   /*
+* If "freeze" callbacks have been skipped during a transition
+* related to hibernation, the subsequent "thaw" callbacks must
+* be skipped too or bad things may happen.  Otherwise, if the
+* device is to be resumed, its runtime PM status must be
+* changed to reflect the new configuration.
+*/
+   if (!dpm_subsys_suspend_late_cb(dev, suspend_msg, NULL) &&
+   !dpm_subsys_suspend_noirq_cb(dev, suspend_msg, NULL)) {
+   if (state.event == PM_EVENT_THAW)
+   skip_resume = true;
+   else if (!skip_resume)
+   pm_runtime_set_active(dev);
+   }
+   }
+
if (skip_resume)
goto Skip;
 
@@ -1228,7 +1265,10 @@ static int __device_suspend_noirq(struct
if (callback)
goto Run;
 
-   direct_cb = true;
+   direct_cb = !dpm_subsys_suspend_late_cb(dev, state, NULL);
+
+   if (dev_pm_smart_suspend_and_suspended(dev) && direct_cb)
+   goto Skip;
 
if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -1242,6 +1282,7 @@ Run:
goto Complete;
}
 
+Skip:
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
@@ -1249,7 +1290,6 @@ Run:
bool skip_resume;
 
if (direct_cb &&
-   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
!dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
!dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL)) {
/*
@@ -1446,17 +1486,27 @@ static int __device_suspend_late(struct
goto Complete;
 
callback = dpm_subsys_suspend_late_cb(dev, state, );
+   if (callback)
+   goto Run;
 
-   if (!callback && dev->driver && dev->driver->pm) {
+   if (dev_pm_smart_suspend_and_suspended(dev) &&
+   !dpm_subsys_suspend_noirq_cb(dev, state, NULL))
+   goto Skip;
+
+   if (dev->driver && dev->driver->pm) {
info = "late driver ";
callback = pm_l

[PATCH v3 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
devices whose "noirq", "late" and "early" driver callbacks are
invoked directly by it.

Namely, make it skip all of the system-wide resume callbacks for
such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
runtime suspend during the "noirq" phase of system-wide suspend
(or analogous) transitions or the system transition under way is
a proper suspend (rather than anything related to hibernation) and
the device's wakeup settings are compatible with runtime PM (that
is, the device cannot generate wakeup signals at all or it is
allowed to wake up the system from sleep).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

v2 -> v3: Rebase on the v3 of patch [1/6].

---
 Documentation/driver-api/pm/devices.rst |9 ++
 drivers/base/power/main.c   |   47 
 2 files changed, 51 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -589,6 +589,7 @@ static int device_resume_noirq(struct de
 {
pm_callback_t callback;
const char *info;
+   bool skip_resume;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -602,23 +603,33 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
+   skip_resume = dev_pm_may_skip_resume(dev);
+
callback = dpm_subsys_resume_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
+
+   if (skip_resume)
+   goto Skip;
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
+
+Skip:
dev->power.is_noirq_suspended = false;
 
-   if (dev_pm_may_skip_resume(dev)) {
+   if (skip_resume) {
pm_runtime_set_suspended(dev);
dev->power.is_late_suspended = false;
dev->power.is_suspended = false;
}
 
- Out:
+Out:
complete_all(>power.completion);
TRACE_RESUME(error);
return error;
@@ -1194,6 +1205,7 @@ static int __device_suspend_noirq(struct
 {
pm_callback_t callback;
const char *info;
+   bool direct_cb = false;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -1213,12 +1225,17 @@ static int __device_suspend_noirq(struct
goto Complete;
 
callback = dpm_subsys_suspend_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
 
-   if (!callback && dev->driver && dev->driver->pm) {
+   direct_cb = true;
+
+   if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
if (error) {
async_error = error;
@@ -1228,13 +1245,33 @@ static int __device_suspend_noirq(struct
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
+   pm_message_t resume_msg = resume_event(state);
+   bool skip_resume;
+
+   if (direct_cb &&
+   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
+   !dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
+   !dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL)) {
+   /*
+* If all of the device driver's "noirq", "late" and
+* "early" callbacks are invoked directly by the core,
+* the decision to allow the device to stay in suspend
+* can be based on its current runtime PM status and its
+* wakeup settings.
+*/
+   skip_resume = pm_runtime_status_suspended(dev) ||
+   (resume_msg.event == PM_EVENT_RESUME &&
+(!device_can_wakeup(dev) ||
+ device_may_wakeup(dev)));
+   } else {
+   skip_resume = dev->power.may_skip_resume;
+   }
/*
 * The only safe strategy here is to require that if the device
 * may not be left in suspend, resume callbacks must be invoked
 * for it.
 */
-   dev->power.must_resume = dev->power.

[PATCH v3 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
instruct the PM core and middle-layer (bus type, PM domain, etc.)
code that it is desirable to leave the device in runtime suspend
after system-wide transitions to the working state (for example,
the device may be slow to resume and it may be better to avoid
resuming it right away).

Generally, the middle-layer code involved in the handling of the
device is expected to indicate to the PM core whether or not the
device may be left in suspend with the help of the device's
power.may_skip_resume status bit.  That has to happen in the "noirq"
phase of the preceding system suspend (or analogous) transition.
The middle layer is then responsible for handling the device as
appropriate in its "noirq" resume callback which is executed
regardless of whether or not the device may be left suspended, but
the other resume callbacks (except for ->complete) will be skipped
automatically by the core if the device really can be left in
suspend.

The additional power.must_resume status bit introduced for the
implementation of this mechanisn is used internally by the PM core
to track the requirement to resume the device (which may depend on
its children etc).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

v2 -> v3: Take dev->power.usage_count when updating power.must_resume in
  __device_suspend_noirq().

---
 Documentation/driver-api/pm/devices.rst |   24 ++-
 drivers/base/power/main.c   |   66 +---
 drivers/base/power/runtime.c|9 ++--
 include/linux/pm.h  |   14 +-
 include/linux/pm_runtime.h  |9 ++--
 5 files changed, 104 insertions(+), 18 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -559,6 +559,7 @@ struct pm_subsys_data {
  * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
+ * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -572,10 +573,14 @@ struct pm_subsys_data {
  * necessary from the driver's perspective.  It also may cause them to skip
  * invocations of the ->suspend_late and ->suspend_noirq callbacks provided by
  * the driver if they decide to leave the device in runtime suspend.
+ *
+ * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that the
+ * driver prefers the device to be left in runtime suspend after system resume.
  */
-#define DPM_FLAG_NEVER_SKIPBIT(0)
-#define DPM_FLAG_SMART_PREPARE BIT(1)
-#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
 
 struct dev_pm_info {
pm_message_tpower_state;
@@ -597,6 +602,8 @@ struct dev_pm_info {
boolwakeup_path:1;
boolsyscore:1;
boolno_pm_callbacks:1;  /* Owned by the PM core 
*/
+   unsigned intmust_resume:1;  /* Owned by the PM core */
+   unsigned intmay_skip_resume:1;  /* Set by subsystems */
 #else
unsigned intshould_wakeup:1;
 #endif
@@ -765,6 +772,7 @@ extern int pm_generic_poweroff_late(stru
 extern int pm_generic_poweroff(struct device *dev);
 extern void pm_generic_complete(struct device *dev);
 
+extern bool dev_pm_may_skip_resume(struct device *dev);
 extern bool dev_pm_smart_suspend_and_suspended(struct device *dev);
 
 #else /* !CONFIG_PM_SLEEP */
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -528,6 +528,18 @@ static void dpm_watchdog_clear(struct dp
 /*- Resume routines -*/
 
 /**
+ * dev_pm_may_skip_resume - System-wide device resume optimization check.
+ * @dev: Target device.
+ *
+ * Checks whether or not the device may be left in suspend after a system-wide
+ * transition to the working state.
+ */
+bool dev_pm_may_skip_resume(struct device *dev)
+{
+   return !dev->power.must_resume && pm_transition.event != 
PM_EVENT_RESTORE;
+}
+
+/**
  * device_resume_noirq - Execute a "noirq resume" callback for given devi

[PATCH v3 2/6] PCI / PM: Support for LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the PCI bus type by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from pci_pm_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
---

v2 -> v3: Add the Acked-by from Bjorn, no changes in the patch.

---
 Documentation/power/pci.txt |   11 +++
 drivers/pci/pci-driver.c|   19 +--
 2 files changed, 28 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -699,7 +699,7 @@ static void pci_pm_complete(struct devic
pm_generic_complete(dev);
 
/* Resume device if platform firmware has put it in reset-power-on */
-   if (dev->power.direct_complete && pm_resume_via_firmware()) {
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware()) {
pci_power_t pre_sleep_state = pci_dev->current_state;
 
pci_update_current_state(pci_dev, pci_dev->current_state);
@@ -783,8 +783,10 @@ static int pci_pm_suspend_noirq(struct d
struct pci_dev *pci_dev = to_pci_dev(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
 
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_suspend_late(dev, PMSG_SUSPEND);
@@ -838,6 +840,16 @@ static int pci_pm_suspend_noirq(struct d
 Fixup:
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
 
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* pci_pm_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
return 0;
 }
 
@@ -847,6 +859,9 @@ static int pci_pm_resume_noirq(struct de
struct device_driver *drv = dev->driver;
int error = 0;
 
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"
Index: linux-pm/Documentation/power/pci.txt
===
--- linux-pm.orig/Documentation/power/pci.txt
+++ linux-pm/Documentation/power/pci.txt
@@ -994,6 +994,17 @@ into D0 going forward), but if it is in
 the function will set the power.direct_complete flag for it (to make the PM 
core
 skip the subsequent "thaw" callbacks for it) and return.
 
+Setting the DPM_FLAG_LEAVE_SUSPENDED flag means that the driver prefers the
+device to be left in suspend after system-wide transitions to the working 
state.
+This flag is checked by the PM core, but the PCI bus type informs the PM core
+which devices may be left in suspend from its perspective (that happens during
+the "noirq" phase of system-wide suspend and analogous transitions) and next it
+uses the dev_pm_may_skip_resume() helper to decide whether or not to return 
from
+pci_pm_resume_noirq() early, as the PM core will skip the remaining resume
+callbacks for the device during the transition under way and will set its
+runtime PM status to "suspended" if dev_pm_may_skip_resume() returns "true" for
+it.
+
 3.2. Device Runtime Power Management
 
 In addition to providing device power management callbacks PCI device drivers

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/6] PM / sleep: Driver flags for system suspend/resume (part 2)

[Rafael J. Wysocki]

Hi All,

The following still applies:

On Wednesday, November 8, 2017 1:41:35 AM CET Rafael J. Wysocki wrote:
>
> This is a follow-up for the first part of the PM driver flags series
> sent previously some time ago with an intro as follows:
> 
> On Saturday, October 28, 2017 12:11:55 AM CET Rafael J. Wysocki wrote:
> > The following part of the original cover letter still applies:
> > 
> > On Monday, October 16, 2017 3:12:35 AM CEST Rafael J. Wysocki wrote:
> > > 
> > > This work was triggered by attempts to fix and optimize PM in the
> > > i2c-designware-platdev driver that ended up with adding a couple of
> > > flags to the driver's internal data structures for the tracking of
> > > device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> > > That approach is sort of suboptimal, though, because other drivers will
> > > probably want to do similar things and if all of them need to use internal
> > > flags for that, quite a bit of code duplication may ensue at least.
> > > 
> > > That can be avoided in a couple of ways and one of them is to provide a 
> > > means
> > > for drivers to tell the core what to do and to make the core take care of 
> > > it
> > > if told to do so.  Hence, the idea to use driver flags for system-wide PM
> > > that was briefly discussed during the LPC in LA last month.
> > 
> > [...]
> > 
> > > What can work (and this is the only strategy that can work AFAICS) is to
> > > point different callback pointers *in* *a* *driver* to the same routine
> > > if the driver wants to reuse that code.  That actually will work for PCI
> > > and USB drivers today, at least most of the time, but unfortunately there
> > > are problems with it for, say, platform devices.
> > > 
> > > The first problem is the requirement to track the status of the device
> > > (suspended vs not suspended) in the callbacks, because the system-wide PM
> > > code in the PM core doesn't do that.  The runtime PM framework does it, so
> > > this means adding some extra code which isn't necessary for runtime PM to
> > > the callback routines and that is not particularly nice.
> > > 
> > > The second problem is that, if the driver wants to do anything in its
> > > ->suspend callback, it generally has to prevent runtime suspend of the
> > > device from taking place in parallel with that, which is quite cumbersome.
> > > Usually, that is taken care of by resuming the device from runtime suspend
> > > upfront, but generally doing that is wasteful (there may be no real need 
> > > to
> > > resume the device except for the fact that the code is designed this way).
> > > 
> > > On top of the above, there are optimizations to be made, like leaving 
> > > certain
> > > devices in suspend after system resume to avoid wasting time on waiting 
> > > for
> > > them to resume before user space can run again and similar.
> > > 
> > > This patch series focuses on addressing those problems so as to make it
> > > easier to reuse callback routines by pointing different callback pointers
> > > to them in device drivers.  The flags introduced here are to instruct the
> > > PM core and middle layers (whatever they are) on how the driver wants the
> > > device to be handled and then the driver has to provide callbacks to match
> > > these instructions and the rest should be taken care of by the code above 
> > > it.
> > > 
> > > The flags are introduced one by one to avoid making too many changes in
> > > one go and to allow things to be explained better (hopefully).  They 
> > > mostly
> > > are mutually independent with some clearly documented exceptions.
> > 
> > but I had to rework the core patches to address the problem pointed with the
> > generic power domains (genpd) framework pointed out by Ulf.
> > 
> > Namely, genpd expects its "noirq" callbacks to be invoked for devices in
> > runtime suspend too and it has valid reasons for that, so its "noirq"
> > callbacks can never be skipped, even for devices with the SMART_SUSPEND
> > flag set.  For this reason, the logic related to DPM_FLAG_SMART_SUSPEND
> > had to be moved from the core to the PCI bus type and the ACPI PM domain
> > which are mostly affected by it anyway.  The code after the changes looks
> > more straightforward to me, but it generally is more code and some patterns
> > had to be repeated in a few places.
> 
> I promised to send the rest of

Re: [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Sat, Nov 11, 2017 at 12:45 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Fri, Nov 10, 2017 at 10:09 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
>> On 8 November 2017 at 14:25, Rafael J. Wysocki <r...@rjwysocki.net> wrote:

[cut]

>> Moreover, you should check the return value from
>> pm_runtime_set_suspended().
>
> This is in "noirq", so failures of that are meaningless here.

They *should* be meaningless, but __pm_runtime_set_status() is sort of
buggy and checks child_count regardless of whether or not runtime PM
is enabled for the children (but when changing the status to "active"
it actually checks if runtime PM is enabled for the parent before
returning -EBUSY, so it is not event consistent internally).  Oh well.

>> Then I wonder, what should you do when it fails here?
>>
>> Perhaps a better idea is to do this in the noirq suspend phase,
>> because it allows you to bail out in case pm_runtime_set_suspended()
>> fails.
>
> This doesn't make sense, sorry.

Not for the above reason, but that would allow the bug in
__pm_runtime_set_status() to be sort of worked around by setting the
status to "suspended" for children before doing that for their
parents.

Moreover, stuff with nonzero usage_counts cannot be left in suspend regardless.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Sat, Nov 11, 2017 at 12:45 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> On Fri, Nov 10, 2017 at 10:09 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
>> On 8 November 2017 at 14:25, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>>
>>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
>>> code that it is desirable to leave the device in runtime suspend
>>> after system-wide transitions to the working state (for example,
>>> the device may be slow to resume and it may be better to avoid
>>> resuming it right away).
>>>
>>> Generally, the middle-layer code involved in the handling of the
>>> device is expected to indicate to the PM core whether or not the
>>> device may be left in suspend with the help of the device's
>>> power.may_skip_resume status bit.  That has to happen in the "noirq"
>>> phase of the preceding system suspend (or analogous) transition.
>>> The middle layer is then responsible for handling the device as
>>> appropriate in its "noirq" resume callback which is executed
>>> regardless of whether or not the device may be left suspended, but
>>> the other resume callbacks (except for ->complete) will be skipped
>>> automatically by the core if the device really can be left in
>>> suspend.
>>
>> I don't understand the reason to why you need to skip invoking resume
>> callbacks to achieve this behavior, could you elaborate on that?
>
> The reason why it is done this way is because that takes less code and
> is easier (or at least less error-prone, because it avoids repeating
> patterns in middle layers).

Actually, it also is a matter of correctness, at least to some extent.

Namely, if the parent or any supplier of the device has
power.must_resume clear in dpm_noirq_resume_devices(), then the device
should not be touched during the whole system resume transition
(because the access may very well go through the suspended parent or
supplier) and the most straightforward way to make that happen is to
avoid running the code that may touch the device.  [Arguably, if
middle layers were made responsible for handling that, they would need
to do pretty much the same thing and so there is no reason for not
doing it in the core.]

Allowing the "noirq" callback from middle layers to run in that case
is a stretch already, but since genpd needs that, well, tough nuggets.

All of that said, if there is a middle layer wanting to set
power.skip_resume and needing to do something different for the resume
callbacks, then this piece can be moved from the core to the middle
layers at any time later.  So far there's none, though.  At least not
in this patch series.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Fri, Nov 10, 2017 at 10:09 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 8 November 2017 at 14:25, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
>> instruct the PM core and middle-layer (bus type, PM domain, etc.)
>> code that it is desirable to leave the device in runtime suspend
>> after system-wide transitions to the working state (for example,
>> the device may be slow to resume and it may be better to avoid
>> resuming it right away).
>>
>> Generally, the middle-layer code involved in the handling of the
>> device is expected to indicate to the PM core whether or not the
>> device may be left in suspend with the help of the device's
>> power.may_skip_resume status bit.  That has to happen in the "noirq"
>> phase of the preceding system suspend (or analogous) transition.
>> The middle layer is then responsible for handling the device as
>> appropriate in its "noirq" resume callback which is executed
>> regardless of whether or not the device may be left suspended, but
>> the other resume callbacks (except for ->complete) will be skipped
>> automatically by the core if the device really can be left in
>> suspend.
>
> I don't understand the reason to why you need to skip invoking resume
> callbacks to achieve this behavior, could you elaborate on that?

The reason why it is done this way is because that takes less code and
is easier (or at least less error-prone, because it avoids repeating
patterns in middle layers).

Note that the callbacks only may be skipped by the core if the middle
layer has set power.skip_resume for the device (or if the core is
handling it in patch [5/6], but that's one more step ahead still).

> Couldn't the PM domain or the middle-layer instead decide what to do?

They still can, the whole thing is a total opt-in.

But to be constructive, do you have any specific examples in mind?

> To me it sounds a bit prone to errors by skipping callbacks from the
> PM core, and I wonder if the general driver author will be able to
> understand how to use this flag properly.

This has nothing to do with general driver authors and I'm not sure
what you mean here and where you are going with this.

> That said, as the series don't include any changes for drivers making
> use of the flag, could please fold in such change as it would provide
> a more complete picture?

I've already done so, see https://patchwork.kernel.org/patch/10007349/

IMHO it's not really useful to drag this stuff (which doesn't change
BTW) along with every iteration of the core patches.

>>
>> The additional power.must_resume status bit introduced for the
>> implementation of this mechanisn is used internally by the PM core
>> to track the requirement to resume the device (which may depend on
>> its children etc).
>
> Yeah, clearly the PM core needs to be involved, because of the need of
> dealing with parent/child relations, however as kind of indicate
> above, couldn't the PM core just set some flag/status bits, which
> instructs the middle-layer and PM domain on what to do? That sounds
> like an easier approach.

No, it is not easier.  And it is backwards.

>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> ---
>>  Documentation/driver-api/pm/devices.rst |   24 ++-
>>  drivers/base/power/main.c   |   65 
>> +---
>>  include/linux/pm.h  |   14 +-
>>  3 files changed, 93 insertions(+), 10 deletions(-)
>>
>> Index: linux-pm/include/linux/pm.h
>> ===
>> --- linux-pm.orig/include/linux/pm.h
>> +++ linux-pm/include/linux/pm.h
>> @@ -559,6 +559,7 @@ struct pm_subsys_data {
>>   * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
>>   * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
>>   * SMART_SUSPEND: No need to resume the device from runtime suspend.
>> + * LEAVE_SUSPENDED: Avoid resuming the device during system resume if 
>> possible.
>>   *
>>   * Setting SMART_PREPARE instructs bus types and PM domains which may want
>>   * system suspend/resume callbacks to be skipped for the device to return 0 
>> from
>> @@ -572,10 +573,14 @@ struct pm_subsys_data {
>>   * necessary from the driver's perspective.  It also may cause them to skip
>>   * invocations of the ->suspend_late and ->suspend_noirq 

Re: [PATCH v2 2/6] PCI / PM: Support for LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

On Wed, Nov 8, 2017 at 9:38 PM, Bjorn Helgaas <helg...@kernel.org> wrote:
> On Wed, Nov 08, 2017 at 02:28:18PM +0100, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Add support for DPM_FLAG_LEAVE_SUSPENDED to the PCI bus type by
>> making it (a) set the power.may_skip_resume status bit for devices
>> that, from its perspective, may be left in suspend after system
>> wakeup from sleep and (b) return early from pci_pm_resume_noirq()
>> for devices whose remaining resume callbacks during the transition
>> under way are going to be skipped by the PM core.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> Acked-by: Bjorn Helgaas <bhelg...@google.com>

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/6] ACPI / PM: Support for LEAVE_SUSPENDED driver flag in ACPI PM domain

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the ACPI PM domain by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from acpi_subsys_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 drivers/acpi/device_pm.c |   27 ---
 1 file changed, 24 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -987,7 +987,7 @@ void acpi_subsys_complete(struct device
 * the sleep state it is going out of and it has never been resumed till
 * now, resume it in case the firmware powered it up.
 */
-   if (dev->power.direct_complete && pm_resume_via_firmware())
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_complete);
@@ -1036,10 +1036,28 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_la
  */
 int acpi_subsys_suspend_noirq(struct device *dev)
 {
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   int ret;
+
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
-   return pm_generic_suspend_noirq(dev);
+   ret = pm_generic_suspend_noirq(dev);
+   if (ret)
+   return ret;
+
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* acpi_subsys_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
+   return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
 
@@ -1049,6 +1067,9 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend_no
  */
 int acpi_subsys_resume_noirq(struct device *dev)
 {
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/6] PCI / PM: Support for LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add support for DPM_FLAG_LEAVE_SUSPENDED to the PCI bus type by
making it (a) set the power.may_skip_resume status bit for devices
that, from its perspective, may be left in suspend after system
wakeup from sleep and (b) return early from pci_pm_resume_noirq()
for devices whose remaining resume callbacks during the transition
under way are going to be skipped by the PM core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 Documentation/power/pci.txt |   11 +++
 drivers/pci/pci-driver.c|   19 +--
 2 files changed, 28 insertions(+), 2 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -699,7 +699,7 @@ static void pci_pm_complete(struct devic
pm_generic_complete(dev);
 
/* Resume device if platform firmware has put it in reset-power-on */
-   if (dev->power.direct_complete && pm_resume_via_firmware()) {
+   if (pm_runtime_suspended(dev) && pm_resume_via_firmware()) {
pci_power_t pre_sleep_state = pci_dev->current_state;
 
pci_update_current_state(pci_dev, pci_dev->current_state);
@@ -783,8 +783,10 @@ static int pci_pm_suspend_noirq(struct d
struct pci_dev *pci_dev = to_pci_dev(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
 
-   if (dev_pm_smart_suspend_and_suspended(dev))
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   dev->power.may_skip_resume = true;
return 0;
+   }
 
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_suspend_late(dev, PMSG_SUSPEND);
@@ -838,6 +840,16 @@ static int pci_pm_suspend_noirq(struct d
 Fixup:
pci_fixup_device(pci_fixup_suspend_late, pci_dev);
 
+   /*
+* If the target system sleep state is suspend-to-idle, it is sufficient
+* to check whether or not the device's wakeup settings are good for
+* runtime PM.  Otherwise, the pm_resume_via_firmware() check will cause
+* pci_pm_complete() to take care of fixing up the device's state
+* anyway, if need be.
+*/
+   dev->power.may_skip_resume = device_may_wakeup(dev) ||
+   !device_can_wakeup(dev);
+
return 0;
 }
 
@@ -847,6 +859,9 @@ static int pci_pm_resume_noirq(struct de
struct device_driver *drv = dev->driver;
int error = 0;
 
+   if (dev_pm_may_skip_resume(dev))
+   return 0;
+
/*
 * Devices with DPM_FLAG_SMART_SUSPEND may be left in runtime suspend
 * during system suspend, so update their runtime PM status to "active"
Index: linux-pm/Documentation/power/pci.txt
===
--- linux-pm.orig/Documentation/power/pci.txt
+++ linux-pm/Documentation/power/pci.txt
@@ -994,6 +994,17 @@ into D0 going forward), but if it is in
 the function will set the power.direct_complete flag for it (to make the PM 
core
 skip the subsequent "thaw" callbacks for it) and return.
 
+Setting the DPM_FLAG_LEAVE_SUSPENDED flag means that the driver prefers the
+device to be left in suspend after system-wide transitions to the working 
state.
+This flag is checked by the PM core, but the PCI bus type informs the PM core
+which devices may be left in suspend from its perspective (that happens during
+the "noirq" phase of system-wide suspend and analogous transitions) and next it
+uses the dev_pm_may_skip_resume() helper to decide whether or not to return 
from
+pci_pm_resume_noirq() early, as the PM core will skip the remaining resume
+callbacks for the device during the transition under way and will set its
+runtime PM status to "suspended" if dev_pm_may_skip_resume() returns "true" for
+it.
+
 3.2. Device Runtime Power Management
 
 In addition to providing device power management callbacks PCI device drivers

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/6] PM / core: DPM_FLAG_SMART_SUSPEND optimization

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core avoid invoking the "late" and "noirq" system-wide
suspend (or analogous) callbacks for devices that are in runtime
suspend during the corresponding phases of system-wide suspend
(or analogous) transitions.

The underlying observation is that runtime PM is disabled for
devices during those system-wide suspend phases, so their runtime
PM status should not change going forward and if it has not changed
so far, their state should be compatible with the target system
sleep state.

This change really makes it possible for, say, platform device
drivers to re-use runtime PM suspend and resume callbacks by
pointing ->suspend_late and ->resume_early, respectively (and
possibly the analogous hibernation-related callback pointers too),
to them without adding any extra "is the device already suspended?"
type of checks to the callback routines, as long as they will be
invoked directly by the core.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |   18 +
 drivers/base/power/main.c   |   62 
 2 files changed, 66 insertions(+), 14 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -536,6 +536,24 @@ static pm_callback_t dpm_subsys_suspend_
 /*- Resume routines -*/
 
 /**
+ * suspend_event - Return a "suspend" message for given "resume" one.
+ * @resume_msg: PM message representing a system-wide resume transition.
+ */
+static pm_message_t suspend_event(pm_message_t resume_msg)
+{
+   switch (resume_msg.event) {
+   case PM_EVENT_RESUME:
+   return PMSG_SUSPEND;
+   case PM_EVENT_THAW:
+   case PM_EVENT_RESTORE:
+   return PMSG_FREEZE;
+   case PM_EVENT_RECOVER:
+   return PMSG_HIBERNATE;
+   }
+   return PMSG_ON;
+}
+
+/**
  * dev_pm_may_skip_resume - System-wide device resume optimization check.
  * @dev: Target device.
  *
@@ -609,6 +627,25 @@ static int device_resume_noirq(struct de
if (callback)
goto Run;
 
+   if (dev_pm_smart_suspend_and_suspended(dev)) {
+   pm_message_t suspend_msg = suspend_event(state);
+
+   /*
+* If "freeze" callbacks have been skipped during a transition
+* related to hibernation, the subsequent "thaw" callbacks must
+* be skipped too or bad things may happen.  Otherwise, if the
+* device is to be resumed, its runtime PM status must be
+* changed to reflect the new configuration.
+*/
+   if (!dpm_subsys_suspend_late_cb(dev, suspend_msg, NULL) &&
+   !dpm_subsys_suspend_noirq_cb(dev, suspend_msg, NULL)) {
+   if (state.event == PM_EVENT_THAW)
+   skip_resume = true;
+   else if (!skip_resume)
+   pm_runtime_set_active(dev);
+   }
+   }
+
if (skip_resume)
goto Skip;
 
@@ -1228,7 +1265,10 @@ static int __device_suspend_noirq(struct
if (callback)
goto Run;
 
-   direct_cb = true;
+   direct_cb = !dpm_subsys_suspend_late_cb(dev, state, NULL);
+
+   if (dev_pm_smart_suspend_and_suspended(dev) && direct_cb)
+   goto Skip;
 
if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -1242,6 +1282,7 @@ Run:
goto Complete;
}
 
+Skip:
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
@@ -1249,7 +1290,6 @@ Run:
bool skip_resume;
 
if (direct_cb &&
-   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
!dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
!dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL)) {
/*
@@ -1445,17 +1485,27 @@ static int __device_suspend_late(struct
goto Complete;
 
callback = dpm_subsys_suspend_late_cb(dev, state, );
+   if (callback)
+   goto Run;
 
-   if (!callback && dev->driver && dev->driver->pm) {
+   if (dev_pm_smart_suspend_and_suspended(dev) &&
+   !dpm_subsys_suspend_noirq_cb(dev, state, NULL))
+   goto Skip;
+
+   if (dev->driver && dev->driver->pm) {
info = "late driver ";
callback = pm_late_early_op(dev->driver->pm

[PATCH v2 5/6] PM / core: Direct handling of DPM_FLAG_LEAVE_SUSPENDED

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PM core handle DPM_FLAG_LEAVE_SUSPENDED directly for
devices whose "noirq", "late" and "early" driver callbacks are
invoked directly by it.

Namely, make it skip all of the system-wide resume callbacks for
such devices with DPM_FLAG_LEAVE_SUSPENDED set if they are in
runtime suspend during the "noirq" phase of system-wide suspend
(or analogous) transitions or the system transition under way is
a proper suspend (rather than anything related to hibernation) and
the device's wakeup settings are compatible with runtime PM (that
is, the device cannot generate wakeup signals at all or it is
allowed to wake up the system from sleep).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |9 ++
 drivers/base/power/main.c   |   47 
 2 files changed, 51 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -589,6 +589,7 @@ static int device_resume_noirq(struct de
 {
pm_callback_t callback;
const char *info;
+   bool skip_resume;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -602,23 +603,33 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
+   skip_resume = dev_pm_may_skip_resume(dev);
+
callback = dpm_subsys_resume_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
+
+   if (skip_resume)
+   goto Skip;
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
+
+Skip:
dev->power.is_noirq_suspended = false;
 
-   if (dev_pm_may_skip_resume(dev)) {
+   if (skip_resume) {
pm_runtime_set_suspended(dev);
dev->power.is_late_suspended = false;
dev->power.is_suspended = false;
}
 
- Out:
+Out:
complete_all(>power.completion);
TRACE_RESUME(error);
return error;
@@ -1194,6 +1205,7 @@ static int __device_suspend_noirq(struct
 {
pm_callback_t callback;
const char *info;
+   bool direct_cb = false;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -1213,12 +1225,17 @@ static int __device_suspend_noirq(struct
goto Complete;
 
callback = dpm_subsys_suspend_noirq_cb(dev, state, );
+   if (callback)
+   goto Run;
 
-   if (!callback && dev->driver && dev->driver->pm) {
+   direct_cb = true;
+
+   if (dev->driver && dev->driver->pm) {
info = "noirq driver ";
callback = pm_noirq_op(dev->driver->pm, state);
}
 
+Run:
error = dpm_run_callback(callback, dev, state, info);
if (error) {
async_error = error;
@@ -1228,13 +1245,33 @@ static int __device_suspend_noirq(struct
dev->power.is_noirq_suspended = true;
 
if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED)) {
+   pm_message_t resume_msg = resume_event(state);
+   bool skip_resume;
+
+   if (direct_cb &&
+   !dpm_subsys_suspend_late_cb(dev, state, NULL) &&
+   !dpm_subsys_resume_early_cb(dev, resume_msg, NULL) &&
+   !dpm_subsys_resume_noirq_cb(dev, resume_msg, NULL)) {
+   /*
+* If all of the device driver's "noirq", "late" and
+* "early" callbacks are invoked directly by the core,
+* the decision to allow the device to stay in suspend
+* can be based on its current runtime PM status and its
+* wakeup settings.
+*/
+   skip_resume = pm_runtime_status_suspended(dev) ||
+   (resume_msg.event == PM_EVENT_RESUME &&
+(!device_can_wakeup(dev) ||
+ device_may_wakeup(dev)));
+   } else {
+   skip_resume = dev->power.may_skip_resume;
+   }
/*
 * The only safe strategy here is to require that if the device
 * may not be left in suspend, resume callbacks must be invoked
 * for it.
 */
-   dev->power.must_resume = dev->power.must_resume ||
- 

[PATCH v2 1/6] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
instruct the PM core and middle-layer (bus type, PM domain, etc.)
code that it is desirable to leave the device in runtime suspend
after system-wide transitions to the working state (for example,
the device may be slow to resume and it may be better to avoid
resuming it right away).

Generally, the middle-layer code involved in the handling of the
device is expected to indicate to the PM core whether or not the
device may be left in suspend with the help of the device's
power.may_skip_resume status bit.  That has to happen in the "noirq"
phase of the preceding system suspend (or analogous) transition.
The middle layer is then responsible for handling the device as
appropriate in its "noirq" resume callback which is executed
regardless of whether or not the device may be left suspended, but
the other resume callbacks (except for ->complete) will be skipped
automatically by the core if the device really can be left in
suspend.

The additional power.must_resume status bit introduced for the
implementation of this mechanisn is used internally by the PM core
to track the requirement to resume the device (which may depend on
its children etc).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
 Documentation/driver-api/pm/devices.rst |   24 ++-
 drivers/base/power/main.c   |   65 +---
 include/linux/pm.h  |   14 +-
 3 files changed, 93 insertions(+), 10 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -559,6 +559,7 @@ struct pm_subsys_data {
  * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
+ * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -572,10 +573,14 @@ struct pm_subsys_data {
  * necessary from the driver's perspective.  It also may cause them to skip
  * invocations of the ->suspend_late and ->suspend_noirq callbacks provided by
  * the driver if they decide to leave the device in runtime suspend.
+ *
+ * Setting LEAVE_SUSPENDED informs the PM core and middle-layer code that the
+ * driver prefers the device to be left in runtime suspend after system resume.
  */
-#define DPM_FLAG_NEVER_SKIPBIT(0)
-#define DPM_FLAG_SMART_PREPARE BIT(1)
-#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
 
 struct dev_pm_info {
pm_message_tpower_state;
@@ -597,6 +602,8 @@ struct dev_pm_info {
boolwakeup_path:1;
boolsyscore:1;
boolno_pm_callbacks:1;  /* Owned by the PM core 
*/
+   unsigned intmust_resume:1;  /* Owned by the PM core */
+   unsigned intmay_skip_resume:1;  /* Set by subsystems */
 #else
unsigned intshould_wakeup:1;
 #endif
@@ -765,6 +772,7 @@ extern int pm_generic_poweroff_late(stru
 extern int pm_generic_poweroff(struct device *dev);
 extern void pm_generic_complete(struct device *dev);
 
+extern bool dev_pm_may_skip_resume(struct device *dev);
 extern bool dev_pm_smart_suspend_and_suspended(struct device *dev);
 
 #else /* !CONFIG_PM_SLEEP */
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -528,6 +528,18 @@ static void dpm_watchdog_clear(struct dp
 /*- Resume routines -*/
 
 /**
+ * dev_pm_may_skip_resume - System-wide device resume optimization check.
+ * @dev: Target device.
+ *
+ * Checks whether or not the device may be left in suspend after a system-wide
+ * transition to the working state.
+ */
+bool dev_pm_may_skip_resume(struct device *dev)
+{
+   return !dev->power.must_resume && pm_transition.event != 
PM_EVENT_RESTORE;
+}
+
+/**
  * device_resume_noirq - Execute a "noirq resume" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
@@ -575,6 +587,12 @@ static int device_resume_noirq(struct de
error = dpm_run_callback(callback, dev, state, info);
dev->

[PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 2)

[Rafael J. Wysocki]

Hi All,

This is a follow-up for the first part of the PM driver flags series
sent previously some time ago with an intro as follows:

On Saturday, October 28, 2017 12:11:55 AM CET Rafael J. Wysocki wrote:
> The following part of the original cover letter still applies:
> 
> On Monday, October 16, 2017 3:12:35 AM CEST Rafael J. Wysocki wrote:
> > 
> > This work was triggered by attempts to fix and optimize PM in the
> > i2c-designware-platdev driver that ended up with adding a couple of
> > flags to the driver's internal data structures for the tracking of
> > device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> > That approach is sort of suboptimal, though, because other drivers will
> > probably want to do similar things and if all of them need to use internal
> > flags for that, quite a bit of code duplication may ensue at least.
> > 
> > That can be avoided in a couple of ways and one of them is to provide a 
> > means
> > for drivers to tell the core what to do and to make the core take care of it
> > if told to do so.  Hence, the idea to use driver flags for system-wide PM
> > that was briefly discussed during the LPC in LA last month.
> 
> [...]
> 
> > What can work (and this is the only strategy that can work AFAICS) is to
> > point different callback pointers *in* *a* *driver* to the same routine
> > if the driver wants to reuse that code.  That actually will work for PCI
> > and USB drivers today, at least most of the time, but unfortunately there
> > are problems with it for, say, platform devices.
> > 
> > The first problem is the requirement to track the status of the device
> > (suspended vs not suspended) in the callbacks, because the system-wide PM
> > code in the PM core doesn't do that.  The runtime PM framework does it, so
> > this means adding some extra code which isn't necessary for runtime PM to
> > the callback routines and that is not particularly nice.
> > 
> > The second problem is that, if the driver wants to do anything in its
> > ->suspend callback, it generally has to prevent runtime suspend of the
> > device from taking place in parallel with that, which is quite cumbersome.
> > Usually, that is taken care of by resuming the device from runtime suspend
> > upfront, but generally doing that is wasteful (there may be no real need to
> > resume the device except for the fact that the code is designed this way).
> > 
> > On top of the above, there are optimizations to be made, like leaving 
> > certain
> > devices in suspend after system resume to avoid wasting time on waiting for
> > them to resume before user space can run again and similar.
> > 
> > This patch series focuses on addressing those problems so as to make it
> > easier to reuse callback routines by pointing different callback pointers
> > to them in device drivers.  The flags introduced here are to instruct the
> > PM core and middle layers (whatever they are) on how the driver wants the
> > device to be handled and then the driver has to provide callbacks to match
> > these instructions and the rest should be taken care of by the code above 
> > it.
> > 
> > The flags are introduced one by one to avoid making too many changes in
> > one go and to allow things to be explained better (hopefully).  They mostly
> > are mutually independent with some clearly documented exceptions.
> 
> but I had to rework the core patches to address the problem pointed with the
> generic power domains (genpd) framework pointed out by Ulf.
> 
> Namely, genpd expects its "noirq" callbacks to be invoked for devices in
> runtime suspend too and it has valid reasons for that, so its "noirq"
> callbacks can never be skipped, even for devices with the SMART_SUSPEND
> flag set.  For this reason, the logic related to DPM_FLAG_SMART_SUSPEND
> had to be moved from the core to the PCI bus type and the ACPI PM domain
> which are mostly affected by it anyway.  The code after the changes looks
> more straightforward to me, but it generally is more code and some patterns
> had to be repeated in a few places.

I promised to send the rest of the series then:

> I will send the core patches for the remaining two flags introduced by the
> original series separately and the intel-lpss and i2c-designware ones will
> be posted when the core patches have been reviewed and agreed on.

and here it goes.

It actually only adds support for one additional flag, namely for
DPM_FLAG_LEAVE_SUSPENDED, to the PM core (basic bits), PCI bus type and the
ACPI PM domain.

That part of the series (patches [1-3/6]) is rather straightforward and, as PCI
and the ACPI PM domain a

[PATCH v2 4/6] PM / core: Add helpers for subsystem callback selection

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Add helper routines to find and return a suitable subsystem callback
during the "noirq" phases of system suspend/resume (or analogous)
transitions as well as during the "late" phase of system suspend and
the "early" phase of system resume (or analogous) transitions.

The helpers will be called from additional sites going forward.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/base/power/main.c |  196 +++---
 1 file changed, 136 insertions(+), 60 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -525,6 +525,14 @@ static void dpm_watchdog_clear(struct dp
 #define dpm_watchdog_clear(x)
 #endif
 
+static pm_callback_t dpm_subsys_suspend_noirq_cb(struct device *dev,
+pm_message_t state,
+const char **info_p);
+
+static pm_callback_t dpm_subsys_suspend_late_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p);
+
 /*- Resume routines -*/
 
 /**
@@ -539,6 +547,35 @@ bool dev_pm_may_skip_resume(struct devic
return !dev->power.must_resume && pm_transition.event != 
PM_EVENT_RESTORE;
 }
 
+static pm_callback_t dpm_subsys_resume_noirq_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "noirq power domain ";
+   callback = pm_noirq_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "noirq type ";
+   callback = pm_noirq_op(dev->type->pm, state);
+   } else if (dev->class && dev->class->pm) {
+   info = "noirq class ";
+   callback = pm_noirq_op(dev->class->pm, state);
+   } else if (dev->bus && dev->bus->pm) {
+   info = "noirq bus ";
+   callback = pm_noirq_op(dev->bus->pm, state);
+   } else {
+   return NULL;
+   }
+
+   if (info_p)
+   *info_p = info;
+
+   return callback;
+}
+
 /**
  * device_resume_noirq - Execute a "noirq resume" callback for given device.
  * @dev: Device to handle.
@@ -550,8 +587,8 @@ bool dev_pm_may_skip_resume(struct devic
  */
 static int device_resume_noirq(struct device *dev, pm_message_t state, bool 
async)
 {
-   pm_callback_t callback = NULL;
-   const char *info = NULL;
+   pm_callback_t callback;
+   const char *info;
int error = 0;
 
TRACE_DEVICE(dev);
@@ -565,19 +602,7 @@ static int device_resume_noirq(struct de
 
dpm_wait_for_superior(dev, async);
 
-   if (dev->pm_domain) {
-   info = "noirq power domain ";
-   callback = pm_noirq_op(>pm_domain->ops, state);
-   } else if (dev->type && dev->type->pm) {
-   info = "noirq type ";
-   callback = pm_noirq_op(dev->type->pm, state);
-   } else if (dev->class && dev->class->pm) {
-   info = "noirq class ";
-   callback = pm_noirq_op(dev->class->pm, state);
-   } else if (dev->bus && dev->bus->pm) {
-   info = "noirq bus ";
-   callback = pm_noirq_op(dev->bus->pm, state);
-   }
+   callback = dpm_subsys_resume_noirq_cb(dev, state, );
 
if (!callback && dev->driver && dev->driver->pm) {
info = "noirq driver ";
@@ -686,6 +711,35 @@ void dpm_resume_noirq(pm_message_t state
dpm_noirq_end();
 }
 
+static pm_callback_t dpm_subsys_resume_early_cb(struct device *dev,
+   pm_message_t state,
+   const char **info_p)
+{
+   pm_callback_t callback;
+   const char *info;
+
+   if (dev->pm_domain) {
+   info = "early power domain ";
+   callback = pm_late_early_op(>pm_domain->ops, state);
+   } else if (dev->type && dev->type->pm) {
+   info = "early type ";
+   callback = pm_late_early_op(dev->type->pm, state);
+   } else if (dev->class && dev->class->pm) {
+   info = "early

Re: [PATCH v2 3/6] PM / core: Add SMART_SUSPEND driver flag

[Rafael J. Wysocki]

On Mon, Nov 6, 2017 at 9:09 AM, Ulf Hansson <ulf.hans...@linaro.org> wrote:
> On 28 October 2017 at 00:22, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Define and document a SMART_SUSPEND flag to instruct bus types and PM
>> domains that the system suspend callbacks provided by the driver can
>> cope with runtime-suspended devices, so from the driver's perspective
>> it should be safe to leave devices in runtime suspend during system
>> suspend.
>>
>> Setting that flag may also cause middle-layer code (bus types,
>> PM domains etc.) to skip invocations of the ->suspend_late and
>> ->suspend_noirq callbacks provided by the driver if the device
>> is in runtime suspend at the beginning of the "late" phase of
>> the system-wide suspend transition, in which case the driver's
>> system-wide resume callbacks may be invoked back-to-back with
>> its ->runtime_suspend callback, so the driver has to be able to
>> cope with that too.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> If not too late:
>
> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>

Not too late, thanks!

I'll be sending the next batch of this shortly. :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/12] PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND

[Rafael J. Wysocki]

On Wed, Nov 1, 2017 at 10:28 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> On Tue, 31 Oct 2017, Rafael J. Wysocki wrote:
>
>> On Tue, Oct 31, 2017 at 4:09 PM, Lee Jones <lee.jo...@linaro.org> wrote:
>> > On Mon, 16 Oct 2017, Rafael J. Wysocki wrote:
>> >
>> >> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> >>
>> >> Make the intel-lpss driver set DPM_FLAG_SMART_SUSPEND for its
>> >> devices which will allow them to stay in runtime suspend during
>> >> system suspend unless they need to be reconfigured for some reason.
>> >>
>> >> Also make it avoid resuming its child devices if they have
>> >> DPM_FLAG_SMART_SUSPEND set to allow them to remain in runtime
>> >> suspend during system suspend.
>> >>
>> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> >> ---
>> >>  drivers/mfd/intel-lpss.c |6 +-
>> >>  1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > Is this patch independent?
>>
>> It depends on the flag definition at least, but functionally it also
>> depends on the PCI support for the flag.
>
> No problem.  Which tree to you propose this goes through?

linux-pm.git if that's not a problem as the patches it depends on will
go through it too.

That said I'll resend it when the core patches it depends on are ready.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 09/12] PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND

[Rafael J. Wysocki]

On Tue, Oct 31, 2017 at 4:09 PM, Lee Jones <lee.jo...@linaro.org> wrote:
> On Mon, 16 Oct 2017, Rafael J. Wysocki wrote:
>
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Make the intel-lpss driver set DPM_FLAG_SMART_SUSPEND for its
>> devices which will allow them to stay in runtime suspend during
>> system suspend unless they need to be reconfigured for some reason.
>>
>> Also make it avoid resuming its child devices if they have
>> DPM_FLAG_SMART_SUSPEND set to allow them to remain in runtime
>> suspend during system suspend.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> ---
>>  drivers/mfd/intel-lpss.c |6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> Is this patch independent?

It depends on the flag definition at least, but functionally it also
depends on the PCI support for the flag.

> For my own reference:
>   Acked-for-MFD-by: Lee Jones <lee.jo...@linaro.org>

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/6] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.

The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.

To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers.  Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.

Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.

While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
---

-> v2: Do not use pm_generic_prepare() in acpi_subsys_prepare()
   as the latter has to distinguish between the lack of the
   driver's ->prepare callback and the situation in which that
   callback has returned 0 if DPM_FLAG_SMART_PREPARE is set.

---
 Documentation/driver-api/pm/devices.rst |   14 ++
 Documentation/power/pci.txt |   19 +++
 drivers/acpi/device_pm.c|   13 +
 drivers/base/dd.c   |2 ++
 drivers/base/power/main.c   |4 +++-
 drivers/pci/pci-driver.c|5 -
 include/linux/device.h  |   10 ++
 include/linux/pm.h  |   20 
 8 files changed, 81 insertions(+), 6 deletions(-)

Index: linux-pm/include/linux/device.h
===
--- linux-pm.orig/include/linux/device.h
+++ linux-pm/include/linux/device.h
@@ -1070,6 +1070,16 @@ static inline void dev_pm_syscore_device
 #endif
 }
 
+static inline void dev_pm_set_driver_flags(struct device *dev, u32 flags)
+{
+   dev->power.driver_flags = flags;
+}
+
+static inline bool dev_pm_test_driver_flags(struct device *dev, u32 flags)
+{
+   return !!(dev->power.driver_flags & flags);
+}
+
 static inline void device_lock(struct device *dev)
 {
mutex_lock(>mutex);
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -550,6 +550,25 @@ struct pm_subsys_data {
 #endif
 };
 
+/*
+ * Driver flags to control system suspend/resume behavior.
+ *
+ * These flags can be set by device drivers at the probe time.  They need not 
be
+ * cleared by the drivers as the driver core will take care of that.
+ *
+ * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
+ * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
+ *
+ * Setting SMART_PREPARE instructs bus types and PM domains which may want
+ * system suspend/resume callbacks to be skipped for the device to return 0 
from
+ * their ->prepare callbacks if the driver's ->prepare callback returns 0 (in
+ * other words, the system suspend/resume callbacks can only be skipped for the
+ * device if its driver doesn't object against that).  This flag has no effect
+ * if NEVER_SKIP is set.
+ */
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+
 struct dev_pm_info {
pm_message_tpower_state;
unsigned intcan_wakeup:1;
@@ -561,6 +580,7 @@ struct dev_pm_info {
boolis_late_suspended:1;
boolearly_init:1;   /* Owned by the PM core */
booldirect_complete:1;  /* Owned

[PATCH v2 3/6] PM / core: Add SMART_SUSPEND driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a SMART_SUSPEND flag to instruct bus types and PM
domains that the system suspend callbacks provided by the driver can
cope with runtime-suspended devices, so from the driver's perspective
it should be safe to leave devices in runtime suspend during system
suspend.

Setting that flag may also cause middle-layer code (bus types,
PM domains etc.) to skip invocations of the ->suspend_late and
->suspend_noirq callbacks provided by the driver if the device
is in runtime suspend at the beginning of the "late" phase of
the system-wide suspend transition, in which case the driver's
system-wide resume callbacks may be invoked back-to-back with
its ->runtime_suspend callback, so the driver has to be able to
cope with that too.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

-> v2: Drop the changes in main.c, as the logic implemented by them
   previously is now going to be implemented in the PCI bus type
   and the ACPI PM domain directly.

---
 Documentation/driver-api/pm/devices.rst |   20 
 drivers/base/power/main.c   |3 +++
 include/linux/pm.h  |8 
 3 files changed, 31 insertions(+)

Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -766,6 +766,26 @@ the state of devices (possibly except fo
 from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
 invoking device drivers' ``->suspend`` callbacks (or equivalent).
 
+Some bus types and PM domains have a policy to resume all devices from runtime
+suspend upfront in their ``->suspend`` callbacks, but that may not be really
+necessary if the driver of the device can cope with runtime-suspended devices.
+The driver can indicate that by setting ``DPM_FLAG_SMART_SUSPEND`` in
+:c:member:`power.driver_flags` at the probe time, by passing it to the
+:c:func:`dev_pm_set_driver_flags` helper.  That also may cause middle-layer 
code
+(bus types, PM domains etc.) to skip the ``->suspend_late`` and
+``->suspend_noirq`` callbacks provided by the driver if the device remains in
+runtime suspend at the beginning of the ``suspend_late`` phase of system-wide
+suspend (or in the ``poweroff_late`` phase of hibernation), when runtime PM
+has been disabled for it, under the assumption that its state should not change
+after that point until the system-wide transition is over.  If that happens, 
the
+driver's system-wide resume callbacks, if present, may still be invoked during
+the subsequent system-wide resume transition and the device's runtime power
+management status may be set to "active" before enabling runtime PM for it,
+so the driver must be prepared to cope with the invocation of its system-wide
+resume callbacks back-to-back with its ``->runtime_suspend`` one (without the
+intervening ``->runtime_resume`` and so on) and the final state of the device
+must reflect the "active" status for runtime PM in that case.
+
 During system-wide resume from a sleep state it's easiest to put devices into
 the full-power state, as explained in 
:file:`Documentation/power/runtime_pm.txt`.
 Refer to that document for more information regarding this particular issue as
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -1652,6 +1652,9 @@ static int device_prepare(struct device
if (dev->power.syscore)
return 0;
 
+   WARN_ON(dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&
+   !pm_runtime_enabled(dev));
+
/*
 * If a device's parent goes into runtime suspend at the wrong time,
 * it won't be possible to resume the device.  To prevent this we
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -558,6 +558,7 @@ struct pm_subsys_data {
  *
  * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
+ * SMART_SUSPEND: No need to resume the device from runtime suspend.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -565,9 +566,16 @@ struct pm_subsys_data {
  * other words, the system suspend/resume callbacks can only be skipped for the
  * device if its driver doesn't object against that).  This flag has no effect
  * if 

[PATCH v2 4/6] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

The only user of non-empty pcibios_pm_ops is s390 and it only uses
"noirq" callbacks, so drop the invocations of the other pcibios_pm_ops
callbacks from the PCI PM code.

That will allow subsequent changes to be somewhat simpler.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Acked-by: Bjorn Helgaas <bhelg...@google.com>
Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org>
---

-> v2: No changes.

---
 drivers/pci/pci-driver.c |   18 --
 1 file changed, 18 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -922,9 +922,6 @@ static int pci_pm_freeze(struct device *
return error;
}
 
-   if (pcibios_pm_ops.freeze)
-   return pcibios_pm_ops.freeze(dev);
-
return 0;
 }
 
@@ -986,12 +983,6 @@ static int pci_pm_thaw(struct device *de
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int error = 0;
 
-   if (pcibios_pm_ops.thaw) {
-   error = pcibios_pm_ops.thaw(dev);
-   if (error)
-   return error;
-   }
-
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume(dev);
 
@@ -1036,9 +1027,6 @@ static int pci_pm_poweroff(struct device
  Fixup:
pci_fixup_device(pci_fixup_suspend, pci_dev);
 
-   if (pcibios_pm_ops.poweroff)
-   return pcibios_pm_ops.poweroff(dev);
-
return 0;
 }
 
@@ -,12 +1099,6 @@ static int pci_pm_restore(struct device
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int error = 0;
 
-   if (pcibios_pm_ops.restore) {
-   error = pcibios_pm_ops.restore(dev);
-   if (error)
-   return error;
-   }
-
/*
 * This is necessary for the hibernation error path in which restore is
 * called without restoring the standard config registers of the device.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/6] PM / sleep: Driver flags for system suspend/resume (part 1)

[Rafael J. Wysocki]

Hi All,

The following part of the original cover letter still applies:

On Monday, October 16, 2017 3:12:35 AM CEST Rafael J. Wysocki wrote:
> 
> This work was triggered by attempts to fix and optimize PM in the
> i2c-designware-platdev driver that ended up with adding a couple of
> flags to the driver's internal data structures for the tracking of
> device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> That approach is sort of suboptimal, though, because other drivers will
> probably want to do similar things and if all of them need to use internal
> flags for that, quite a bit of code duplication may ensue at least.
> 
> That can be avoided in a couple of ways and one of them is to provide a means
> for drivers to tell the core what to do and to make the core take care of it
> if told to do so.  Hence, the idea to use driver flags for system-wide PM
> that was briefly discussed during the LPC in LA last month.

[...]

> What can work (and this is the only strategy that can work AFAICS) is to
> point different callback pointers *in* *a* *driver* to the same routine
> if the driver wants to reuse that code.  That actually will work for PCI
> and USB drivers today, at least most of the time, but unfortunately there
> are problems with it for, say, platform devices.
> 
> The first problem is the requirement to track the status of the device
> (suspended vs not suspended) in the callbacks, because the system-wide PM
> code in the PM core doesn't do that.  The runtime PM framework does it, so
> this means adding some extra code which isn't necessary for runtime PM to
> the callback routines and that is not particularly nice.
> 
> The second problem is that, if the driver wants to do anything in its
> ->suspend callback, it generally has to prevent runtime suspend of the
> device from taking place in parallel with that, which is quite cumbersome.
> Usually, that is taken care of by resuming the device from runtime suspend
> upfront, but generally doing that is wasteful (there may be no real need to
> resume the device except for the fact that the code is designed this way).
> 
> On top of the above, there are optimizations to be made, like leaving certain
> devices in suspend after system resume to avoid wasting time on waiting for
> them to resume before user space can run again and similar.
> 
> This patch series focuses on addressing those problems so as to make it
> easier to reuse callback routines by pointing different callback pointers
> to them in device drivers.  The flags introduced here are to instruct the
> PM core and middle layers (whatever they are) on how the driver wants the
> device to be handled and then the driver has to provide callbacks to match
> these instructions and the rest should be taken care of by the code above it.
> 
> The flags are introduced one by one to avoid making too many changes in
> one go and to allow things to be explained better (hopefully).  They mostly
> are mutually independent with some clearly documented exceptions.

but I had to rework the core patches to address the problem pointed with the
generic power domains (genpd) framework pointed out by Ulf.

Namely, genpd expects its "noirq" callbacks to be invoked for devices in
runtime suspend too and it has valid reasons for that, so its "noirq"
callbacks can never be skipped, even for devices with the SMART_SUSPEND
flag set.  For this reason, the logic related to DPM_FLAG_SMART_SUSPEND
had to be moved from the core to the PCI bus type and the ACPI PM domain
which are mostly affected by it anyway.  The code after the changes looks
more straightforward to me, but it generally is more code and some patterns
had to be repeated in a few places.

I also fixed a minor issue in the ACPI PM domain part of the first patch which
interpreted the lack of a driver ->prepare callback as an indication that the
driver refuses to participate in the direct-complete optimization if
DPM_FLAG_SMART_PREPARE is set for the given device (the flag should be ignored
in that case, but arguably setting it and failing to provide a ->prepare
callback would be sort of inconsistent anyway).

This series includes the core, PCI and ACPI PM domain part of the patches
introducing the NEVER_SKIP, SMART_PREPARE and SMART_SUSPEND flags plus one
extra PCI patch that hasn't changed from the previous iteration.  It is
based on the linux-next branch of the linux-pm.git tree that should be
included in linux-next.

I will send the core patches for the remaining two flags introduced by the
original series separately and the intel-lpss and i2c-designware ones will
be posted when the core patches have been reviewed and agreed on.

I have retained the Greg's ACKs on everything (as discussed with Greg offline)
and the Bjorn's ACKs on the majority of PCI changes (as they are e

[PATCH v2 6/6] ACPI / PM: Take SMART_SUSPEND driver flag into account

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.

[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]

Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add
checks for that in acpi_subsys_suspend_late/noirq() and
acpi_subsys_freeze_late/noirq().

Moreover, if acpi_subsys_resume_noirq() is called during the
subsequent system-wide resume transition and if the device was left
in runtime suspend previously, its runtime PM status needs to be
changed to "active" as it is going to be put into the full-power
state going forward, so add a check for that too in there.

In turn, if acpi_subsys_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.

On top of the above, make the analogous changes in the acpi_lpss
driver that uses the ACPI PM domain callbacks.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

-> v2: Implement the entire handling of DPM_FLAG_SMART_SUSPEND in the ACPI PM
   domain (instead of relying on the core to handle it).  Among other
   things this requires some more callbacks to be provided.

---
 drivers/acpi/acpi_lpss.c |   13 -
 drivers/acpi/device_pm.c |  113 +++
 include/linux/acpi.h |   10 
 3 files changed, 126 insertions(+), 10 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -936,7 +936,8 @@ static bool acpi_dev_needs_resume(struct
u32 sys_target = acpi_target_system_state();
int ret, state;
 
-   if (device_may_wakeup(dev) != !!adev->wakeup.prepare_count)
+   if (!pm_runtime_suspended(dev) || !adev ||
+   device_may_wakeup(dev) != !!adev->wakeup.prepare_count)
return true;
 
if (sys_target == ACPI_STATE_S0)
@@ -970,9 +971,6 @@ int acpi_subsys_prepare(struct device *d
return 0;
}
 
-   if (!adev || !pm_runtime_suspended(dev))
-   return 0;
-
return !acpi_dev_needs_resume(dev, adev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
@@ -998,12 +996,17 @@ EXPORT_SYMBOL_GPL(acpi_subsys_complete);
  * acpi_subsys_suspend - Run the device driver's suspend callback.
  * @dev: Device to handle.
  *
- * Follow PCI and resume devices suspended at run time before running their
- * system suspend callbacks.
+ * Follow PCI and resume devices from runtime suspend before running their
+ * system suspend callbacks, unless the driver can cope with runtime-suspended
+ * devices during system suspend and there are no ACPI-specific reasons for
+ * resuming them.
  */
 int acpi_subsys_suspend(struct device *dev)
 {
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
+   acpi_dev_needs_resume(dev, ACPI_COMPANION(dev)))
+   pm_runtime_resume(dev);
+
return pm_generic_suspend(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend);
@@ -1017,12 +1020,48 @@ EXPORT_SYMBOL_GPL(acpi_subsys_suspend);
  */
 int acpi_subsys_suspend_late(struct device *dev)
 {
-   int ret = pm_generic_suspend_late(dev);
+   int ret;
+
+   if (dev_pm_smart_suspend_and_suspended(dev))
+   return 0;
+
+   ret = pm_generic_suspend_late(dev);
return ret ? ret : acpi_dev_suspend(dev, device_may_wakeup(dev));
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend_late);
 
 /**
+ * acpi_subsys_suspend_noirq - Run the device driver's "noirq" suspend 
callback.
+ * @dev: Device to suspend.
+ */
+int acpi_subsys_suspend_noirq(struct device *dev)
+{
+   if (dev_pm_smart_suspend_and_suspended(dev))
+   return 0;
+
+   return pm_generic_suspend_noirq(dev);
+}
+EXPORT_SYMBOL_GPL(acpi_subsys_suspend_noirq);
+
+/**
+ * acpi_subsys_resume_noirq - Run the device driver's "noirq" resume callback.
+ * @dev: Device to handle.
+ */
+int acpi_subsys_resume_noirq(struct device *dev)
+{
+   /*
+* Devices with DPM_FLAG_SMART_SUSPEND may be left in

[PATCH v2 5/6] PCI / PM: Take SMART_SUSPEND driver flag into account

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its
system-wide PM callbacks and make sure that all code that should not
run in parallel with pci_pm_runtime_resume() is executed in the "late"
phases of system suspend, freeze and poweroff transitions.

[Note that the pm_runtime_suspended() check in pci_dev_keep_suspended()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]

Also use the observation that if the device is in runtime suspend
at the beginning of the "late" phase of a system-wide suspend-like
transition, its state cannot change going forward (runtime PM is
disabled for it at that time) until the transition is over and the
subsequent system-wide PM callbacks should be skipped for it (as
they generally assume the device to not be suspended), so add checks
for that in pci_pm_suspend_late/noirq(), pci_pm_freeze_late/noirq()
and pci_pm_poweroff_late/noirq().

Moreover, if pci_pm_resume_noirq() or pci_pm_restore_noirq() is
called during the subsequent system-wide resume transition and if
the device was left in runtime suspend previously, its runtime PM
status needs to be changed to "active" as it is going to be put
into the full-power state, so add checks for that too to these
functions.

In turn, if pci_pm_thaw_noirq() runs after the device has been
left in runtime suspend, the subsequent "thaw" callbacks need
to be skipped for it (as they may not work correctly with a
suspended device), so set the power.direct_complete flag for the
device then to make the PM core skip those callbacks.

In addition to the above add a core helper for checking if
DPM_FLAG_SMART_SUSPEND is set and the device runtime PM status is
"suspended" at the same time, which is done quite often in the new
code (and will be done elsewhere going forward too).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---

-> v2: Implement the entire handling of DPM_FLAG_SMART_SUSPEND in
   the PCI bus type (instead of doing that in the core).

---
 Documentation/power/pci.txt |   14 +
 drivers/base/power/main.c   |6 ++
 drivers/pci/pci-driver.c|  103 
 include/linux/pm.h  |2 
 4 files changed, 108 insertions(+), 17 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -734,18 +734,25 @@ static int pci_pm_suspend(struct device
 
if (!pm) {
pci_pm_default_suspend(pci_dev);
-   goto Fixup;
+   return 0;
}
 
/*
-* PCI devices suspended at run time need to be resumed at this point,
-* because in general it is necessary to reconfigure them for system
-* suspend.  Namely, if the device is supposed to wake up the system
-* from the sleep state, we may need to reconfigure it for this purpose.
-* In turn, if the device is not supposed to wake up the system from the
-* sleep state, we'll have to prevent it from signaling wake-up.
+* PCI devices suspended at run time may need to be resumed at this
+* point, because in general it may be necessary to reconfigure them for
+* system suspend.  Namely, if the device is expected to wake up the
+* system from the sleep state, it may have to be reconfigured for this
+* purpose, or if the device is not expected to wake up the system from
+* the sleep state, it should be prevented from signaling wakeup events
+* going forward.
+*
+* Also if the driver of the device does not indicate that its system
+* suspend callbacks can cope with runtime-suspended devices, it is
+* better to resume the device from runtime suspend here.
 */
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
+   !pci_dev_keep_suspended(pci_dev))
+   pm_runtime_resume(dev);
 
pci_dev->state_saved = false;
if (pm->suspend) {
@@ -765,17 +772,27 @@ static int pci_pm_suspend(struct device
}
}
 
- Fixup:
-   pci_fixup_device(pci_fixup_suspend, pci_dev);
-
return 0;
 }
 
+static int pci_pm_suspend_late(struct device *dev)
+{
+   if (dev_pm_smart_suspend_and_suspended(dev))
+   return 0;
+
+   pci_fixup_device(pci_fixup_suspend, to_pci_dev(dev));
+
+   return pm_generic_suspend_late(dev);
+}
+
 static int pci_pm_suspend_noirq(struct device *dev)
 {
struct pci_dev *pci_dev = to_pci_dev(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm :

Re: [PATCH 11/12] PM: i2c-designware-platdrv: Optimize power management

[Rafael J. Wysocki]

On Thursday, October 26, 2017 10:41:40 PM CEST Wolfram Sang wrote:
> On Mon, Oct 16, 2017 at 03:31:17AM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > Optimize the power management in i2c-designware-platdrv by making it
> > set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which
> > allows some code to be dropped from its PM callbacks.
> > 
> > First, setting DPM_FLAG_SMART_SUSPEND causes the intel-lpss driver
> > to avoid resuming i2c-designware-platdrv devices in its ->prepare
> > callback, so they can stay in runtime suspend after that point even
> > if the direct-complete feature is not used for them.
> > 
> > It also causes the PM core to avoid invoking "late" and "noirq"
> > suspend callbacks for these devices if they are in runtime suspend
> > at the beginning of the "late" phase of device suspend during
> > system suspend.  That guarantees dw_i2c_plat_suspend() to be
> > called for a device only if it is not in runtime suspend.
> > Moreover, it also causes the PM core to set the device's runtime
> > PM status to "active" after calling dw_i2c_plat_resume() for
> > it, so the driver doesn't need internal flags to avoid invoking
> > either dw_i2c_plat_suspend() or dw_i2c_plat_resume() twice in
> > a row.
> > 
> > Second, setting DPM_FLAG_LEAVE_SUSPENDED enables the optimization
> > allowing the device to stay suspended after system resume under
> > suitable conditions, so again the driver doesn't need to take
> > care of that by itself.
> > 
> > Accordingly, the internal "suspended" and "skip_resume" flags
> > used by the driver are not necessary any more, so drop them and
> > simplify the driver's PM callbacks.
> > 
> > Additionally, notice that dw_i2c_plat_complete() only needs
> > to schedule runtime PM for the device if platform firmware
> > has been involved in resuming the system, so make it call
> > pm_resume_via_firmware() to check that.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> So, if the designware maintainers ack it, I will, too.

Thanks!

I need to post a new revision of the core patches, so I'll send this one
again later.  Likely during the next cycle.

Thanks,
Rafael


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag

[Rafael J. Wysocki]

On Tuesday, October 24, 2017 7:22:25 AM CEST Ulf Hansson wrote:
> On 16 October 2017 at 03:29, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >
> > Define and document a SMART_SUSPEND flag to instruct bus types and PM
> > domains that the system suspend callbacks provided by the driver can
> > cope with runtime-suspended devices, so from the driver's perspective
> > it should be safe to leave devices in runtime suspend during system
> > suspend.
> >
> > Setting that flag also causes the PM core to skip the "late" and
> > "noirq" phases of device suspend for devices that remain in runtime
> > suspend at the beginning of the "late" phase (when runtime PM has
> > been disabled for them) under the assumption that their state cannot
> > (and should not) change after that point until the system suspend
> > transition is complete.  Moreover, the PM core prevents runtime PM
> > from acting on devices with DPM_FLAG_SMART_SUSPEND during system
> > resume by setting their runtime PM status to "active" at the end of
> > the "early" phase (right prior to enabling runtime PM for them).
> > That allows system resume callbacks to do whatever is necessary to
> > resume the device without worrying about runtime PM possibly
> > running in parallel with them.
> 
> After some sleep, I woke up and realized that the hole thing of making
> the PM core skip invoking system sleep callbacks, is not compatible
> with devices being attached to the genpd. Sorry.

That's OK. :-)

It just means I need to move that logic up to the concerned middle layers.

I was going to do that to start with, but then I thought I would do it in
the core to avoid duplicated checks.  I overlooked the genpd case, however.

> The reason is because genpd may not power off the PM domain, even if
> all devices attached to it are runtime suspended. For example, due to
> a subdomain holding it powered or because a PM QoS constraints
> prevents to power off it in runtime. Then to understand whether it
> shall power off/on the PM domain, during system-wide PM it requires
> the system sleep callbacks to be invoked.
> 
> So, even if the driver can cope with the behavior from
> DPM_FLAG_SMART_SUSPEND, then what happens when the PM domain (genpd)
> can not?
> 
> Taking this into account, this feels like solution entirely specific
> to ACPI and PCI. That is fine by me, however then we still have those
> cross SoC drivers, the i2c-designware driver, which may have its
> device attached to an ACPI PM domain or perhaps a genpd.

Yes, that should be fine if the logic above goes to the PCI bus type
and ACPI PM domain.  Then, setting the flag will have no effect on
genpd at all, but that's OK.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Monday, October 23, 2017 6:37:41 PM CEST Ulf Hansson wrote:
> On 19 October 2017 at 01:17, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >
> > The motivation for this change is to provide a way to work around
> > a problem with the direct-complete mechanism used for avoiding
> > system suspend/resume handling for devices in runtime suspend.
> >
> > The problem is that some middle layer code (the PCI bus type and
> > the ACPI PM domain in particular) returns positive values from its
> > system suspend ->prepare callbacks regardless of whether the driver's
> > ->prepare returns a positive value or 0, which effectively prevents
> > drivers from being able to control the direct-complete feature.
> > Some drivers need that control, however, and the PCI bus type has
> > grown its own flag to deal with this issue, but since it is not
> > limited to PCI, it is better to address it by adding driver flags at
> > the core level.
> >
> > To that end, add a driver_flags field to struct dev_pm_info for flags
> > that can be set by device drivers at the probe time to inform the PM
> > core and/or bus types, PM domains and so on on the capabilities and/or
> > preferences of device drivers.  Also add two static inline helpers
> > for setting that field and testing it against a given set of flags
> > and make the driver core clear it automatically on driver remove
> > and probe failures.
> >
> > Define and document two PM driver flags related to the direct-
> > complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> > respectively, to indicate to the PM core that the direct-complete
> > mechanism should never be used for the device and to inform the
> > middle layer code (bus types, PM domains etc) that it can only
> > request the PM core to use the direct-complete mechanism for
> > the device (by returning a positive value from its ->prepare
> > callback) if it also has been requested by the driver.
> >
> > While at it, make the core check pm_runtime_suspended() when
> > setting power.direct_complete so that it doesn't need to be
> > checked by ->prepare callbacks.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > ---
> >
> > -> v2: Change the data type for driver_flags to u32 as suggested by Greg
> >and fix a couple of documentation typos pointed out by Lukas.
> >
> > ---
> >  Documentation/driver-api/pm/devices.rst |   14 ++
> >  Documentation/power/pci.txt |   19 +++
> >  drivers/acpi/device_pm.c|3 +++
> >  drivers/base/dd.c   |2 ++
> >  drivers/base/power/main.c   |4 +++-
> >  drivers/pci/pci-driver.c|5 -
> >  include/linux/device.h  |   10 ++
> >  include/linux/pm.h  |   20 
> >  8 files changed, 75 insertions(+), 2 deletions(-)
> >
> > Index: linux-pm/include/linux/device.h
> > ===
> > --- linux-pm.orig/include/linux/device.h
> > +++ linux-pm/include/linux/device.h
> > @@ -1070,6 +1070,16 @@ static inline void dev_pm_syscore_device
> >  #endif
> >  }
> >
> > +static inline void dev_pm_set_driver_flags(struct device *dev, u32 flags)
> > +{
> > +   dev->power.driver_flags = flags;
> > +}
> > +
> > +static inline bool dev_pm_test_driver_flags(struct device *dev, u32 flags)
> > +{
> > +   return !!(dev->power.driver_flags & flags);
> > +}
> > +
> >  static inline void device_lock(struct device *dev)
> >  {
> > mutex_lock(>mutex);
> > Index: linux-pm/include/linux/pm.h
> > ===
> > --- linux-pm.orig/include/linux/pm.h
> > +++ linux-pm/include/linux/pm.h
> > @@ -550,6 +550,25 @@ struct pm_subsys_data {
> >  #endif
> >  };
> >
> > +/*
> > + * Driver flags to control system suspend/resume behavior.
> > + *
> > + * These flags can be set by device drivers at the probe time.  They need 
> > not be
> > + * cleared by the drivers as the driver core will take care of that.
> > + *
> > + * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
> > + * SMART_PREPARE: Check the return value of the driver's ->prepare 
> > callback.
> > + *
> > + * Setting SMART_PREPARE

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Friday, October 20, 2017 10:46:07 PM CEST Bjorn Helgaas wrote:
> On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote:
> > Hi All,
> > 
> > Well, this took more time than expected, as I tried to cover everything I 
> > had
> > in mind regarding PM flags for drivers.
> 
> For the parts that touch PCI,
> 
> Acked-by: Bjorn Helgaas <bhelg...@google.com>

Thank you!

> I doubt there'll be conflicts with changes in my tree, but let me know if
> you trip over any so I can watch for them when merging.

Well, if there are any conflicts, we'll see them in linux-next I guess. :-)

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Friday, October 20, 2017 1:35:27 PM CEST Greg Kroah-Hartman wrote:
> On Fri, Oct 20, 2017 at 01:11:22PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, October 19, 2017 9:33:15 AM CEST Greg Kroah-Hartman wrote:
> > > On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote:
> > > > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > > > 
> > > > The motivation for this change is to provide a way to work around
> > > > a problem with the direct-complete mechanism used for avoiding
> > > > system suspend/resume handling for devices in runtime suspend.
> > > > 
> > > > The problem is that some middle layer code (the PCI bus type and
> > > > the ACPI PM domain in particular) returns positive values from its
> > > > system suspend ->prepare callbacks regardless of whether the driver's
> > > > ->prepare returns a positive value or 0, which effectively prevents
> > > > drivers from being able to control the direct-complete feature.
> > > > Some drivers need that control, however, and the PCI bus type has
> > > > grown its own flag to deal with this issue, but since it is not
> > > > limited to PCI, it is better to address it by adding driver flags at
> > > > the core level.
> > > > 
> > > > To that end, add a driver_flags field to struct dev_pm_info for flags
> > > > that can be set by device drivers at the probe time to inform the PM
> > > > core and/or bus types, PM domains and so on on the capabilities and/or
> > > > preferences of device drivers.  Also add two static inline helpers
> > > > for setting that field and testing it against a given set of flags
> > > > and make the driver core clear it automatically on driver remove
> > > > and probe failures.
> > > > 
> > > > Define and document two PM driver flags related to the direct-
> > > > complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> > > > respectively, to indicate to the PM core that the direct-complete
> > > > mechanism should never be used for the device and to inform the
> > > > middle layer code (bus types, PM domains etc) that it can only
> > > > request the PM core to use the direct-complete mechanism for
> > > > the device (by returning a positive value from its ->prepare
> > > > callback) if it also has been requested by the driver.
> > > > 
> > > > While at it, make the core check pm_runtime_suspended() when
> > > > setting power.direct_complete so that it doesn't need to be
> > > > checked by ->prepare callbacks.
> > > > 
> > > > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > > 
> > > Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > 
> > Thanks!
> > 
> > Does it also apply to the other patches in the series?
> > 
> > I'd like to queue up the core patches for 4.15 as they are specifically
> > designed to only affect the drivers that actually set the flags, so there
> > shouldn't be any regression resulting from them, and I'd like to be
> > able to start using the flags in drivers going forward.
> 
> Yes, sorry, I thought I acked them, but you are right, I didn't:
> 
> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> 
> for all of them please.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Thursday, October 19, 2017 9:33:15 AM CEST Greg Kroah-Hartman wrote:
> On Thu, Oct 19, 2017 at 01:17:31AM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > The motivation for this change is to provide a way to work around
> > a problem with the direct-complete mechanism used for avoiding
> > system suspend/resume handling for devices in runtime suspend.
> > 
> > The problem is that some middle layer code (the PCI bus type and
> > the ACPI PM domain in particular) returns positive values from its
> > system suspend ->prepare callbacks regardless of whether the driver's
> > ->prepare returns a positive value or 0, which effectively prevents
> > drivers from being able to control the direct-complete feature.
> > Some drivers need that control, however, and the PCI bus type has
> > grown its own flag to deal with this issue, but since it is not
> > limited to PCI, it is better to address it by adding driver flags at
> > the core level.
> > 
> > To that end, add a driver_flags field to struct dev_pm_info for flags
> > that can be set by device drivers at the probe time to inform the PM
> > core and/or bus types, PM domains and so on on the capabilities and/or
> > preferences of device drivers.  Also add two static inline helpers
> > for setting that field and testing it against a given set of flags
> > and make the driver core clear it automatically on driver remove
> > and probe failures.
> > 
> > Define and document two PM driver flags related to the direct-
> > complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
> > respectively, to indicate to the PM core that the direct-complete
> > mechanism should never be used for the device and to inform the
> > middle layer code (bus types, PM domains etc) that it can only
> > request the PM core to use the direct-complete mechanism for
> > the device (by returning a positive value from its ->prepare
> > callback) if it also has been requested by the driver.
> > 
> > While at it, make the core check pm_runtime_suspended() when
> > setting power.direct_complete so that it doesn't need to be
> > checked by ->prepare callbacks.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> Acked-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

Thanks!

Does it also apply to the other patches in the series?

I'd like to queue up the core patches for 4.15 as they are specifically
designed to only affect the drivers that actually set the flags, so there
shouldn't be any regression resulting from them, and I'd like to be
able to start using the flags in drivers going forward.

Thanks,
Rafael


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Thursday, October 19, 2017 2:21:07 PM CEST Ulf Hansson wrote:
> On 19 October 2017 at 00:12, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
> >> [...]
> >>
> >> >>
> >> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
> >> >> the RPM callbacks, is because otherwise it can't safely update the
> >> >> runtime PM status of the device.
> >> >
> >> > I'm not sure I follow this requirement.  Why is that so?
> >>
> >> If the PM domain controls some resources for the device in its RPM
> >> callbacks and the driver controls some other resources in its RPM
> >> callbacks - then these resources needs to be managed together.
> >
> > Right, but that doesn't automatically make it necessary to use runtime PM
> > callbacks in the middle layer.  Its system-wide PM callbacks may be
> > suitable for that just fine.
> >
> > That is, at least in some cases, you can combine ->runtime_suspend from a
> > driver and ->suspend_late from a middle layer with no problems, for example.
> >
> > That's why some middle layers allow drivers to point ->suspend_late and
> > ->runtime_suspend to the same routine if they want to reuse that code.
> >
> >> This follows the behavior of when a regular call to
> >> pm_runtime_get|put(), triggers the RPM callbacks to be invoked.
> >
> > But (a) it doesn't have to follow it and (b) in some cases it should not
> > follow it.
> 
> Of course you don't explicitly *have to* respect the hierarchy of the
> RPM callbacks in pm_runtime_force_*.
> 
> However, changing that would require some additional information
> exchange between the driver and the middle-layer/PM domain, as to
> instruct the middle-layer/PM domain of what to do during system-wide
> PM. Especially in cases when the driver deals with wakeup, as in those
> cases the instructions may change dynamically.

Well, if wakeup matters, drivers can't simply point their PM callbacks
to pm_runtime_force_* anyway.

If the driver itself deals with wakeups, it clearly needs different callback
routines for system-wide PM and for runtime PM, so it can't reuse its runtime
PM callbacks at all then.

If the middle layer deals with wakeups, different callbacks are needed at
that level and so pm_runtime_force_* are unsuitable too.

Really, invoking runtime PM callbacks from the middle layer in
pm_runtime_force_* is a not a idea at all and there's no general requirement
for it whatever.

> [...]
> 
> >> > In general, not if the wakeup settings are adjusted by the middle layer.
> >>
> >> Correct!
> >>
> >> To use pm_runtime_force* for these cases, one would need some
> >> additional information exchange between the driver and the
> >> middle-layer.
> >
> > Which pretty much defeats the purpose of the wrappers, doesn't it?
> 
> Well, no matter if the wrappers are used or not, we need some kind of
> information exchange between the driver and the middle-layers/PM
> domains.

Right.

But if that information is exchanged, then why use wrappers *in* *addition*
to that?

> Anyway, me personally think it's too early to conclude that using the
> wrappers may not be useful going forward. At this point, they clearly
> helps trivial cases to remain being trivial.

I'm not sure about that really.  So far I've seen more complexity resulting
from using them than being avoided by using them, but I guess the beauty is
in the eye of the beholder. :-)

> >
> >> >
> >> >> Regarding hibernation, honestly that's not really my area of
> >> >> expertise. Although, I assume the middle-layer and driver can treat
> >> >> that as a separate case, so if it's not suitable to use
> >> >> pm_runtime_force* for that case, then they shouldn't do it.
> >> >
> >> > Well, agreed.
> >> >
> >> > In some simple cases, though, driver callbacks can be reused for 
> >> > hibernation
> >> > too, so it would be good to have a common way to do that too, IMO.
> >>
> >> Okay, that makes sense!
> >>
> >> >
> >> >> >
> >> >> > Also, quite so often other middle layers interact with PCI directly or
> >> >> > indirectly (eg. a platform device may be a child or a consumer of a 
> >> >> > PCI
> >> >> > device) and some optimizations need to take that into account (eg. 
> >> >> > parents
> >> >> > generally need to be acc

[PATCH] PM: docs: Fix formatting typo in devices.rst

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

There is one word too many under formatting markup in one place
in device.rst, so fix it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -274,7 +274,7 @@ sleep states and the hibernation state (
 executing callbacks for every device before the next phase begins.  Not all
 buses or classes support all these callbacks and not all drivers use all the
 callbacks.  The various phases always run after tasks have been frozen and
-before they are unfrozen.  Furthermore, the ``*_noirq phases`` run at a time
+before they are unfrozen.  Furthermore, the ``*_noirq`` phases run at a time
 when IRQ handlers have been disabled (except for those marked with the
 IRQF_NO_SUSPEND flag).
 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Update][PATCH v2 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.

The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.

To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers.  Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.

Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.

While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

-> v2: Change the data type for driver_flags to u32 as suggested by Greg
   and fix a couple of documentation typos pointed out by Lukas.

---
 Documentation/driver-api/pm/devices.rst |   14 ++
 Documentation/power/pci.txt |   19 +++
 drivers/acpi/device_pm.c|3 +++
 drivers/base/dd.c   |2 ++
 drivers/base/power/main.c   |4 +++-
 drivers/pci/pci-driver.c|5 -
 include/linux/device.h  |   10 ++
 include/linux/pm.h  |   20 
 8 files changed, 75 insertions(+), 2 deletions(-)

Index: linux-pm/include/linux/device.h
===
--- linux-pm.orig/include/linux/device.h
+++ linux-pm/include/linux/device.h
@@ -1070,6 +1070,16 @@ static inline void dev_pm_syscore_device
 #endif
 }
 
+static inline void dev_pm_set_driver_flags(struct device *dev, u32 flags)
+{
+   dev->power.driver_flags = flags;
+}
+
+static inline bool dev_pm_test_driver_flags(struct device *dev, u32 flags)
+{
+   return !!(dev->power.driver_flags & flags);
+}
+
 static inline void device_lock(struct device *dev)
 {
mutex_lock(>mutex);
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -550,6 +550,25 @@ struct pm_subsys_data {
 #endif
 };
 
+/*
+ * Driver flags to control system suspend/resume behavior.
+ *
+ * These flags can be set by device drivers at the probe time.  They need not 
be
+ * cleared by the drivers as the driver core will take care of that.
+ *
+ * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
+ * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
+ *
+ * Setting SMART_PREPARE instructs bus types and PM domains which may want
+ * system suspend/resume callbacks to be skipped for the device to return 0 
from
+ * their ->prepare callbacks if the driver's ->prepare callback returns 0 (in
+ * other words, the system suspend/resume callbacks can only be skipped for the
+ * device if its driver doesn't object against that).  This flag has no effect
+ * if NEVER_SKIP is set.
+ */
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+
 struct dev_pm_info {
pm_message_tpower_state;
unsigned intcan_wakeup:1;
@@ -561,6 +580,7 @@ struct dev_pm_info {
boolis_late_suspended:1;
boolearly_init:1;   /* Owned by the PM core */
booldirect_complete:1;  /* Owned by the PM core 
*/
+   u32 driver_flags;
spinlock_t  lock;
 #ifdef CONFIG_PM_SLEEP
struct list_headentry;
Index: linux-pm/drivers/base/dd.c
==

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Wednesday, October 18, 2017 4:11:33 PM CEST Ulf Hansson wrote:
> [...]
> 
> >>
> >> The reason why pm_runtime_force_* needs to respects the hierarchy of
> >> the RPM callbacks, is because otherwise it can't safely update the
> >> runtime PM status of the device.
> >
> > I'm not sure I follow this requirement.  Why is that so?
> 
> If the PM domain controls some resources for the device in its RPM
> callbacks and the driver controls some other resources in its RPM
> callbacks - then these resources needs to be managed together.

Right, but that doesn't automatically make it necessary to use runtime PM
callbacks in the middle layer.  Its system-wide PM callbacks may be
suitable for that just fine.

That is, at least in some cases, you can combine ->runtime_suspend from a
driver and ->suspend_late from a middle layer with no problems, for example.

That's why some middle layers allow drivers to point ->suspend_late and
->runtime_suspend to the same routine if they want to reuse that code.

> This follows the behavior of when a regular call to
> pm_runtime_get|put(), triggers the RPM callbacks to be invoked.

But (a) it doesn't have to follow it and (b) in some cases it should not
follow it.
 
> >
> >> And updating the runtime PM status of
> >> the device is required to manage the optimized behavior during system
> >> resume (avoiding to unnecessary resume devices).
> >
> > Well, OK.  The runtime PM status of the device after system resume should
> > better reflect its physical state.
> >
> > [The physical state of the device may not be under the control of the
> > kernel in some cases, like in S3 resume on some systems that reset
> > devices in the firmware and so on, but let's set that aside.]
> >
> > However, for the runtime PM status of the device may still reflect its state
> > if, say, a ->resume_early of the middle layer is called during resume along
> > with a driver's ->runtime_resume.  That still can produce the right state
> > of the device and all depends on the middle layer.
> >
> > On the other hand, as I said before, using a middle-layer ->runtime_suspend
> > during a system sleep transition may be outright incorrect, say if device
> > wakeup settings need to be adjusted by the middle layer (which is the
> > case for some of them).
> >
> > Of course, if the middle layer expects the driver to point its
> > system-wide PM callbacks to pm_runtime_force_*, then that's how it goes,
> > but the drivers working with this particular middle layer generally
> > won't work with other middle layers and may interact incorrectly
> > with parents and/or children using the other middle layers.
> >
> > I guess the problem boils down to having a common set of expectations
> > on the driver side and on the middle layer side allowing different
> > combinations of these to work together.
> 
> Yes!
> 
> >
> >> Besides the AMBA case, I also realized that we are dealing with PM
> >> clocks in the genpd case. For this, genpd relies on the that runtime
> >> PM status of the device properly reflects the state of the HW, during
> >> system-wide PM.
> >>
> >> In other words, if the driver would change the runtime PM status of
> >> the device, without respecting the hierarchy of the runtime PM
> >> callbacks, it would lead to that genpd starts taking wrong decisions
> >> while managing the PM clocks during system-wide PM. So in case you
> >> intend to change pm_runtime_force_* this needs to be addressed too.
> >
> > I've just looked at the genpd code and quite frankly I'm not sure how this
> > works, but I'll figure this out. :-)
> 
> You may think of it as genpd's RPM callback controls some device
> clocks, while the driver control some other device resources (pinctrl
> for example) from its RPM callback.
> 
> These resources needs to managed together, similar to as I described above.

Which, again, doesn't mean that runtime PM callbacks from the middle layer
have to be used for that.

> [...]
> 
> >> Absolutely agree about the different wake-up settings. However, these
> >> issues can be addressed also when using pm_runtime_force_*, at least
> >> in general, but then not for PCI.
> >
> > Well, not for the ACPI PM domain too.
> >
> > In general, not if the wakeup settings are adjusted by the middle layer.
> 
> Correct!
> 
> To use pm_runtime_force* for these cases, one would need some
> additional information exchange between the driver and the
> middle-layer.

Which pretty much defeats the purpose of the wrappers, doesn't it?

> >
> >> Regarding hibernation, honestly that's not really my area of
> >> expertise. Although, I assume the middle-layer and driver can treat
> >> that as a separate case, so if it's not suitable to use
> >> pm_runtime_force* for that case, then they shouldn't do it.
> >
> > Well, agreed.
> >
> > In some simple cases, though, driver callbacks can be reused for hibernation
> > too, so it would be good to have a common way to do that too, IMO.
> 
> Okay, that makes sense!
> 
> >
> >> >
> >> > 

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Wednesday, October 18, 2017 2:34:10 PM CEST Ulf Hansson wrote:
> [...]
> 
> >> Are there any major reasons why the appended patch (obviously untested) 
> >> won't
> >> work, then?
> >
> > OK, there is a reason, which is the optimizations bundled into
> > pm_runtime_force_*, because (a) the device may be left in runtime suspend
> > by them (in which case amba_pm_suspend_early() in my patch should not run)
> > and (b) pm_runtime_force_resume() may decide to leave it suspended (in which
> > case amba_pm_suspend_late() in my patch should not run).
> 
> Exactly.
> 
> >
> > [BTW, the "leave the device suspended" optimization in pm_runtime_force_*
> > is potentially problematic too, because it requires the children to do
> > the right thing, which effectively means that their drivers need to use
> > pm_runtime_force_* too, but what if they don't want to reuse their
> > runtime PM callbacks for system-wide PM?]
> 
> Deployment of pm_runtime_force_suspend() should generally be done for
> children devices first.
> 
> If some reason that isn't the case, it's expected that the call to
> pm_runtime_set_suspended() invoked from pm_runtime_force_suspend(),
> for the parent, should fail and thus abort system suspend.

Well, generally what about drivers that need to do something significantly
different for system suspend and runtime PM?  The whole picture seems to be
falling apart if one of these is involved.

> >
> > Honestly, I don't like the way this is designed.  IMO, it would be better
> > to do the optimizations and all in the bus type middle-layer code instead
> > of expecting drivers to use pm_runtime_force_* as their system-wide PM
> > callbacks (and that expectation should at least be documented, which I'm
> > not sure is the case now).  But whatever.
> >
> > It all should work the way it does now without pm_runtime_force_* if (a) the
> > bus type's PM callbacks are changed like in the last patch and the drivers
> > (b) point their system suspend callbacks to the runtime PM callback routines
> > and (c) set DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED for the
> > devices (if they need to do the PM in ->suspend and ->resume, they may set
> > DPM_FLAG_AVOID_RPM too).
> >
> > And if you see a reason why that won't work, please let me know.
> 
> I will have look and try out the series by using my local "runtime PM
> test driver".
> 
> I get back to you with an update on this.

OK, thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Wednesday, October 18, 2017 9:45:11 PM CEST Grygorii Strashko wrote:
> 
> On 10/18/2017 09:11 AM, Ulf Hansson wrote:

[...]

> >>> That's the point. We know pm_runtime_force_* works nicely for the
> >>> trivial middle-layer cases.
> >>
> >> In which cases the middle-layer callbacks don't exist, so it's just like
> >> reusing driver callbacks directly. :-)
> 
> I'd like to ask you clarify one point here and provide some info which I hope 
> can be useful - 
> what's exactly means  "trivial middle-layer cases"?
> 
> Is it when systems use "drivers/base/power/clock_ops.c - Generic clock
> manipulation PM callbacks" as dev_pm_domain (arm davinci/keystone), or OMAP
> device framework struct dev_pm_domain omap_device_pm_domain
> (arm/mach-omap2/omap_device.c) or static const struct dev_pm_ops
> tegra_aconnect_pm_ops?
> 
> if yes all above have PM runtime callbacks.

Trivial ones don't actually do anything meaningful in their PM callbacks.

Things like the platform bus type, spi bus type, i2c bus type and similar.

If the middle-layer callbacks manipulate devices in a significant way, then
they aren't trivial.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Wednesday, October 18, 2017 1:57:52 PM CEST Ulf Hansson wrote:
> On 18 October 2017 at 02:39, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
> >
> > [cut]
> >
> >> >
> >> >> deploying this and from a middle layer point of view, all the trivial
> >> >> cases supports this.
> >> >
> >> > These functions are wrong, however, because they attempt to reuse the
> >> > whole callback *path* instead of just reusing driver callbacks.  The
> >> > *only* reason why it all "works" is because there are no middle layer
> >> > callbacks involved in that now.
> >> >
> >> > If you changed them to reuse driver callbacks only today, nothing would 
> >> > break
> >> > AFAICS.
> >>
> >> Yes, it would.
> >>
> >> First, for example, the amba bus is responsible for the amba bus
> >> clock, but relies on drivers to gate/ungate it during system sleep. In
> >> case the amba drivers don't use the pm_runtime_force_suspend|resume(),
> >> it will explicitly have to start manage the clock during system sleep
> >> themselves. Leading to open coding.
> >
> > Well, I suspected that something like this would surface. ;-)
> >
> > Are there any major reasons why the appended patch (obviously untested) 
> > won't
> > work, then?
> 
> Let me comment on the code, instead of here...
> 
> ...just realized your second reply, so let me reply to that instead
> regarding the patch.
> 
> >
> >> Second, it will introduce a regression in behavior for all users of
> >> pm_runtime_force_suspend|resume(), especially during system resume as
> >> the driver may then end up resuming the device even in case it isn't
> >> needed.
> >
> > How so?
> >
> > I'm talking about a change like in the appended patch, where
> > pm_runtime_force_* simply invoke driver callbacks directly.  What is
> > skipped there is middle-layer stuff which is empty anyway in all cases
> > except for AMBA (if that's all what is lurking below the surface), so
> > I don't quite see how the failure will happen.
> 
> I am afraid changing pm_runtime_force* to only call driver callbacks
> may become fragile. Let me elaborate.
> 
> The reason why pm_runtime_force_* needs to respects the hierarchy of
> the RPM callbacks, is because otherwise it can't safely update the
> runtime PM status of the device.

I'm not sure I follow this requirement.  Why is that so?

> And updating the runtime PM status of
> the device is required to manage the optimized behavior during system
> resume (avoiding to unnecessary resume devices).

Well, OK.  The runtime PM status of the device after system resume should
better reflect its physical state.

[The physical state of the device may not be under the control of the
kernel in some cases, like in S3 resume on some systems that reset
devices in the firmware and so on, but let's set that aside.]

However, for the runtime PM status of the device may still reflect its state
if, say, a ->resume_early of the middle layer is called during resume along
with a driver's ->runtime_resume.  That still can produce the right state
of the device and all depends on the middle layer.

On the other hand, as I said before, using a middle-layer ->runtime_suspend
during a system sleep transition may be outright incorrect, say if device
wakeup settings need to be adjusted by the middle layer (which is the
case for some of them).

Of course, if the middle layer expects the driver to point its
system-wide PM callbacks to pm_runtime_force_*, then that's how it goes,
but the drivers working with this particular middle layer generally
won't work with other middle layers and may interact incorrectly
with parents and/or children using the other middle layers.

I guess the problem boils down to having a common set of expectations
on the driver side and on the middle layer side allowing different
combinations of these to work together.

> Besides the AMBA case, I also realized that we are dealing with PM
> clocks in the genpd case. For this, genpd relies on the that runtime
> PM status of the device properly reflects the state of the HW, during
> system-wide PM.
> 
> In other words, if the driver would change the runtime PM status of
> the device, without respecting the hierarchy of the runtime PM
> callbacks, it would lead to that genpd starts taking wrong decisions
> while managing the PM clocks during system-wide PM. So in case you
> intend to change pm_runtime_force_* this needs to be addressed too.

I've just looked at the genpd code and quite frankl

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Wednesday, October 18, 2017 2:39:24 AM CEST Rafael J. Wysocki wrote:
> On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:
> 
> [cut]
> 
> > >
> > >> deploying this and from a middle layer point of view, all the trivial
> > >> cases supports this.
> > >
> > > These functions are wrong, however, because they attempt to reuse the
> > > whole callback *path* instead of just reusing driver callbacks.  The
> > > *only* reason why it all "works" is because there are no middle layer
> > > callbacks involved in that now.
> > >
> > > If you changed them to reuse driver callbacks only today, nothing would 
> > > break
> > > AFAICS.
> > 
> > Yes, it would.
> > 
> > First, for example, the amba bus is responsible for the amba bus
> > clock, but relies on drivers to gate/ungate it during system sleep. In
> > case the amba drivers don't use the pm_runtime_force_suspend|resume(),
> > it will explicitly have to start manage the clock during system sleep
> > themselves. Leading to open coding.
> 
> Well, I suspected that something like this would surface. ;-)
> 
> Are there any major reasons why the appended patch (obviously untested) won't
> work, then?

OK, there is a reason, which is the optimizations bundled into
pm_runtime_force_*, because (a) the device may be left in runtime suspend
by them (in which case amba_pm_suspend_early() in my patch should not run)
and (b) pm_runtime_force_resume() may decide to leave it suspended (in which
case amba_pm_suspend_late() in my patch should not run).

[BTW, the "leave the device suspended" optimization in pm_runtime_force_*
is potentially problematic too, because it requires the children to do
the right thing, which effectively means that their drivers need to use
pm_runtime_force_* too, but what if they don't want to reuse their
runtime PM callbacks for system-wide PM?]

Honestly, I don't like the way this is designed.  IMO, it would be better
to do the optimizations and all in the bus type middle-layer code instead
of expecting drivers to use pm_runtime_force_* as their system-wide PM
callbacks (and that expectation should at least be documented, which I'm
not sure is the case now).  But whatever.

It all should work the way it does now without pm_runtime_force_* if (a) the
bus type's PM callbacks are changed like in the last patch and the drivers
(b) point their system suspend callbacks to the runtime PM callback routines
and (c) set DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED for the
devices (if they need to do the PM in ->suspend and ->resume, they may set
DPM_FLAG_AVOID_RPM too).

And if you see a reason why that won't work, please let me know.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Tuesday, October 17, 2017 9:41:16 PM CEST Ulf Hansson wrote:

[cut]

> >
> >> deploying this and from a middle layer point of view, all the trivial
> >> cases supports this.
> >
> > These functions are wrong, however, because they attempt to reuse the
> > whole callback *path* instead of just reusing driver callbacks.  The
> > *only* reason why it all "works" is because there are no middle layer
> > callbacks involved in that now.
> >
> > If you changed them to reuse driver callbacks only today, nothing would 
> > break
> > AFAICS.
> 
> Yes, it would.
> 
> First, for example, the amba bus is responsible for the amba bus
> clock, but relies on drivers to gate/ungate it during system sleep. In
> case the amba drivers don't use the pm_runtime_force_suspend|resume(),
> it will explicitly have to start manage the clock during system sleep
> themselves. Leading to open coding.

Well, I suspected that something like this would surface. ;-)

Are there any major reasons why the appended patch (obviously untested) won't
work, then?

> Second, it will introduce a regression in behavior for all users of
> pm_runtime_force_suspend|resume(), especially during system resume as
> the driver may then end up resuming the device even in case it isn't
> needed.

How so?

I'm talking about a change like in the appended patch, where
pm_runtime_force_* simply invoke driver callbacks directly.  What is
skipped there is middle-layer stuff which is empty anyway in all cases
except for AMBA (if that's all what is lurking below the surface), so
I don't quite see how the failure will happen.

> I believe I have explained why, also several times by now -
> and that's also how far you could take the i2c designware driver at
> this point.
> 
> That said, I assume the second part may be addressed in this series,
> if these drivers convert to use the "driver PM flags", right?
> 
> However, what about the first case? Is some open coding needed or your
> think the amba driver can instruct the amba bus via the "driver PM
> flags"?

With the appended patch applied things should work for AMBA like for
any other bus type implementing PM, so I don't see why not.

> >
> >> Like the spi bus, i2c bus, amba bus, platform
> >> bus, genpd, etc. There are no changes needed to continue to support
> >> this option, if you see what I mean.
> >
> > For the time being, nothing changes in that respect, but eventually I'd
> > prefer the pm_runtime_force_* things to go away, frankly.
> 
> Okay, thanks for that clear statement!
> 
> >
> >> So, when you say that re-using runtime PM callbacks for system-wide PM
> >> isn't going to happen, can you please elaborate what you mean?
> >
> > I didn't mean "reusing runtime PM callbacks for system-wide PM" overall, but
> > reusing *middle-layer* runtime PM callbacks for system-wide PM.  That is the
> > bogus part.
> 
> I think we have discussed this several times, but the arguments you
> have put forward, explaining *why* haven't yet convinced me.

Well, sorry about that.  I would like to be able to explain my point to you so
that you understand my perspective, but if that's not working, that's not a
sufficient reason for me to give up.

I'm just refusing to maintain code that I don't agree with in the long run.

> In principle what you have been saying is that it's a "layering
> violation" to use pm_runtime_force_suspend|resume() from driver's
> system sleep callbacks, but on the other hand you think using
> pm_runtime_get*  and friends is okay!?

Not unconditionally, which would be fair to mention.

Only if it is called in ->prepare or as the first thing in a ->suspend
callback.  Later than that is broken too in principle.

> That makes little sense to me, because it's the same "layering
> violation" that is done for both cases.

The "layering violation" is all about things possibly occurring in a
wrong order.  For example, say a middle-layer ->runtime_suspend is
called via pm_runtime_force_suspend() which in turn is called from
middle-layer ->suspend_late as a driver callback.  If the ->runtime_suspend
does anything significat to the device, then executing the remaining part of
->suspend_late will almost cetainly break things, more or less.

That is not a concern with a middle-layer ->runtime_resume running
*before* a middle-layer ->suspend (or any subsequent callbacks) does
anything significant to the device.

Is there anything in the above which is not clear enough?

> Moreover, you have been explaining that re-using runtime PM callbacks
> for PCI doesn't work. Then my question is, why should a limitation of
> the PCI subsystem put constraints on the behavior for all other
> subsystems/middle-layers?

Because they aren't just PCI subsystem limitations only.  The need to handle
wakeup setup differently for runtime PM and system sleep is not PCI-specific.
The need to handle suspend and hibernation differently isn't too.

Those things may be more obvious in PCI, but they are generic rather than
special.

Also, quite 

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Tuesday, October 17, 2017 10:12:19 PM CEST Alan Stern wrote:
> On Tue, 17 Oct 2017, Ulf Hansson wrote:
> 
> > > These functions are wrong, however, because they attempt to reuse the
> > > whole callback *path* instead of just reusing driver callbacks.  The
> > > *only* reason why it all "works" is because there are no middle layer
> > > callbacks involved in that now.
> > >
> > > If you changed them to reuse driver callbacks only today, nothing would 
> > > break
> > > AFAICS.
> > 
> > Yes, it would.
> > 
> > First, for example, the amba bus is responsible for the amba bus
> > clock, but relies on drivers to gate/ungate it during system sleep. In
> > case the amba drivers don't use the pm_runtime_force_suspend|resume(),
> > it will explicitly have to start manage the clock during system sleep
> > themselves. Leading to open coding.
> 
> I think what Rafael has in mind is that the PM core will call the amba
> bus's ->suspend callback, and that routine will then be able to call
> the amba driver's runtime_suspend routine directly, if it wants to --
> as opposed to going through pm_runtime_force_suspend.

Right in general.

> However, it's not clear whether this fully answers your concerns.

Well, in the particular AMBA case fixing this should be quite straightforward.

> > Second, it will introduce a regression in behavior for all users of
> > pm_runtime_force_suspend|resume(), especially during system resume as
> > the driver may then end up resuming the device even in case it isn't
> > needed. I believe I have explained why, also several times by now -
> > and that's also how far you could take the i2c designware driver at
> > this point.
> > 
> > That said, I assume the second part may be addressed in this series,
> > if these drivers convert to use the "driver PM flags", right?
> 
> Presumably.
> 
> The problem is how to handle things which need to be treated
> differently for runtime PM vs. system suspend vs. hibernation.  If
> everything filters through a runtime_suspend routine, that doesn't
> leave any scope for handling the different kinds of PM transitions
> differently.  Instead, we can make the middle layer (i.e., the bus-type
> callbacks) take care of the varying tasks, and they can directly invoke
> a driver's runtime-PM callbacks to handle all the common activities.  
> If that's how the middle layer wants to do it.

Well, that's what happens today, except that driver runtime PM callbacks
are not directly invoked.  Actually, I tried to implement that, but it was
so ugly and fragile that I gave up.

It really is better if drivers point the different callback pointers to the
same rountine if they want to reuse it.

> > However, what about the first case? Is some open coding needed or your
> > think the amba driver can instruct the amba bus via the "driver PM
> > flags"?
> 
> PM flags won't directly be able to cover things like disabling clocks.  
> But they could be useful for indicating explicitly whether the code to
> take care of those things needs to reside at the driver layer or at the
> bus layer.

Right.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 12/12] PM / core: Add AVOID_RPM driver flag

[Rafael J. Wysocki]

On Tuesday, October 17, 2017 5:33:17 PM CEST Andy Shevchenko wrote:
> On Mon, 2017-10-16 at 03:32 +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > Define and document a new driver flag, DPM_FLAG_AVOID_RPM, to inform
> > the PM core and middle layer code that the driver has something
> > significant to do in its ->suspend and/or ->resume callbacks and
> > runtime PM should be disabled for the device when these callbacks
> > run.
> > 
> > Setting DPM_FLAG_AVOID_RPM (in addition to DPM_FLAG_SMART_SUSPEND)
> > causes runtime PM to be disabled for the device before invoking the
> > driver's ->suspend callback for it and to be enabled again for it
> > only after the driver's ->resume callback has returned.  In addition
> > to that, if the device is in runtime suspend right after disabling
> > runtime PM for it (which means that there was no reason to resume it
> > from runtime suspend beforehand), the invocation of the ->suspend
> > callback will be skipped for it and it will be left in runtime
> > suspend until the "noirq" phase of the subsequent system resume.
> > 
> > If DPM_FLAG_SMART_SUSPEND is not set, DPM_FLAG_AVOID_RPM has no
> > effect.
> > 
> 
> > +   if (dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&
> > +   dev_pm_test_driver_flags(dev, DPM_FLAG_AVOID_RPM)) {
> 
> Wasn't interface designed to allow something like:
>   if (dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND | 
> DPM_FLAG_AVOID_RPM)) {
> instead?

That would return true if any of them was set and both are needed here.

> Does it make sense to have a separate definition for
> DPM_FLAG_SMART_SUSPEND | DPM_FLAG_AVOID_RPM ?

Yes, it does IMO, because if you don't provide ->suspend and ->resume
callbacks, it is sufficient if runtime PM is disabled for the device
in __device_suspend_late() which happens anyway.

DPM_FLAG_AVOID_RPM is about disabling it earlier.

Thanks,
Rafael


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Tuesday, October 17, 2017 10:36:39 AM CEST Ulf Hansson wrote:
> On 16 October 2017 at 03:12, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > Hi All,
> >
> > Well, this took more time than expected, as I tried to cover everything I 
> > had
> > in mind regarding PM flags for drivers.
> >
> > This work was triggered by attempts to fix and optimize PM in the
> > i2c-designware-platdev driver that ended up with adding a couple of
> > flags to the driver's internal data structures for the tracking of
> > device state (https://marc.info/?l=linux-acpi=150629646805636=2).
> > That approach is sort of suboptimal, though, because other drivers will
> > probably want to do similar things and if all of them need to use internal
> > flags for that, quite a bit of code duplication may ensue at least.
> >
> > That can be avoided in a couple of ways and one of them is to provide a 
> > means
> > for drivers to tell the core what to do and to make the core take care of it
> > if told to do so.  Hence, the idea to use driver flags for system-wide PM
> > that was briefly discussed during the LPC in LA last month.
> >
> > One of the flags considered at that time was to possibly cause the core
> > to reuse the runtime PM callback path of a device for system suspend/resume.
> > Admittedly, that idea didn't look too bad to me until I had started to try 
> > to
> > implement it and I got to the PCI bus type's hibernation callbacks.  Then, I
> > moved the patch I was working on to /dev/null right away.  I mean it.
> >
> > No, this is not going to happen.  No way.
> >
> > Moreover, that experience made me realize that the whole *idea* of using the
> > runtime PM callback path for system-wide PM was actually totally bogus 
> > (sorry
> > Ulf).
> >
> > The whole point of having different callbacks pointers for different types 
> > of
> > device transitions is because it may be necessary to do different things in
> > those callbacks in general.  Now, if you consider runtime PM and system
> > suspend/resume *only* and from a driver perspective, then yes, in some cases
> > the same pair of callback routines may be used for all suspend-like and
> > resume-like transitions of the device, but if you add hibernation to the 
> > mix,
> > then it is not so clear any more unless the callbacks don't actually do any
> > power management at all, but simply quiesce the device's activity and then
> > activate it again.  Namely, changing power states of devices during the
> > hibernation's "freeze" and "thaw" transitions rarely makes sense at all and
> > the "restore" transition needs to be able to cope with uninitialized devices
> > (in fact, it should be prepared to cope with devices in *any* state), so
> > runtime PM is hardly suitable for them.  Still, if a *driver* choses to not
> > do any real PM in its PM callbacks and leaves that to a middle layer (quite
> > a few drivers do that), then it possibly can use one pair of callbacks in 
> > all
> > cases and be happy, but middle layers pretty much have to use different
> > callback routines for different transitions.
> >
> > If you are a middle layer, your role is basically to do PM for a certain
> > group of devices.  Thus you cannot really do the same in ->suspend or
> > ->suspend_early and in ->runtime_suspend (because the former generally need 
> > to
> > take device_may_wakeup() into account and the latter doesn't) and you 
> > shouldn't
> > really do the same in ->suspend and ->freeze (becuase the latter shouldn't
> > change the device's power state) and so on.  To put it bluntly, trying
> > to use the ->runtime_suspend callback of a middle layer for anything other
> > than runtime suspend is complete and utter nonsense.  At the same time, the
> > ->runtime_resume callback of a middle layer may be reused to some extent,
> > but even that doesn't cover the "thaw" transitions during hibernation.
> >
> > What can work (and this is the only strategy that can work AFAICS) is to
> > point different callback pointers *in* *a* *driver* to the same routine
> > if the driver wants to reuse that code.  That actually will work for PCI
> > and USB drivers today, at least most of the time, but unfortunately there
> > are problems with it for, say, platform devices.
> >
> > The first problem is the requirement to track the status of the device
> > (suspended vs not suspended) in the callbacks, because the system-wide PM
> > code in the PM core doesn't do that.  The runtime PM 

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Tuesday, October 17, 2017 9:15:43 AM CEST Greg Kroah-Hartman wrote:
> On Tue, Oct 17, 2017 at 12:05:11AM +0200, Rafael J. Wysocki wrote:
> > On Monday, October 16, 2017 8:28:52 AM CEST Greg Kroah-Hartman wrote:
> > > On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > > >  struct dev_pm_info {
> > > > pm_message_tpower_state;
> > > > unsigned intcan_wakeup:1;
> > > > @@ -561,6 +580,7 @@ struct dev_pm_info {
> > > > boolis_late_suspended:1;
> > > > boolearly_init:1;   /* Owned by the PM core 
> > > > */
> > > > booldirect_complete:1;  /* Owned by the 
> > > > PM core */
> > > > +   unsigned intdriver_flags;
> > > 
> > > Minor nit, u32 or u64?
> > 
> > u32 I think, will update.
> > 
> > BTW, there's a mess in this struct overall and I'd like all of the bit 
> > fileds
> > to be the same type (and that shouldn't be bool IMO :-)).
> > 
> > Do you prefer u32 or unsinged int?
> 
> I always prefer an explicit size for variables, unless it's a "generic
> loop" type thing.  So I'll always say "u32" for this.
> 
> And cleaning up the structure would be great, it's grown over time in
> odd ways as you point out.

OK, but that will be separate from this work.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Monday, October 16, 2017 8:31:22 AM CEST Greg Kroah-Hartman wrote:
> On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > +static inline void dev_pm_set_driver_flags(struct device *dev, unsigned 
> > int flags)
> > +{
> > +   dev->power.driver_flags = flags;
> > +}
> 
> Should this function just set the specific bit?  Or is it going to be ok
> to set the whole value, meaning you aren't going to care about turning
> on and off specific flags over the lifetime of the driver/device, you
> are just going to set them once and then just test them as needed?

The idea is to set them once and they should not be touched again until
the driver (or device) goes away, so that would be the whole value at once
(and one of the i2c-designware-platdrv patches actually sets multiple flags
in one go).

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Monday, October 16, 2017 8:28:52 AM CEST Greg Kroah-Hartman wrote:
> On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> >  struct dev_pm_info {
> > pm_message_tpower_state;
> > unsigned intcan_wakeup:1;
> > @@ -561,6 +580,7 @@ struct dev_pm_info {
> > boolis_late_suspended:1;
> > boolearly_init:1;   /* Owned by the PM core */
> > booldirect_complete:1;  /* Owned by the PM core 
> > */
> > +   unsigned intdriver_flags;
> 
> Minor nit, u32 or u64?

u32 I think, will update.

BTW, there's a mess in this struct overall and I'd like all of the bit fileds
to be the same type (and that shouldn't be bool IMO :-)).

Do you prefer u32 or unsinged int?

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

On Monday, October 16, 2017 7:34:52 AM CEST Lukas Wunner wrote:
> On Mon, Oct 16, 2017 at 03:29:02AM +0200, Rafael J. Wysocki wrote:
> > +   :c:func:`dev_pm_set_driver_flags` helper function.]  If the first of
> > +   tese flags is set, the PM core will not apply the direct-complete
> ^
>   these
> 
> > +   proceudre described above to the given device and, consequenty, to any
> ^
> procedure
> 

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

On Mon, Oct 16, 2017 at 9:08 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> On Mon, Oct 16, 2017 at 03:12:35AM +0200, Rafael J. Wysocki wrote:
>> Hi All,
>>
>> Well, this took more time than expected, as I tried to cover everything I had
>> in mind regarding PM flags for drivers.
>>
>> This work was triggered by attempts to fix and optimize PM in the
>> i2c-designware-platdev driver that ended up with adding a couple of
>> flags to the driver's internal data structures for the tracking of
>> device state (https://marc.info/?l=linux-acpi=150629646805636=2).
>> That approach is sort of suboptimal, though, because other drivers will
>> probably want to do similar things and if all of them need to use internal
>> flags for that, quite a bit of code duplication may ensue at least.
>>
>> That can be avoided in a couple of ways and one of them is to provide a means
>> for drivers to tell the core what to do and to make the core take care of it
>> if told to do so.  Hence, the idea to use driver flags for system-wide PM
>> that was briefly discussed during the LPC in LA last month.
>>
>> One of the flags considered at that time was to possibly cause the core
>> to reuse the runtime PM callback path of a device for system suspend/resume.
>> Admittedly, that idea didn't look too bad to me until I had started to try to
>> implement it and I got to the PCI bus type's hibernation callbacks.  Then, I
>> moved the patch I was working on to /dev/null right away.  I mean it.
>>
>> No, this is not going to happen.  No way.
>>
>> Moreover, that experience made me realize that the whole *idea* of using the
>> runtime PM callback path for system-wide PM was actually totally bogus (sorry
>> Ulf).
>>
>> The whole point of having different callbacks pointers for different types of
>> device transitions is because it may be necessary to do different things in
>> those callbacks in general.  Now, if you consider runtime PM and system
>> suspend/resume *only* and from a driver perspective, then yes, in some cases
>> the same pair of callback routines may be used for all suspend-like and
>> resume-like transitions of the device, but if you add hibernation to the mix,
>> then it is not so clear any more unless the callbacks don't actually do any
>> power management at all, but simply quiesce the device's activity and then
>> activate it again.  Namely, changing power states of devices during the
>> hibernation's "freeze" and "thaw" transitions rarely makes sense at all and
>> the "restore" transition needs to be able to cope with uninitialized devices
>> (in fact, it should be prepared to cope with devices in *any* state), so
>> runtime PM is hardly suitable for them.  Still, if a *driver* choses to not
>> do any real PM in its PM callbacks and leaves that to a middle layer (quite
>> a few drivers do that), then it possibly can use one pair of callbacks in all
>> cases and be happy, but middle layers pretty much have to use different
>> callback routines for different transitions.
>>
>> If you are a middle layer, your role is basically to do PM for a certain
>> group of devices.  Thus you cannot really do the same in ->suspend or
>> ->suspend_early and in ->runtime_suspend (because the former generally need 
>> to
>> take device_may_wakeup() into account and the latter doesn't) and you 
>> shouldn't
>> really do the same in ->suspend and ->freeze (becuase the latter shouldn't
>> change the device's power state) and so on.  To put it bluntly, trying
>> to use the ->runtime_suspend callback of a middle layer for anything other
>> than runtime suspend is complete and utter nonsense.  At the same time, the
>> ->runtime_resume callback of a middle layer may be reused to some extent,
>> but even that doesn't cover the "thaw" transitions during hibernation.
>>
>> What can work (and this is the only strategy that can work AFAICS) is to
>> point different callback pointers *in* *a* *driver* to the same routine
>> if the driver wants to reuse that code.  That actually will work for PCI
>> and USB drivers today, at least most of the time, but unfortunately there
>> are problems with it for, say, platform devices.
>>
>> The first problem is the requirement to track the status of the device
>> (suspended vs not suspended) in the callbacks, because the system-wide PM
>> code in the PM core doesn't do that.  The runtime PM framework does it, so
>> this means adding some extra code which isn't necessary for runtime PM to
>> the callback ro

[PATCH 12/12] PM / core: Add AVOID_RPM driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a new driver flag, DPM_FLAG_AVOID_RPM, to inform
the PM core and middle layer code that the driver has something
significant to do in its ->suspend and/or ->resume callbacks and
runtime PM should be disabled for the device when these callbacks
run.

Setting DPM_FLAG_AVOID_RPM (in addition to DPM_FLAG_SMART_SUSPEND)
causes runtime PM to be disabled for the device before invoking the
driver's ->suspend callback for it and to be enabled again for it
only after the driver's ->resume callback has returned.  In addition
to that, if the device is in runtime suspend right after disabling
runtime PM for it (which means that there was no reason to resume it
from runtime suspend beforehand), the invocation of the ->suspend
callback will be skipped for it and it will be left in runtime
suspend until the "noirq" phase of the subsequent system resume.

If DPM_FLAG_SMART_SUSPEND is not set, DPM_FLAG_AVOID_RPM has no
effect.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |   14 ++
 Documentation/power/pci.txt |9 +++-
 drivers/acpi/device_pm.c|   24 ++-
 drivers/base/power/main.c   |   31 ++
 drivers/pci/pci-driver.c|   69 ++--
 include/linux/pm.h  |   10 
 6 files changed, 134 insertions(+), 23 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -560,6 +560,7 @@ struct pm_subsys_data {
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
  * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
+ * AVOID_RPM: Disable runtime PM and check its status before ->suspend.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -577,11 +578,17 @@ struct pm_subsys_data {
  *
  * Setting LEAVE_SUSPENDED informs the PM core and middle layer code that the
  * driver prefers the device to be left in runtime suspend after system resume.
+ *
+ * Setting AVOID_RPM informs the PM core and middle layer code that the driver
+ * has something significant to do in its ->suspend and/or ->resume callbacks
+ * and runtime PM should be disabled for the device when these callbacks run.
+ * If SMART_SUSPEND is not set, this flag has no effect.
  */
 #define DPM_FLAG_NEVER_SKIPBIT(0)
 #define DPM_FLAG_SMART_PREPARE BIT(1)
 #define DPM_FLAG_SMART_SUSPEND BIT(2)
 #define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
+#define DPM_FLAG_AVOID_RPM BIT(4)
 
 struct dev_pm_info {
pm_message_tpower_state;
@@ -604,6 +611,7 @@ struct dev_pm_info {
boolsyscore:1;
boolno_pm_callbacks:1;  /* Owned by the PM core 
*/
unsigned intmust_resume:1;  /* Owned by the PM core */
+   unsigned intrpm_reenable:1; /* Do not modify directly */
 #else
unsigned intshould_wakeup:1;
 #endif
@@ -741,6 +749,8 @@ extern int dpm_suspend_late(pm_message_t
 extern int dpm_suspend(pm_message_t state);
 extern int dpm_prepare(pm_message_t state);
 
+extern void dpm_disable_runtime_pm_early(struct device *dev);
+
 extern void __suspend_report_result(const char *function, void *fn, int ret);
 
 #define suspend_report_result(fn, ret) \
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -906,6 +906,10 @@ static int device_resume(struct device *
  Unlock:
device_unlock(dev);
dpm_watchdog_clear();
+   if (dev->power.rpm_reenable) {
+   pm_runtime_enable(dev);
+   dev->power.rpm_reenable = false;
+   }
 
  Complete:
complete_all(>power.completion);
@@ -1534,6 +1538,12 @@ static int legacy_suspend(struct device
return error;
 }
 
+void dpm_disable_runtime_pm_early(struct device *dev)
+{
+   pm_runtime_disable(dev);
+   dev->power.rpm_reenable = true;
+}
+
 static void dpm_clear_suppliers_direct_complete(struct device *dev)
 {
struct device_link *link;
@@ -1636,6 +1646,27 @@ static int __device_suspend(struct devic
if (!callback && dev->driver && dev->driver->pm) {
info = "driver ";
callback = pm_op(dev->driver->pm, state);
+   if (callback &&
+   dev_pm_test_dri

[PATCH 07/12] ACPI / LPSS: Consolidate runtime PM and system sleep handling

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Move the LPSS-specific code from acpi_lpss_runtime_suspend()
and acpi_lpss_runtime_resume() into separate functions,
acpi_lpss_suspend() and acpi_lpss_resume(), respectively, and
make acpi_lpss_suspend_late() and acpi_lpss_resume_early() use
them too in order to unify the runtime PM and system sleep
handling in the LPSS driver.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---

This is based on an RFC I posted some time ago
(https://patchwork.kernel.org/patch/9998147/), which didn't
receive any comments and it depends on a couple of ACPI device PM
patches posted recently (https://patchwork.kernel.org/patch/10006457/
in particular).

It's included in this series, because the next patch won't work without it.

---
 drivers/acpi/acpi_lpss.c |   75 ---
 1 file changed, 33 insertions(+), 42 deletions(-)

Index: linux-pm/drivers/acpi/acpi_lpss.c
===
--- linux-pm.orig/drivers/acpi/acpi_lpss.c
+++ linux-pm/drivers/acpi/acpi_lpss.c
@@ -716,40 +716,6 @@ static void acpi_lpss_dismiss(struct dev
acpi_dev_suspend(dev, false);
 }
 
-#ifdef CONFIG_PM_SLEEP
-static int acpi_lpss_suspend_late(struct device *dev)
-{
-   struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
-   int ret;
-
-   ret = pm_generic_suspend_late(dev);
-   if (ret)
-   return ret;
-
-   if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
-   acpi_lpss_save_ctx(dev, pdata);
-
-   return acpi_dev_suspend(dev, device_may_wakeup(dev));
-}
-
-static int acpi_lpss_resume_early(struct device *dev)
-{
-   struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
-   int ret;
-
-   ret = acpi_dev_resume(dev);
-   if (ret)
-   return ret;
-
-   acpi_lpss_d3_to_d0_delay(pdata);
-
-   if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
-   acpi_lpss_restore_ctx(dev, pdata);
-
-   return pm_generic_resume_early(dev);
-}
-#endif /* CONFIG_PM_SLEEP */
-
 /* IOSF SB for LPSS island */
 #define LPSS_IOSF_UNIT_LPIOEP  0xA0
 #define LPSS_IOSF_UNIT_LPIO1   0xAB
@@ -835,19 +801,15 @@ static void lpss_iosf_exit_d3_state(void
mutex_unlock(_iosf_mutex);
 }
 
-static int acpi_lpss_runtime_suspend(struct device *dev)
+static int acpi_lpss_suspend(struct device *dev, bool wakeup)
 {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
 
-   ret = pm_generic_runtime_suspend(dev);
-   if (ret)
-   return ret;
-
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_save_ctx(dev, pdata);
 
-   ret = acpi_dev_suspend(dev, true);
+ret = acpi_dev_suspend(dev, wakeup);
 
/*
 * This call must be last in the sequence, otherwise PMC will return
@@ -860,7 +822,7 @@ static int acpi_lpss_runtime_suspend(str
return ret;
 }
 
-static int acpi_lpss_runtime_resume(struct device *dev)
+static int acpi_lpss_resume(struct device *dev)
 {
struct lpss_private_data *pdata = acpi_driver_data(ACPI_COMPANION(dev));
int ret;
@@ -881,7 +843,36 @@ static int acpi_lpss_runtime_resume(stru
if (pdata->dev_desc->flags & LPSS_SAVE_CTX)
acpi_lpss_restore_ctx(dev, pdata);
 
-   return pm_generic_runtime_resume(dev);
+   return 0;
+}
+#ifdef CONFIG_PM_SLEEP
+static int acpi_lpss_suspend_late(struct device *dev)
+{
+   int ret = pm_generic_suspend_late(dev);
+
+   return ret ? ret : acpi_lpss_suspend(dev, device_may_wakeup(dev));
+}
+
+static int acpi_lpss_resume_early(struct device *dev)
+{
+   int ret = acpi_lpss_resume(dev);
+
+   return ret ? ret : pm_generic_resume_early(dev);
+}
+#endif /* CONFIG_PM_SLEEP */
+
+static int acpi_lpss_runtime_suspend(struct device *dev)
+{
+   int ret = pm_generic_runtime_suspend(dev);
+
+   return ret ? ret : acpi_lpss_suspend(dev, true);
+}
+
+static int acpi_lpss_runtime_resume(struct device *dev)
+{
+   int ret = acpi_lpss_resume(dev);
+
+   return ret ? ret : pm_generic_runtime_resume(dev);
 }
 #endif /* CONFIG_PM */
 


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 08/12] ACPI / PM: Take SMART_SUSPEND driver flag into account

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in
its system suspend callbacks.

[Note that the pm_runtime_suspended() check in acpi_dev_needs_resume()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/acpi/device_pm.c |   21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

Index: linux-pm/drivers/acpi/device_pm.c
===
--- linux-pm.orig/drivers/acpi/device_pm.c
+++ linux-pm/drivers/acpi/device_pm.c
@@ -936,7 +936,8 @@ static bool acpi_dev_needs_resume(struct
u32 sys_target = acpi_target_system_state();
int ret, state;
 
-   if (device_may_wakeup(dev) != !!adev->wakeup.prepare_count)
+   if (!pm_runtime_suspended(dev) || !adev ||
+   device_may_wakeup(dev) != !!adev->wakeup.prepare_count)
return true;
 
if (sys_target == ACPI_STATE_S0)
@@ -968,9 +969,6 @@ int acpi_subsys_prepare(struct device *d
if (!ret && dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_PREPARE))
return 0;
 
-   if (!adev || !pm_runtime_suspended(dev))
-   return 0;
-
return !acpi_dev_needs_resume(dev, adev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_prepare);
@@ -996,12 +994,17 @@ EXPORT_SYMBOL_GPL(acpi_subsys_complete);
  * acpi_subsys_suspend - Run the device driver's suspend callback.
  * @dev: Device to handle.
  *
- * Follow PCI and resume devices suspended at run time before running their
- * system suspend callbacks.
+ * Follow PCI and resume devices from runtime suspend before running their
+ * system suspend callbacks, unless the driver can cope with runtime-suspended
+ * devices during system suspend and there are no ACPI-specific reasons for
+ * resuming them.
  */
 int acpi_subsys_suspend(struct device *dev)
 {
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
+   acpi_dev_needs_resume(dev, ACPI_COMPANION(dev)))
+   pm_runtime_resume(dev);
+
return pm_generic_suspend(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_suspend);
@@ -1047,7 +1050,9 @@ int acpi_subsys_freeze(struct device *de
 * runtime-suspended devices should not be touched during freeze/thaw
 * transitions.
 */
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND))
+   pm_runtime_resume(dev);
+
return pm_generic_freeze(dev);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_freeze);


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 11/12] PM: i2c-designware-platdrv: Optimize power management

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Optimize the power management in i2c-designware-platdrv by making it
set the DPM_FLAG_SMART_SUSPEND and DPM_FLAG_LEAVE_SUSPENDED which
allows some code to be dropped from its PM callbacks.

First, setting DPM_FLAG_SMART_SUSPEND causes the intel-lpss driver
to avoid resuming i2c-designware-platdrv devices in its ->prepare
callback, so they can stay in runtime suspend after that point even
if the direct-complete feature is not used for them.

It also causes the PM core to avoid invoking "late" and "noirq"
suspend callbacks for these devices if they are in runtime suspend
at the beginning of the "late" phase of device suspend during
system suspend.  That guarantees dw_i2c_plat_suspend() to be
called for a device only if it is not in runtime suspend.
Moreover, it also causes the PM core to set the device's runtime
PM status to "active" after calling dw_i2c_plat_resume() for
it, so the driver doesn't need internal flags to avoid invoking
either dw_i2c_plat_suspend() or dw_i2c_plat_resume() twice in
a row.

Second, setting DPM_FLAG_LEAVE_SUSPENDED enables the optimization
allowing the device to stay suspended after system resume under
suitable conditions, so again the driver doesn't need to take
care of that by itself.

Accordingly, the internal "suspended" and "skip_resume" flags
used by the driver are not necessary any more, so drop them and
simplify the driver's PM callbacks.

Additionally, notice that dw_i2c_plat_complete() only needs
to schedule runtime PM for the device if platform firmware
has been involved in resuming the system, so make it call
pm_resume_via_firmware() to check that.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/i2c/busses/i2c-designware-core.h|2 --
 drivers/i2c/busses/i2c-designware-platdrv.c |   25 ++---
 2 files changed, 6 insertions(+), 21 deletions(-)

Index: linux-pm/drivers/i2c/busses/i2c-designware-core.h
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-core.h
+++ linux-pm/drivers/i2c/busses/i2c-designware-core.h
@@ -280,8 +280,6 @@ struct dw_i2c_dev {
int (*acquire_lock)(struct dw_i2c_dev *dev);
void(*release_lock)(struct dw_i2c_dev *dev);
boolpm_disabled;
-   boolsuspended;
-   boolskip_resume;
void(*disable)(struct dw_i2c_dev *dev);
void(*disable_int)(struct dw_i2c_dev *dev);
int (*init)(struct dw_i2c_dev *dev);
Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i2c-designware-core.h"
 
@@ -370,7 +371,10 @@ static int dw_i2c_plat_probe(struct plat
ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
 
-   dev_pm_set_driver_flags(>dev, DPM_FLAG_SMART_PREPARE);
+   dev_pm_set_driver_flags(>dev,
+   DPM_FLAG_SMART_PREPARE |
+   DPM_FLAG_SMART_SUSPEND |
+   DPM_FLAG_LEAVE_SUSPENDED);
 
/* The code below assumes runtime PM to be disabled. */
WARN_ON(pm_runtime_enabled(>dev));
@@ -446,7 +450,7 @@ static int dw_i2c_plat_prepare(struct de
 
 static void dw_i2c_plat_complete(struct device *dev)
 {
-   if (dev->power.direct_complete)
+   if (dev->power.direct_complete && pm_resume_via_firmware())
pm_request_resume(dev);
 }
 #else
@@ -459,16 +463,9 @@ static int dw_i2c_plat_suspend(struct de
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (i_dev->suspended) {
-   i_dev->skip_resume = true;
-   return 0;
-   }
-
i_dev->disable(i_dev);
i2c_dw_plat_prepare_clk(i_dev, false);
 
-   i_dev->suspended = true;
-
return 0;
 }
 
@@ -476,19 +473,9 @@ static int dw_i2c_plat_resume(struct dev
 {
struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
-   if (!i_dev->suspended)
-   return 0;
-
-   if (i_dev->skip_resume) {
-   i_dev->skip_resume = false;
-   return 0;
-   }
-
i2c_dw_plat_prepare_clk(i_dev, true);
i_dev->init(i_dev);
 
-   i_dev->suspended = false;
-
return 0;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/12] PCI / PM: Take SMART_SUSPEND driver flag into account

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the PCI bus type take DPM_FLAG_SMART_SUSPEND into account in its
system suspend callbacks and make sure that all code that should not
run in parallel with pci_pm_runtime_resume() is executed in the "late"
phases of system suspend, freeze and poweroff transitions.

[Note that the pm_runtime_suspended() check in pci_dev_keep_suspended()
is an optimization, because if is not passed, all of the subsequent
checks may be skipped and some of them are much more overhead in
general.]

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
---
 Documentation/power/pci.txt |6 
 drivers/pci/pci-driver.c|   56 ++--
 2 files changed, 45 insertions(+), 17 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -727,18 +727,25 @@ static int pci_pm_suspend(struct device
 
if (!pm) {
pci_pm_default_suspend(pci_dev);
-   goto Fixup;
+   return 0;
}
 
/*
-* PCI devices suspended at run time need to be resumed at this point,
-* because in general it is necessary to reconfigure them for system
-* suspend.  Namely, if the device is supposed to wake up the system
-* from the sleep state, we may need to reconfigure it for this purpose.
-* In turn, if the device is not supposed to wake up the system from the
-* sleep state, we'll have to prevent it from signaling wake-up.
+* PCI devices suspended at run time may need to be resumed at this
+* point, because in general it may be necessary to reconfigure them for
+* system suspend.  Namely, if the device is expected to wake up the
+* system from the sleep state, it may have to be reconfigured for this
+* purpose, or if the device is not expected to wake up the system from
+* the sleep state, it should be prevented from signaling wakeup events
+* going forward.
+*
+* Also if the driver of the device does not indicate that its system
+* suspend callbacks can cope with runtime-suspended devices, it is
+* better to resume the device from runtime suspend here.
 */
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
+   !pci_dev_keep_suspended(pci_dev))
+   pm_runtime_resume(dev);
 
pci_dev->state_saved = false;
if (pm->suspend) {
@@ -758,12 +765,16 @@ static int pci_pm_suspend(struct device
}
}
 
- Fixup:
-   pci_fixup_device(pci_fixup_suspend, pci_dev);
-
return 0;
 }
 
+static int pci_pm_suspend_late(struct device *dev)
+{
+   pci_fixup_device(pci_fixup_suspend, to_pci_dev(dev));
+
+   return pm_generic_suspend_late(dev);;
+}
+
 static int pci_pm_suspend_noirq(struct device *dev)
 {
struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -872,6 +883,7 @@ static int pci_pm_resume(struct device *
 #else /* !CONFIG_SUSPEND */
 
 #define pci_pm_suspend NULL
+#define pci_pm_suspend_lateNULL
 #define pci_pm_suspend_noirq   NULL
 #define pci_pm_resume  NULL
 #define pci_pm_resume_noirqNULL
@@ -906,7 +918,8 @@ static int pci_pm_freeze(struct device *
 * devices should not be touched during freeze/thaw transitions,
 * however.
 */
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND))
+   pm_runtime_resume(dev);
 
pci_dev->state_saved = false;
if (pm->freeze) {
@@ -1004,11 +1017,13 @@ static int pci_pm_poweroff(struct device
 
if (!pm) {
pci_pm_default_suspend(pci_dev);
-   goto Fixup;
+   return 0;
}
 
/* The reason to do that is the same as in pci_pm_suspend(). */
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) ||
+   !pci_dev_keep_suspended(pci_dev))
+   pm_runtime_resume(dev);
 
pci_dev->state_saved = false;
if (pm->poweroff) {
@@ -1020,12 +1035,16 @@ static int pci_pm_poweroff(struct device
return error;
}
 
- Fixup:
-   pci_fixup_device(pci_fixup_suspend, pci_dev);
-
return 0;
 }
 
+static int pci_pm_poweroff_late(struct device *dev)
+{
+   pci_fixup_device(pci_fixup_suspend, to_pci_dev(dev));
+
+   return pm_generic_poweroff_late(dev);
+}
+
 static int pci_pm_poweroff_noirq(struct device *dev)
 {
struct pci_dev *pci_dev = to_pci_dev(dev);
@@ -1124,6 +1143,7 @@ static int pci_pm_restore(struct device
 #define pci_pm_thawNULL
 #define pci_pm_thaw_noirq  NULL
 #define pci_pm_poweroffNULL
+#def

[PATCH 05/12] PCI / PM: Drop unnecessary invocations of pcibios_pm_ops callbacks

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

The only user of non-empty pcibios_pm_ops is s390 and it only uses
"noirq" callbacks, so drop the invocations of the other pcibios_pm_ops
callbacks from the PCI PM code.

That will allow subsequent changes to be somewhat simpler.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/pci/pci-driver.c |   18 --
 1 file changed, 18 deletions(-)

Index: linux-pm/drivers/pci/pci-driver.c
===
--- linux-pm.orig/drivers/pci/pci-driver.c
+++ linux-pm/drivers/pci/pci-driver.c
@@ -918,9 +918,6 @@ static int pci_pm_freeze(struct device *
return error;
}
 
-   if (pcibios_pm_ops.freeze)
-   return pcibios_pm_ops.freeze(dev);
-
return 0;
 }
 
@@ -982,12 +979,6 @@ static int pci_pm_thaw(struct device *de
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int error = 0;
 
-   if (pcibios_pm_ops.thaw) {
-   error = pcibios_pm_ops.thaw(dev);
-   if (error)
-   return error;
-   }
-
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume(dev);
 
@@ -1032,9 +1023,6 @@ static int pci_pm_poweroff(struct device
  Fixup:
pci_fixup_device(pci_fixup_suspend, pci_dev);
 
-   if (pcibios_pm_ops.poweroff)
-   return pcibios_pm_ops.poweroff(dev);
-
return 0;
 }
 
@@ -1107,12 +1095,6 @@ static int pci_pm_restore(struct device
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int error = 0;
 
-   if (pcibios_pm_ops.restore) {
-   error = pcibios_pm_ops.restore(dev);
-   if (error)
-   return error;
-   }
-
/*
 * This is necessary for the hibernation error path in which restore is
 * called without restoring the standard config registers of the device.


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 04/12] PM / core: Add SMART_SUSPEND driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a SMART_SUSPEND flag to instruct bus types and PM
domains that the system suspend callbacks provided by the driver can
cope with runtime-suspended devices, so from the driver's perspective
it should be safe to leave devices in runtime suspend during system
suspend.

Setting that flag also causes the PM core to skip the "late" and
"noirq" phases of device suspend for devices that remain in runtime
suspend at the beginning of the "late" phase (when runtime PM has
been disabled for them) under the assumption that their state cannot
(and should not) change after that point until the system suspend
transition is complete.  Moreover, the PM core prevents runtime PM
from acting on devices with DPM_FLAG_SMART_SUSPEND during system
resume by setting their runtime PM status to "active" at the end of
the "early" phase (right prior to enabling runtime PM for them).
That allows system resume callbacks to do whatever is necessary to
resume the device without worrying about runtime PM possibly
running in parallel with them.

However, that doesn't apply to transitions involving ->thaw_noirq,
->thaw_early and ->thaw callbacks during hibernation, as they
generally are not expected to change the power states of devices.
Consequently, if a device is in runtime suspend at the beginning
of such a transition, it must stay in runtime suspend until the
"complete" phase of it (since the callbacks may not change its
power state).

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |   17 
 drivers/base/power/main.c   |   63 
 include/linux/pm.h  |9 
 3 files changed, 82 insertions(+), 7 deletions(-)

Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -766,6 +766,23 @@ the state of devices (possibly except fo
 from their ``->prepare`` and ``->suspend`` callbacks (or equivalent) *before*
 invoking device drivers' ``->suspend`` callbacks (or equivalent).
 
+Some bus types and PM domains have a policy to resume all devices from runtime
+suspend upfront in their ``->suspend`` callbacks, but that may not be really
+necessary if the system suspend-resume callbacks provided by the device's
+driver can cope with runtime-suspended devices.  The driver can indicate that
+by setting ``DPM_FLAG_SMART_SUSPEND`` in :c:member:`power.driver_flags` at the
+probe time, by passing it to the :c:func:`dev_pm_set_driver_flags` helper.  
That
+also causes the PM core to skip the ``suspend_late`` and ``suspend_noirq``
+phases of device suspend for the device if it remains in runtime suspend at the
+beginning of the ``suspend_late`` phase (when runtime PM has been disabled for
+it) under the assumption that its state cannot (and should not) change after
+that point until the system-wide transition is over.  Moreover, the PM core
+updates the runtime power management status of devices with
+``DPM_FLAG_SMART_SUSPEND`` set to "active" at the end of the ``resume_early``
+phase of device resume (right prior to enabling runtime PM for them) in order
+to prevent runtime PM from acting on them before the ``complete`` phase, which
+means that they should be put into the full-power state before that phase.
+
 During system-wide resume from a sleep state it's easiest to put devices into
 the full-power state, as explained in 
:file:`Documentation/power/runtime_pm.txt`.
 Refer to that document for more information regarding this particular issue as
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -558,6 +558,7 @@ struct pm_subsys_data {
  *
  * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
+ * SMART_SUSPEND: No need to resume the device from runtime suspend.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -565,9 +566,17 @@ struct pm_subsys_data {
  * other words, the system suspend/resume callbacks can only be skipped for the
  * device if its driver doesn't object against that).  This flag has no effect
  * if NEVER_SKIP is set.
+ *
+ * Setting SMART_SUSPEND instructs bus types and PM domains which may want to
+ * runtime resume the device upfront during system suspend that doing so is not
+ * necessary from the driver's perspective.  It also causes the PM core to skip
+ * the "late" and "noirq" phases of device 

[PATCH 10/12] PM / core: Add LEAVE_SUSPENDED driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Define and document a new driver flag, DPM_FLAG_LEAVE_SUSPENDED, to
instruct the PM core that it is desirable to leave the device in
runtime suspend after system resume (for example, the device may be
slow to resume and it may be better to avoid resuming it right away
for this reason).

Setting that flag causes the PM core to skip the ->resume_noirq,
->resume_early and ->resume callbacks for the device (like in the
direct-complete optimization case) if (1) the wakeup settings of it
are compatible with runtime PM (that is, either the device is
configured to wake up the system from sleep or it cannot generate
wakeup signals at all), and it will not be used for resuming any of
its children or consumers.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |   20 +++
 drivers/base/power/main.c   |   81 ++--
 include/linux/pm.h  |   12 +++-
 3 files changed, 104 insertions(+), 9 deletions(-)

Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -559,6 +559,7 @@ struct pm_subsys_data {
  * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
  * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
  * SMART_SUSPEND: No need to resume the device from runtime suspend.
+ * LEAVE_SUSPENDED: Avoid resuming the device during system resume if possible.
  *
  * Setting SMART_PREPARE instructs bus types and PM domains which may want
  * system suspend/resume callbacks to be skipped for the device to return 0 
from
@@ -573,10 +574,14 @@ struct pm_subsys_data {
  * the "late" and "noirq" phases of device suspend for the device if it remains
  * in runtime suspend at the beginning of the "late" phase (when runtime PM has
  * been disabled for it).
+ *
+ * Setting LEAVE_SUSPENDED informs the PM core and middle layer code that the
+ * driver prefers the device to be left in runtime suspend after system resume.
  */
-#define DPM_FLAG_NEVER_SKIPBIT(0)
-#define DPM_FLAG_SMART_PREPARE BIT(1)
-#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+#define DPM_FLAG_SMART_SUSPEND BIT(2)
+#define DPM_FLAG_LEAVE_SUSPENDED   BIT(3)
 
 struct dev_pm_info {
pm_message_tpower_state;
@@ -598,6 +603,7 @@ struct dev_pm_info {
boolwakeup_path:1;
boolsyscore:1;
boolno_pm_callbacks:1;  /* Owned by the PM core 
*/
+   unsigned intmust_resume:1;  /* Owned by the PM core */
 #else
unsigned intshould_wakeup:1;
 #endif
Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -705,6 +705,12 @@ static int device_resume_early(struct de
if (!dev->power.is_late_suspended)
goto Out;
 
+   if (dev_pm_test_driver_flags(dev, DPM_FLAG_LEAVE_SUSPENDED) &&
+   !dev->power.must_resume) {
+   pm_runtime_set_suspended(dev);
+   goto Out;
+   }
+
dpm_wait_for_superior(dev, async);
 
if (dev->pm_domain) {
@@ -1098,6 +1104,32 @@ static pm_message_t resume_event(pm_mess
return PMSG_ON;
 }
 
+static void dpm_suppliers_set_must_resume(struct device *dev)
+{
+   struct device_link *link;
+   int idx;
+
+   idx = device_links_read_lock();
+
+   list_for_each_entry_rcu(link, >links.suppliers, c_node)
+   link->supplier->power.must_resume = true;
+
+   device_links_read_unlock(idx);
+}
+
+static void dpm_leave_suspended(struct device *dev)
+{
+   pm_runtime_set_suspended(dev);
+   dev->power.is_suspended = false;
+   dev->power.is_late_suspended = false;
+   /*
+* This tells middle layer code to schedule runtime resume of the device
+* from its ->complete callback to update the device's power state in
+* case the platform firmware has been involved in resuming the system.
+*/
+   dev->power.direct_complete = true;
+}
+
 /**
  * __device_suspend_noirq - Execute a "noirq suspend" callback for given 
device.
  * @dev: Device to handle.
@@ -1135,8 +1167,20 @@ static int __device_suspend_noirq(struct
 * the callback invocation for them.
 */
if (dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&
-   pm_runtime_status_suspended(dev))
-   goto Skip;
+   pm_runtime_status_suspended(dev)) {
+   /*
+* The device may be lef

[PATCH 03/12] PM: i2c-designware-platdrv: Use DPM_FLAG_SMART_PREPARE

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Modify i2c-designware-platdrv to set DPM_FLAG_SMART_PREPARE for its
devices and return 0 from the system suspend ->prepare callback
if the device has an ACPI companion object in order to tell the PM
core and middle layers to avoid skipping system suspend/resume
callbacks for the device in that case (which may be problematic,
because the device may be accessed during suspend and resume of
other devices via I2C operation regions then).

Also the pm_runtime_suspended() check in dw_i2c_plat_prepare()
is not necessary any more, because the core does it when setting
power.direct_complete for the device, so drop it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/i2c/busses/i2c-designware-platdrv.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
===
--- linux-pm.orig/drivers/i2c/busses/i2c-designware-platdrv.c
+++ linux-pm/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -370,6 +370,8 @@ static int dw_i2c_plat_probe(struct plat
ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
 
+   dev_pm_set_driver_flags(>dev, DPM_FLAG_SMART_PREPARE);
+
/* The code below assumes runtime PM to be disabled. */
WARN_ON(pm_runtime_enabled(>dev));
 
@@ -433,7 +435,13 @@ MODULE_DEVICE_TABLE(of, dw_i2c_of_match)
 #ifdef CONFIG_PM_SLEEP
 static int dw_i2c_plat_prepare(struct device *dev)
 {
-   return pm_runtime_suspended(dev);
+   /*
+* If the ACPI companion device object is present for this device, it
+* may be accessed during suspend and resume of other devices via I2C
+* operation regions, so tell the PM core and middle layers to avoid
+* skipping system suspend/resume callbacks for it in that case.
+*/
+   return !has_acpi_companion(dev);
 }
 
 static void dw_i2c_plat_complete(struct device *dev)


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/12] PM / mfd: intel-lpss: Use DPM_FLAG_SMART_SUSPEND

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Make the intel-lpss driver set DPM_FLAG_SMART_SUSPEND for its
devices which will allow them to stay in runtime suspend during
system suspend unless they need to be reconfigured for some reason.

Also make it avoid resuming its child devices if they have
DPM_FLAG_SMART_SUSPEND set to allow them to remain in runtime
suspend during system suspend.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/mfd/intel-lpss.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-pm/drivers/mfd/intel-lpss.c
===
--- linux-pm.orig/drivers/mfd/intel-lpss.c
+++ linux-pm/drivers/mfd/intel-lpss.c
@@ -450,6 +450,8 @@ int intel_lpss_probe(struct device *dev,
if (ret)
goto err_remove_ltr;
 
+   dev_pm_set_driver_flags(dev, DPM_FLAG_SMART_SUSPEND);
+
return 0;
 
 err_remove_ltr:
@@ -478,7 +480,9 @@ EXPORT_SYMBOL_GPL(intel_lpss_remove);
 
 static int resume_lpss_device(struct device *dev, void *data)
 {
-   pm_runtime_resume(dev);
+   if (!dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND))
+   pm_runtime_resume(dev);
+
return 0;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 02/12] PCI / PM: Use the NEVER_SKIP driver flag

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Replace the PCI-specific flag PCI_DEV_FLAGS_NEEDS_RESUME with the
PM core's DPM_FLAG_NEVER_SKIP one everywhere and drop it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.c |2 +-
 drivers/misc/mei/pci-me.c   |2 +-
 drivers/misc/mei/pci-txe.c  |2 +-
 drivers/pci/pci.c   |3 +--
 include/linux/pci.h |7 +--
 5 files changed, 5 insertions(+), 11 deletions(-)

Index: linux-pm/include/linux/pci.h
===
--- linux-pm.orig/include/linux/pci.h
+++ linux-pm/include/linux/pci.h
@@ -205,13 +205,8 @@ enum pci_dev_flags {
PCI_DEV_FLAGS_BRIDGE_XLATE_ROOT = (__force pci_dev_flags_t) (1 << 9),
/* Do not use FLR even if device advertises PCI_AF_CAP */
PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10),
-   /*
-* Resume before calling the driver's system suspend hooks, disabling
-* the direct_complete optimization.
-*/
-   PCI_DEV_FLAGS_NEEDS_RESUME = (__force pci_dev_flags_t) (1 << 11),
/* Don't use Relaxed Ordering for TLPs directed at this device */
-   PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 12),
+   PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11),
 };
 
 enum pci_irq_reroute_variant {
Index: linux-pm/drivers/pci/pci.c
===
--- linux-pm.orig/drivers/pci/pci.c
+++ linux-pm/drivers/pci/pci.c
@@ -2166,8 +2166,7 @@ bool pci_dev_keep_suspended(struct pci_d
 
if (!pm_runtime_suspended(dev)
|| pci_target_state(pci_dev, wakeup) != pci_dev->current_state
-   || platform_pci_need_resume(pci_dev)
-   || (pci_dev->dev_flags & PCI_DEV_FLAGS_NEEDS_RESUME))
+   || platform_pci_need_resume(pci_dev))
return false;
 
/*
Index: linux-pm/drivers/gpu/drm/i915/i915_drv.c
===
--- linux-pm.orig/drivers/gpu/drm/i915/i915_drv.c
+++ linux-pm/drivers/gpu/drm/i915/i915_drv.c
@@ -1304,7 +1304,7 @@ int i915_driver_load(struct pci_dev *pde
 * becaue the HDA driver may require us to enable the audio power
 * domain during system suspend.
 */
-   pdev->dev_flags |= PCI_DEV_FLAGS_NEEDS_RESUME;
+   dev_pm_set_driver_flags(>dev, DPM_FLAG_NEVER_SKIP);
 
ret = i915_driver_init_early(dev_priv, ent);
if (ret < 0)
Index: linux-pm/drivers/misc/mei/pci-txe.c
===
--- linux-pm.orig/drivers/misc/mei/pci-txe.c
+++ linux-pm/drivers/misc/mei/pci-txe.c
@@ -141,7 +141,7 @@ static int mei_txe_probe(struct pci_dev
 * MEI requires to resume from runtime suspend mode
 * in order to perform link reset flow upon system suspend.
 */
-   pdev->dev_flags |= PCI_DEV_FLAGS_NEEDS_RESUME;
+   dev_pm_set_driver_flags(>dev, DPM_FLAG_NEVER_SKIP);
 
/*
* For not wake-able HW runtime pm framework
Index: linux-pm/drivers/misc/mei/pci-me.c
===
--- linux-pm.orig/drivers/misc/mei/pci-me.c
+++ linux-pm/drivers/misc/mei/pci-me.c
@@ -223,7 +223,7 @@ static int mei_me_probe(struct pci_dev *
 * MEI requires to resume from runtime suspend mode
 * in order to perform link reset flow upon system suspend.
 */
-   pdev->dev_flags |= PCI_DEV_FLAGS_NEEDS_RESUME;
+   dev_pm_set_driver_flags(>dev, DPM_FLAG_NEVER_SKIP);
 
/*
* For not wake-able HW runtime pm framework

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 01/12] PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

The motivation for this change is to provide a way to work around
a problem with the direct-complete mechanism used for avoiding
system suspend/resume handling for devices in runtime suspend.

The problem is that some middle layer code (the PCI bus type and
the ACPI PM domain in particular) returns positive values from its
system suspend ->prepare callbacks regardless of whether the driver's
->prepare returns a positive value or 0, which effectively prevents
drivers from being able to control the direct-complete feature.
Some drivers need that control, however, and the PCI bus type has
grown its own flag to deal with this issue, but since it is not
limited to PCI, it is better to address it by adding driver flags at
the core level.

To that end, add a driver_flags field to struct dev_pm_info for flags
that can be set by device drivers at the probe time to inform the PM
core and/or bus types, PM domains and so on on the capabilities and/or
preferences of device drivers.  Also add two static inline helpers
for setting that field and testing it against a given set of flags
and make the driver core clear it automatically on driver remove
and probe failures.

Define and document two PM driver flags related to the direct-
complete feature: NEVER_SKIP and SMART_PREPARE that can be used,
respectively, to indicate to the PM core that the direct-complete
mechanism should never be used for the device and to inform the
middle layer code (bus types, PM domains etc) that it can only
request the PM core to use the direct-complete mechanism for
the device (by returning a positive value from its ->prepare
callback) if it also has been requested by the driver.

While at it, make the core check pm_runtime_suspended() when
setting power.direct_complete so that it doesn't need to be
checked by ->prepare callbacks.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |   14 ++
 Documentation/power/pci.txt |   19 +++
 drivers/acpi/device_pm.c|3 +++
 drivers/base/dd.c   |2 ++
 drivers/base/power/main.c   |4 +++-
 drivers/pci/pci-driver.c|5 -
 include/linux/device.h  |   10 ++
 include/linux/pm.h  |   20 
 8 files changed, 75 insertions(+), 2 deletions(-)

Index: linux-pm/include/linux/device.h
===
--- linux-pm.orig/include/linux/device.h
+++ linux-pm/include/linux/device.h
@@ -1070,6 +1070,16 @@ static inline void dev_pm_syscore_device
 #endif
 }
 
+static inline void dev_pm_set_driver_flags(struct device *dev, unsigned int 
flags)
+{
+   dev->power.driver_flags = flags;
+}
+
+static inline bool dev_pm_test_driver_flags(struct device *dev, unsigned int 
flags)
+{
+   return !!(dev->power.driver_flags & flags);
+}
+
 static inline void device_lock(struct device *dev)
 {
mutex_lock(>mutex);
Index: linux-pm/include/linux/pm.h
===
--- linux-pm.orig/include/linux/pm.h
+++ linux-pm/include/linux/pm.h
@@ -550,6 +550,25 @@ struct pm_subsys_data {
 #endif
 };
 
+/*
+ * Driver flags to control system suspend/resume behavior.
+ *
+ * These flags can be set by device drivers at the probe time.  They need not 
be
+ * cleared by the drivers as the driver core will take care of that.
+ *
+ * NEVER_SKIP: Do not skip system suspend/resume callbacks for the device.
+ * SMART_PREPARE: Check the return value of the driver's ->prepare callback.
+ *
+ * Setting SMART_PREPARE instructs bus types and PM domains which may want
+ * system suspend/resume callbacks to be skipped for the device to return 0 
from
+ * their ->prepare callbacks if the driver's ->prepare callback returns 0 (in
+ * other words, the system suspend/resume callbacks can only be skipped for the
+ * device if its driver doesn't object against that).  This flag has no effect
+ * if NEVER_SKIP is set.
+ */
+#define DPM_FLAG_NEVER_SKIPBIT(0)
+#define DPM_FLAG_SMART_PREPARE BIT(1)
+
 struct dev_pm_info {
pm_message_tpower_state;
unsigned intcan_wakeup:1;
@@ -561,6 +580,7 @@ struct dev_pm_info {
boolis_late_suspended:1;
boolearly_init:1;   /* Owned by the PM core */
booldirect_complete:1;  /* Owned by the PM core 
*/
+   unsigned intdriver_flags;
spinlock_t  lock;
 #ifdef CONFIG_PM_SLEEP
struct list_headentry;
Index: linux-pm/drivers/base/dd.c
===
--- linux-pm.orig/drivers/base/dd.c
+++ linux-pm/drivers/base/dd.c
@@ -464,6 +464,7 @@ pinctrl_bind_failed:
   

[PATCH 0/12] PM / sleep: Driver flags for system suspend/resume

[Rafael J. Wysocki]

Hi All,

Well, this took more time than expected, as I tried to cover everything I had
in mind regarding PM flags for drivers.

This work was triggered by attempts to fix and optimize PM in the
i2c-designware-platdev driver that ended up with adding a couple of
flags to the driver's internal data structures for the tracking of
device state (https://marc.info/?l=linux-acpi=150629646805636=2).
That approach is sort of suboptimal, though, because other drivers will
probably want to do similar things and if all of them need to use internal
flags for that, quite a bit of code duplication may ensue at least.

That can be avoided in a couple of ways and one of them is to provide a means
for drivers to tell the core what to do and to make the core take care of it
if told to do so.  Hence, the idea to use driver flags for system-wide PM
that was briefly discussed during the LPC in LA last month.

One of the flags considered at that time was to possibly cause the core
to reuse the runtime PM callback path of a device for system suspend/resume.
Admittedly, that idea didn't look too bad to me until I had started to try to
implement it and I got to the PCI bus type's hibernation callbacks.  Then, I
moved the patch I was working on to /dev/null right away.  I mean it.

No, this is not going to happen.  No way.

Moreover, that experience made me realize that the whole *idea* of using the
runtime PM callback path for system-wide PM was actually totally bogus (sorry
Ulf).

The whole point of having different callbacks pointers for different types of
device transitions is because it may be necessary to do different things in
those callbacks in general.  Now, if you consider runtime PM and system
suspend/resume *only* and from a driver perspective, then yes, in some cases
the same pair of callback routines may be used for all suspend-like and
resume-like transitions of the device, but if you add hibernation to the mix,
then it is not so clear any more unless the callbacks don't actually do any
power management at all, but simply quiesce the device's activity and then
activate it again.  Namely, changing power states of devices during the
hibernation's "freeze" and "thaw" transitions rarely makes sense at all and
the "restore" transition needs to be able to cope with uninitialized devices
(in fact, it should be prepared to cope with devices in *any* state), so
runtime PM is hardly suitable for them.  Still, if a *driver* choses to not
do any real PM in its PM callbacks and leaves that to a middle layer (quite
a few drivers do that), then it possibly can use one pair of callbacks in all
cases and be happy, but middle layers pretty much have to use different
callback routines for different transitions.

If you are a middle layer, your role is basically to do PM for a certain
group of devices.  Thus you cannot really do the same in ->suspend or
->suspend_early and in ->runtime_suspend (because the former generally need to
take device_may_wakeup() into account and the latter doesn't) and you shouldn't
really do the same in ->suspend and ->freeze (becuase the latter shouldn't
change the device's power state) and so on.  To put it bluntly, trying
to use the ->runtime_suspend callback of a middle layer for anything other
than runtime suspend is complete and utter nonsense.  At the same time, the
->runtime_resume callback of a middle layer may be reused to some extent,
but even that doesn't cover the "thaw" transitions during hibernation.

What can work (and this is the only strategy that can work AFAICS) is to
point different callback pointers *in* *a* *driver* to the same routine
if the driver wants to reuse that code.  That actually will work for PCI
and USB drivers today, at least most of the time, but unfortunately there
are problems with it for, say, platform devices.

The first problem is the requirement to track the status of the device
(suspended vs not suspended) in the callbacks, because the system-wide PM
code in the PM core doesn't do that.  The runtime PM framework does it, so
this means adding some extra code which isn't necessary for runtime PM to
the callback routines and that is not particularly nice.

The second problem is that, if the driver wants to do anything in its
->suspend callback, it generally has to prevent runtime suspend of the
device from taking place in parallel with that, which is quite cumbersome.
Usually, that is taken care of by resuming the device from runtime suspend
upfront, but generally doing that is wasteful (there may be no real need to
resume the device except for the fact that the code is designed this way).

On top of the above, there are optimizations to be made, like leaving certain
devices in suspend after system resume to avoid wasting time on waiting for
them to resume before user space can run again and similar.

This patch series focuses on addressing those problems so as to make it
easier to reuse callback routines by pointing different callback pointers
to them in device 

[PATCH] PM / core: Fix kerneldoc comments of four functions

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Fix the kerneldoc comments of __device_suspend_noirq(),
__device_suspend_late() and __device_suspend() where the function
names in kerneldoc don't match the actual names of the functions.

Also fix the device_resume_noirq() kerneldoc comment which mentions
"early resume" instead of "noirq resume" incorrectly.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/base/power/main.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -528,7 +528,7 @@ static void dpm_watchdog_clear(struct dp
 /*- Resume routines -*/
 
 /**
- * device_resume_noirq - Execute an "early resume" callback for given device.
+ * device_resume_noirq - Execute a "noirq resume" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being resumed asynchronously.
@@ -1077,7 +1077,7 @@ static pm_message_t resume_event(pm_mess
 }
 
 /**
- * device_suspend_noirq - Execute a "late suspend" callback for given device.
+ * __device_suspend_noirq - Execute a "noirq suspend" callback for given 
device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.
@@ -1237,7 +1237,7 @@ int dpm_suspend_noirq(pm_message_t state
 }
 
 /**
- * device_suspend_late - Execute a "late suspend" callback for given device.
+ * __device_suspend_late - Execute a "late suspend" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.
@@ -1439,7 +1439,7 @@ static void dpm_clear_suppliers_direct_c
 }
 
 /**
- * device_suspend - Execute "suspend" callbacks for given device.
+ * __device_suspend - Execute "suspend" callbacks for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PM / core: Fix kerneldoc comments of three functions

[Rafael J. Wysocki]

On Friday, October 13, 2017 8:48:30 AM CEST Ulf Hansson wrote:
> On 13 October 2017 at 02:33, Rafael J. Wysocki <r...@rjwysocki.net> wrote:
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> >
> > Fix kerneldoc comments of __device_suspend_noirq(),
> > __device_suspend_late() and __device_suspend() where the function
> > names in kerneldoc don't match the actual names of the functions.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > ---
> >  drivers/base/power/main.c |6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Index: linux-pm/drivers/base/power/main.c
> > ===
> > --- linux-pm.orig/drivers/base/power/main.c
> > +++ linux-pm/drivers/base/power/main.c
> > @@ -1077,7 +1077,7 @@ static pm_message_t resume_event(pm_mess
> >  }
> >
> >  /**
> > - * device_suspend_noirq - Execute a "late suspend" callback for given 
> > device.
> > + * __device_suspend_noirq - Execute a "late suspend" callback for given 
> > device.
> 
> While at it, I suggest to also change "late suspend" to "noirq suspend".
> 
> As a matter of fact I found the similar text to be wrong also for
> device_resume_noirq(), perhaps that should be fixed as well.

Right, I will do that.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PM / core: Fix kerneldoc comments of three functions

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Fix kerneldoc comments of __device_suspend_noirq(),
__device_suspend_late() and __device_suspend() where the function
names in kerneldoc don't match the actual names of the functions.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 drivers/base/power/main.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/base/power/main.c
===
--- linux-pm.orig/drivers/base/power/main.c
+++ linux-pm/drivers/base/power/main.c
@@ -1077,7 +1077,7 @@ static pm_message_t resume_event(pm_mess
 }
 
 /**
- * device_suspend_noirq - Execute a "late suspend" callback for given device.
+ * __device_suspend_noirq - Execute a "late suspend" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.
@@ -1237,7 +1237,7 @@ int dpm_suspend_noirq(pm_message_t state
 }
 
 /**
- * device_suspend_late - Execute a "late suspend" callback for given device.
+ * __device_suspend_late - Execute a "late suspend" callback for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.
@@ -1439,7 +1439,7 @@ static void dpm_clear_suppliers_direct_c
 }
 
 /**
- * device_suspend - Execute "suspend" callbacks for given device.
+ * __device_suspend - Execute "suspend" callbacks for given device.
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  * @async: If true, the device is being suspended asynchronously.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/8] Documentation: fix ref to power basic-pm-debugging

[Rafael J. Wysocki]

On Thu, Oct 12, 2017 at 10:24 PM, Tom Saeger <tom.sae...@oracle.com> wrote:
> Signed-off-by: Tom Saeger <tom.sae...@oracle.com>
> ---
>  Documentation/power/interface.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/power/interface.txt 
> b/Documentation/power/interface.txt
> index 7dc75f48e8bd..27df7f98668a 100644
> --- a/Documentation/power/interface.txt
> +++ b/Documentation/power/interface.txt
> @@ -43,7 +43,7 @@ The currently selected option is printed in square brackets.
>  The 'platform' option is only available if the platform provides a special
>  mechanism to put the system to sleep after creating a hibernation image (ACPI
>  does that, for example).  The 'suspend' option is available if Suspend-to-RAM
> -is supported.  Refer to Documentation/power/basic_pm_debugging.txt for the
> +is supported.  Refer to Documentation/power/basic-pm-debugging.txt for the
>  description of the 'test_resume' option.
>
>  To select an option, write the string representing it to /sys/power/disk.
> --

Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] Documentation: fix admin-guide doc refs

[Rafael J. Wysocki]

On Tue, Oct 10, 2017 at 7:36 PM, Tom Saeger <tom.sae...@oracle.com> wrote:
> Make admin-guide document refs valid.
>
> Signed-off-by: Tom Saeger <tom.sae...@oracle.com>

Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

> ---
>  Documentation/ABI/stable/sysfs-devices | 2 +-
>  Documentation/ABI/testing/sysfs-devices-system-cpu | 6 --
>  Documentation/ABI/testing/sysfs-power  | 6 --
>  Documentation/admin-guide/README.rst   | 2 +-
>  Documentation/admin-guide/kernel-parameters.txt| 4 ++--
>  Documentation/admin-guide/reporting-bugs.rst   | 4 ++--
>  Documentation/laptops/laptop-mode.txt  | 6 +++---
>  Documentation/media/v4l-drivers/bttv.rst   | 2 +-
>  Documentation/power/interface.txt  | 3 ++-
>  9 files changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/Documentation/ABI/stable/sysfs-devices 
> b/Documentation/ABI/stable/sysfs-devices
> index 35c457f8ce73..4404bd9b96c1 100644
> --- a/Documentation/ABI/stable/sysfs-devices
> +++ b/Documentation/ABI/stable/sysfs-devices
> @@ -1,5 +1,5 @@
>  # Note: This documents additional properties of any device beyond what
> -# is documented in Documentation/sysfs-rules.txt
> +# is documented in Documentation/admin-guide/sysfs-rules.rst
>
>  What:  /sys/devices/*/of_node
>  Date:  February 2015
> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu 
> b/Documentation/ABI/testing/sysfs-devices-system-cpu
> index f3d5817c4ef0..d6d862db3b5d 100644
> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
> @@ -187,7 +187,8 @@ Description:Processor frequency boosting control
> This switch controls the boost setting for the whole system.
> Boosting allows the CPU and the firmware to run at a frequency
> beyound it's nominal limit.
> -   More details can be found in Documentation/cpu-freq/boost.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/cpufreq.rst
>
>
>  What:  /sys/devices/system/cpu/cpu#/crash_notes
> @@ -223,7 +224,8 @@ Description:Parameters for the Intel P-state 
> driver
> no_turbo: limits the driver to selecting P states below the 
> turbo
> frequency range.
>
> -   More details can be found in 
> Documentation/cpu-freq/intel-pstate.txt
> +   More details can be found in
> +   Documentation/admin-guide/pm/intel_pstate.rst
>
>  What:  
> /sys/devices/system/cpu/cpu*/cache/index*/
>  Date:  July 2014(documented, existed before August 2008)
> diff --git a/Documentation/ABI/testing/sysfs-power 
> b/Documentation/ABI/testing/sysfs-power
> index a1d1612f3651..1e0d1dac706b 100644
> --- a/Documentation/ABI/testing/sysfs-power
> +++ b/Documentation/ABI/testing/sysfs-power
> @@ -18,7 +18,8 @@ Description:
> Writing one of the above strings to this file causes the 
> system
> to transition into the corresponding state, if available.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/mem_sleep
>  Date:  November 2016
> @@ -35,7 +36,8 @@ Description:
> represented by it to be used on subsequent attempts to suspend
> the system.
>
> -   See Documentation/power/states.txt for more information.
> +   See Documentation/admin-guide/pm/sleep-states.rst for more
> +   information.
>
>  What:  /sys/power/disk
>  Date:  September 2006
> diff --git a/Documentation/admin-guide/README.rst 
> b/Documentation/admin-guide/README.rst
> index b5343c5aa224..63066db39910 100644
> --- a/Documentation/admin-guide/README.rst
> +++ b/Documentation/admin-guide/README.rst
> @@ -350,7 +350,7 @@ If something goes wrong
> help debugging the problem.  The text above the dump is also
> important: it tells something about why the kernel dumped code (in
> the above example, it's due to a bad kernel pointer). More information
> -   on making sense of the dump is in 
> Documentation/admin-guide/oops-tracing.rst
> +   on making sense of the dump is in 
> Documentation/admin-guide/bug-hunting.rst
>
>   - If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
> as is, otherwise you will have to use the ``ksymoops`` program to make
> diff --git a/Documentation/a

Re: [PATCH 1/8] Documentation: fix driver-api doc refs

[Rafael J. Wysocki]

On Tue, Oct 10, 2017 at 7:36 PM, Tom Saeger <tom.sae...@oracle.com> wrote:
> Make driver-api document refs valid.
>
> Signed-off-by: Tom Saeger <tom.sae...@oracle.com>

Acked-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

> ---
>  Documentation/power/pci.txt  | 10 +-
>  Documentation/power/runtime_pm.txt   |  2 +-
>  Documentation/process/submitting-drivers.rst |  2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt
> index a1b7f7158930..d17fdf8f45ef 100644
> --- a/Documentation/power/pci.txt
> +++ b/Documentation/power/pci.txt
> @@ -8,7 +8,7 @@ management.  Based on previous work by Patrick Mochel 
> <moc...@transmeta.com>
>
>  This document only covers the aspects of power management specific to PCI
>  devices.  For general description of the kernel's interfaces related to 
> device
> -power management refer to Documentation/power/admin-guide/devices.rst and
> +power management refer to Documentation/driver-api/pm/devices.rst and
>  Documentation/power/runtime_pm.txt.
>
>  ---
> @@ -417,7 +417,7 @@ pm->runtime_idle() callback.
>  2.4. System-Wide Power Transitions
>  --
>  There are a few different types of system-wide power transitions, described 
> in
> -Documentation/power/admin-guide/devices.rst.  Each of them requires devices 
> to be handled
> +Documentation/driver-api/pm/devices.rst.  Each of them requires devices to 
> be handled
>  in a specific way and the PM core executes subsystem-level power management
>  callbacks for this purpose.  They are executed in phases such that each phase
>  involves executing the same subsystem-level callback for every device 
> belonging
> @@ -623,7 +623,7 @@ System restore requires a hibernation image to be loaded 
> into memory and the
>  pre-hibernation memory contents to be restored before the pre-hibernation 
> system
>  activity can be resumed.
>
> -As described in Documentation/power/admin-guide/devices.rst, the hibernation 
> image is loaded
> +As described in Documentation/driver-api/pm/devices.rst, the hibernation 
> image is loaded
>  into memory by a fresh instance of the kernel, called the boot kernel, which 
> in
>  turn is loaded and run by a boot loader in the usual way.  After the boot 
> kernel
>  has loaded the image, it needs to replace its own code and data with the code
> @@ -677,7 +677,7 @@ controlling the runtime power management of their devices.
>
>  At the time of this writing there are two ways to define power management
>  callbacks for a PCI device driver, the recommended one, based on using a
> -dev_pm_ops structure described in 
> Documentation/power/admin-guide/devices.rst, and the
> +dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, 
> and the
>  "legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and
>  .resume() callbacks from struct pci_driver are used.  The legacy approach,
>  however, doesn't allow one to define runtime power management callbacks and 
> is
> @@ -1046,5 +1046,5 @@ PCI Local Bus Specification, Rev. 3.0
>  PCI Bus Power Management Interface Specification, Rev. 1.2
>  Advanced Configuration and Power Interface (ACPI) Specification, Rev. 3.0b
>  PCI Express Base Specification, Rev. 2.0
> -Documentation/power/admin-guide/devices.rst
> +Documentation/driver-api/pm/devices.rst
>  Documentation/power/runtime_pm.txt
> diff --git a/Documentation/power/runtime_pm.txt 
> b/Documentation/power/runtime_pm.txt
> index 625549d4c74a..57af2f7963ee 100644
> --- a/Documentation/power/runtime_pm.txt
> +++ b/Documentation/power/runtime_pm.txt
> @@ -680,7 +680,7 @@ left in runtime suspend.  If that happens, the PM core 
> will not execute any
>  system suspend and resume callbacks for all of those devices, except for the
>  complete callback, which is then entirely responsible for handling the device
>  as appropriate.  This only applies to system suspend transitions that are not
> -related to hibernation (see Documentation/power/admin-guide/devices.rst for 
> more
> +related to hibernation (see Documentation/driver-api/pm/devices.rst for more
>  information).
>
>  The PM core does its best to reduce the probability of race conditions 
> between
> diff --git a/Documentation/process/submitting-drivers.rst 
> b/Documentation/process/submitting-drivers.rst
> index afb82ee0cbea..b38bf2054ce3 100644
> --- a/Documentation/process/submitting-drivers.rst
> +++ b/Documentation/process/submitting-drivers.rst
> @@ -117,7 +117,7 @@ PM support:
>

[PATCH] PM: docs: Fix stale reference in kernel-parameters.txt

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Commit 7aa7a0360a66 (PM: docs: Delete the obsolete states.txt
document) forgot to update kernel-parameters.txt with a reference
to the new sleep-states.rst document and it still points to
states.txt that was dropped, so fix it now.

Fixes: 7aa7a0360a66 (PM: docs: Delete the obsolete states.txt document)
Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/admin-guide/kernel-parameters.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/Documentation/admin-guide/kernel-parameters.txt
===
--- linux-pm.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-pm/Documentation/admin-guide/kernel-parameters.txt
@@ -2248,7 +2248,7 @@
s2idle  - Suspend-To-Idle
shallow - Power-On Suspend or equivalent (if supported)
deep- Suspend-To-RAM or equivalent (if supported)
-   See Documentation/power/states.txt.
+   See Documentation/admin-guide/pm/sleep-states.rst.
 
meye.*= [HW] Set MotionEye Camera parameters
See Documentation/video4linux/meye.txt.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cpufreq: docs: Drop intel_pstate.txt from index.txt

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Commit 33fc30b47098 (cpufreq: intel_pstate: Document the current
behavior and user interface) dropped the intel-pstate.txt file
from Documentation/cpu-freq/, but it did not update the index.txt
file in there accordingly, so do that now.

Fixes: 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and 
user interface)
Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/cpu-freq/index.txt |2 --
 1 file changed, 2 deletions(-)

Index: linux-pm/Documentation/cpu-freq/index.txt
===
--- linux-pm.orig/Documentation/cpu-freq/index.txt
+++ linux-pm/Documentation/cpu-freq/index.txt
@@ -32,8 +32,6 @@ cpufreq-stats.txt -   General description
 
 index.txt  -   File index, Mailing list and Links (this document)
 
-intel-pstate.txt - Intel pstate cpufreq driver specific file.
-
 pcc-cpufreq.txt -  PCC cpufreq driver specific file.
 
 

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] PM: docs: Drop an excess character from devices.rst

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Drop an excess "`" from Documentation/driver-api/pm/devices.rst.

Fixes: 2728b2d2e5be (PM / core / docs: Convert sleep states API document to 
reST)
Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/driver-api/pm/devices.rst |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-pm/Documentation/driver-api/pm/devices.rst
===
--- linux-pm.orig/Documentation/driver-api/pm/devices.rst
+++ linux-pm/Documentation/driver-api/pm/devices.rst
@@ -675,7 +675,7 @@ sub-domain of the parent domain.
 
 Support for power domains is provided through the :c:member:`pm_domain` field 
of
 |struct device|.  This field is a pointer to an object of type
-|struct dev_pm_domain|, defined in :file:`include/linux/pm.h``, providing a set
+|struct dev_pm_domain|, defined in :file:`include/linux/pm.h`, providing a set
 of power management callbacks analogous to the subsystem-level and device 
driver
 callbacks that are executed for the given device during all power transitions,
 instead of the respective subsystem-level callbacks.  Specifically, if a

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] PM: docs: Describe high-level PM strategies and sleep states

[Rafael J. Wysocki]

On Monday, August 21, 2017 3:14:56 PM CEST Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> 
> Reorganize the power management part of admin-guide by adding a
> description of major power management strategies supported by the
> kernel (system-wide and working-state power management) to it and
> dividing the rest of the material into the system-wide PM and
> working-state PM chapters.
> 
> On top of that, add a description of system sleep states to the
> system-wide PM chapter.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> Reviewed-by: Lukas Wunner <lu...@wunner.de>
> ---
> 
> -> v2:
>  - Changed the wording in the strategies.rst document slightly
>to address Lukas' comments.
>  - Changed refs in the sleep-states.rst document to address
>Markus' comments.
>  - Followed Markus' suggestion to drop C 'only' blocks in a few
>places.
>  - Added Reviewed-by from Lukas as the changes to the content are
>very small.
> 

I haven't seen any more comments on this which I'm taking as the lack of
objections, so I'm going to queue it up for 4.14.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/2] PM: docs: Describe high-level PM strategies and sleep states

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Reorganize the power management part of admin-guide by adding a
description of major power management strategies supported by the
kernel (system-wide and working-state power management) to it and
dividing the rest of the material into the system-wide PM and
working-state PM chapters.

On top of that, add a description of system sleep states to the
system-wide PM chapter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
Reviewed-by: Lukas Wunner <lu...@wunner.de>
---

-> v2:
 - Changed the wording in the strategies.rst document slightly
   to address Lukas' comments.
 - Changed refs in the sleep-states.rst document to address
   Markus' comments.
 - Followed Markus' suggestion to drop C 'only' blocks in a few
   places.
 - Added Reviewed-by from Lukas as the changes to the content are
   very small.

---
 Documentation/admin-guide/pm/index.rst |   12 -
 Documentation/admin-guide/pm/sleep-states.rst  |  245 +
 Documentation/admin-guide/pm/strategies.rst|   52 +
 Documentation/admin-guide/pm/system-wide.rst   |8 
 Documentation/admin-guide/pm/working-state.rst |9 
 5 files changed, 317 insertions(+), 9 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/index.rst
===
--- linux-pm.orig/Documentation/admin-guide/pm/index.rst
+++ linux-pm/Documentation/admin-guide/pm/index.rst
@@ -5,12 +5,6 @@ Power Management
 .. toctree::
:maxdepth: 2
 
-   cpufreq
-   intel_pstate
-
-.. only::  subproject and html
-
-   Indices
-   ===
-
-   * :ref:`genindex`
+   strategies
+   system-wide
+   working-state
Index: linux-pm/Documentation/admin-guide/pm/sleep-states.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/sleep-states.rst
@@ -0,0 +1,245 @@
+===
+System Sleep States
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wyso...@intel.com>
+
+Sleep states are global low-power states of the entire system in which user
+space code cannot be executed and the overall system activity is significantly
+reduced.
+
+
+Sleep States That Can Be Supported
+==
+
+Depending on its configuration and the capabilities of the platform it runs on,
+the Linux kernel can support up to four system sleep states, includig
+hibernation and up to three variants of system suspend.  The sleep states that
+can be supported by the kernel are listed below.
+
+.. _s2idle:
+
+Suspend-to-Idle
+---
+
+This is a generic, pure software, light-weight variant of system suspend (also
+referred to as S2I or S2Idle).  It allows more energy to be saved relative to
+runtime idle by freezing user space, suspending the timekeeping and putting all
+I/O devices into low-power states (possibly lower-power than available in the
+working state), such that the processors can spend time in their deepest idle
+states while the system is suspended.
+
+The system is woken up from this state by in-band interrupts, so theoretically
+any devices that can cause interrupts to be generated in the working state can
+also be set up as wakeup devices for S2Idle.
+
+This state can be used on platforms without support for :ref:`standby 
`
+or :ref:`suspend-to-RAM `, or it can be used in addition to any of the
+deeper system suspend variants to provide reduced resume latency.  It is always
+supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set.
+
+.. _standby:
+
+Standby
+---
+
+This state, if supported, offers moderate, but real, energy savings, while
+providing a relatively straightforward transition back to the working state.  
No
+operating state is lost (the system core logic retains power), so the system 
can
+go back to where it left off easily enough.
+
+In addition to freezing user space, suspending the timekeeping and putting all
+I/O devices into low-power states, which is done for :ref:`suspend-to-idle
+` too, nonboot CPUs are taken offline and all low-level system 
functions
+are suspended during transitions into this state.  For this reason, it should
+allow more energy to be saved relative to :ref:`suspend-to-idle `, but
+the resume latency will generally be greater than for that state.
+
+The set of devices that can wake up the system from this state usually is
+reduced relative to :ref:`suspend-to-idle ` and it may be necessary to
+rely on the platform for setting up the wakeup functionality as appropriate.
+
+This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration
+option is set and the support for it is registered by the platform with the
+core system suspend subsystem.  On ACPI-based systems this state is mapped to
+the S1 system state defined by ACPI.
+
+.. _s2ram:
+
+Suspend-to-RAM
+--
+
+This state (also 

Re: [PATCH 2/2] PM: docs: Delete the obsolete states.txt document

[Rafael J. Wysocki]

On Monday, August 21, 2017 9:39:17 AM CEST Markus Heiser wrote:
> 
> > Am 20.08.2017 um 18:06 schrieb Rafael J. Wysocki <r...@rjwysocki.net>:
> > 
> > From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > 
> > The Documentation/power/states.txt document is now redundant and
> > sonewhat outdated, so delete it.
> > 
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
> > ---
> > Documentation/power/states.txt |  127 
> > -
> > 1 file changed, 127 deletions(-)
> 
> strange, I tried to apply the series, 1/2 applied but with 2/2 I get a 
> "sha1 information is lacking or useless", did I miss something?

You need to apply this on top of linux-next, as some changes are made to
states.txt in one of the pending PM commits.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states

[Rafael J. Wysocki]

On Mon, Aug 21, 2017 at 11:51 AM, Markus Heiser
<markus.hei...@darmarit.de> wrote:
> Hi Rafael,
>
> great work, helps me and the world saving fossil fuels ;)

Thanks!

>> Am 20.08.2017 um 18:05 schrieb Rafael J. Wysocki <r...@rjwysocki.net>:
>>
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Reorganize the power management part of admin-guide by adding a
>> description of major power management strategies supported by the
>> kernel (system-wide and working-state power management) to it and
>> dividing the rest of the material into the system-wide PM and
>> working-state PM chapters.
>>
>> On top of that, add a description of system sleep states to the
>> system-wide PM chapter.
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>> ---
>> Documentation/admin-guide/pm/index.rst |5
>> Documentation/admin-guide/pm/sleep-states.rst  |  234 
>> +
>> Documentation/admin-guide/pm/strategies.rst|   52 +
>> Documentation/admin-guide/pm/system-wide.rst   |   15 +
>> Documentation/admin-guide/pm/working-state.rst |   16 +
>> 5 files changed, 320 insertions(+), 2 deletions(-)
>>
>> Index: linux-pm/Documentation/admin-guide/pm/index.rst
>> ===
>> --- linux-pm.orig/Documentation/admin-guide/pm/index.rst
>> +++ linux-pm/Documentation/admin-guide/pm/index.rst
>> @@ -5,8 +5,9 @@ Power Management
>> .. toctree::
>>:maxdepth: 2
>>
>> -   cpufreq
>> -   intel_pstate
>> +   strategies
>> +   system-wide
>> +   working-state
>>
>> .. only::  subproject and html
>
> BTW: lets drop this C 'only' block here. Subprojects are only where a
> Documentation/*/conf.py exists. The build does not have sub-sub-projects
> at Documentation/*/*/conf.py level.

OK

[cut]

>
>> Index: linux-pm/Documentation/admin-guide/pm/strategies.rst
>> ===============
>> --- /dev/null
>> +++ linux-pm/Documentation/admin-guide/pm/strategies.rst
>> @@ -0,0 +1,52 @@
>> +===
>> +Power Management Strategies
>> +===
>> +
>> +::
>> +
>> + Copyright (c) 2017 Intel Corp., Rafael J. Wysocki 
>> <rafael.j.wyso...@intel.com>
>> +
>> +The Linux kernel supports two major high-level power management strategies.
>> +
>> +One of them is based on using global low-power states of the whole system in
>> +which user space code cannot be executed and the overall system activity is
>> +significantly reduced, referred to as :doc:`sleep states `.  
>> The
>> +kernel puts the system into one of these states when requested by user space
>> +and the system stays in it until a special signal is received from one of
>> +designated devices, triggering a transition to the ``working state`` in 
>> which
>> +user space code can run.  Because sleep states are global and the whole 
>> system
>> +is affected by the state changes, this strategy is referred to as the
>> +:doc:`system-wide power management `.
>
> I really appreciate your hyper-ref markup using :doc:`Foo ` and `Bar`_
> it is very clear when reading the raw text files in the source tree. I think
> this has its value, but it also has its drawbacks when chapters are renamed
> or moved from one file to another. Thats, why I recommend using explicitly
> anchors / may be the maintainer Jon can give us his assessment. What I mean::
>
> .. _foo:
>
> Foo
> ===
>
> lorem see :ref:`bar`
>
> .. _bar:
>
> Bar
> ===
>
> ipsum see :ref:`foo`
>
> With explicitly anchors:
>
> - there is no need to track when a chapter is renamed
> - or moved to another file,
> - same to renaming files
> - with intersphinx [1] other projects can link to such anchors
>
> [1] http://www.sphinx-doc.org/en/stable/ext/intersphinx.html

OK, makes sense.

>> +
>> +The other strategy, referred to as the
>> +:doc:`working-state power management `,
>
> Even if you use :ref: or :doc: both are line-break-safe ...
>
> +The other strategy, referred to as the :doc:`working-state power
> +management `, ...
>
> .. should work.

I works.

I'll send a v2 with the above changes shortly

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states

[Rafael J. Wysocki]

On Sun, Aug 20, 2017 at 8:23 PM, Lukas Wunner <lu...@wunner.de> wrote:
> On Sun, Aug 20, 2017 at 06:05:05PM +0200, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
>>
>> Reorganize the power management part of admin-guide by adding a
>> description of major power management strategies supported by the
>> kernel (system-wide and working-state power management) to it and
>> dividing the rest of the material into the system-wide PM and
>> working-state PM chapters.
>>
>> On top of that, add a description of system sleep states to the
>> system-wide PM chapter.
>
> Found no typos and no factual inaccuracies, the only thing that
> irritated me a bit was the part about "working state" power
> management:
>
>> +The other strategy, referred to as the
>> +:doc:`working-state power management `, is based on 
>> adjusting the
>> +power states of individual hardware components of the system, as needed, in 
>> the
>> +working state.  In consequence, if this strategy is in use, the working 
>> state
>> +of the system usually does not correspond to any particular physical
>> +configuration of it, but can be treated as a metastate covering a range of
>> +different power states of the system in which the individual components of 
>> it
>> +can be either ``active`` (in use) or ``inactive`` (idle).  If they are 
>> active,
>> +they have to be in power states allowing them to process data and to be 
>> accessed
>> +by software.  In turn, if they are inactive, they are expected to be in
>> +low-power states in which they may not be accessible.
>> +
>> +If all of the system components are active, the system as a whole is 
>> regarded as
>> +``runtime active`` and that situation typically corresponds to the maximum 
>> power
>> +draw (or maximum energy usage) of it.  If all of them are inactive, the 
>> system
>> +as a whole is regarded as ``runtime idle`` which may be very close to a 
>> sleep
>
> The code uses the terms pm_runtime_active() and pm_runtime_suspended(),
> not "runtime idle".

Well, the phrase "runtime idle" in the document is (quite clearly)
used with respect to the system as a whole, so I'm not sure how this
is related to the runtime PM framework.

> Taking the ->runtime_idle callback as guidance,
> "runtime idle" would mean that a component is runtime active, but idling

Well, no.  At least that wasn't the intention and now it turns out to
be confusing ...

->runtime_idle is for cases when the device looks idle to a piece of
the kernel code and then it can use this callback to request the
devices driver/bus type and so on to take care of this situation.

Also the prefix "runtime" is there to distinguish the callback from
the other callbacks, related to system suspend and hibernation, in the
same data type.

And, of course, "suspended" implies "idle", but not the other way
around, in general.

> and could thus be transitioned to runtime suspended state.  However above
> it says that if it's idle, it's already "in low-power states and may
> not be accessible".

No, it doesn't say that.  It talks about expectations which may not be
what actually happens.

> For someone reading this it may be difficult to
> reconcile it with the terminology used in the code.

Anyway, the point here is to note the difference between sleep states
and a completely idle system in the working state.

>
> Otherwise,
> Reviewed-by: Lukas Wunner <lu...@wunner.de>

Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] PM: docs: Describe high-level PM strategies and sleep states

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wyso...@intel.com>

Reorganize the power management part of admin-guide by adding a
description of major power management strategies supported by the
kernel (system-wide and working-state power management) to it and
dividing the rest of the material into the system-wide PM and
working-state PM chapters.

On top of that, add a description of system sleep states to the
system-wide PM chapter.

Signed-off-by: Rafael J. Wysocki <rafael.j.wyso...@intel.com>
---
 Documentation/admin-guide/pm/index.rst |5 
 Documentation/admin-guide/pm/sleep-states.rst  |  234 +
 Documentation/admin-guide/pm/strategies.rst|   52 +
 Documentation/admin-guide/pm/system-wide.rst   |   15 +
 Documentation/admin-guide/pm/working-state.rst |   16 +
 5 files changed, 320 insertions(+), 2 deletions(-)

Index: linux-pm/Documentation/admin-guide/pm/index.rst
===
--- linux-pm.orig/Documentation/admin-guide/pm/index.rst
+++ linux-pm/Documentation/admin-guide/pm/index.rst
@@ -5,8 +5,9 @@ Power Management
 .. toctree::
:maxdepth: 2
 
-   cpufreq
-   intel_pstate
+   strategies
+   system-wide
+   working-state
 
 .. only::  subproject and html
 
Index: linux-pm/Documentation/admin-guide/pm/sleep-states.rst
===
--- /dev/null
+++ linux-pm/Documentation/admin-guide/pm/sleep-states.rst
@@ -0,0 +1,234 @@
+===
+System Sleep States
+===
+
+::
+
+ Copyright (c) 2017 Intel Corp., Rafael J. Wysocki <rafael.j.wyso...@intel.com>
+
+Sleep states are global low-power states of the entire system in which user
+space code cannot be executed and the overall system activity is significantly
+reduced.
+
+
+Sleep States That Can Be Supported
+==
+
+Depending on its configuration and the capabilities of the platform it runs on,
+the Linux kernel can support up to four system sleep states, includig
+hibernation and up to three variants of system suspend.  The sleep states that
+can be supported by the kernel are listed below.
+
+Suspend-to-Idle
+---
+
+This is a generic, pure software, light-weight variant of system suspend (also
+referred to as S2I or S2Idle).  It allows more energy to be saved relative to
+runtime idle by freezing user space, suspending the timekeeping and putting all
+I/O devices into low-power states (possibly lower-power than available in the
+working state), such that the processors can spend time in their deepest idle
+states while the system is suspended.
+
+The system is woken up from this state by in-band interrupts, so theoretically
+any devices that can cause interrupts to be generated in the working state can
+also be set up as wakeup devices for S2Idle.
+
+This state can be used on platforms without support for `Standby`_ or
+`Suspend-to-RAM`_, or it can be used in addition to any of the deeper system
+suspend variants to provide reduced resume latency.  It is always supported if
+the :c:macro:`CONFIG_SUSPEND` kernel configuration option is set.
+
+Standby
+---
+
+This state, if supported, offers moderate, but real, energy savings, while
+providing a relatively straightforward transition back to the working state.  
No
+operating state is lost (the system core logic retains power), so the system 
can
+go back to where it left off easily enough.
+
+In addition to freezing user space, suspending the timekeeping and putting all
+I/O devices into low-power states, which is done for `Suspend-to-Idle`_ too,
+nonboot CPUs are taken offline and all low-level system functions are suspended
+during transitions into this state.  For this reason, it should allow more
+energy to be saved relative to `Suspend-to-Idle`_, but the resume latency will
+generally be greater than for that state.
+
+The set of devices that can wake up the system from this state usually is
+reduced relative to `Suspend-to-Idle`_ and it may be necessary to rely on the
+platform for setting up the wakeup functionality as appropriate.
+
+This state is supported if the :c:macro:`CONFIG_SUSPEND` kernel configuration
+option is set and the support for it is registered by the platform with the
+core system suspend subsystem.  On ACPI-based systems this state is mapped to
+the S1 system state defined by ACPI.
+
+Suspend-to-RAM
+--
+
+This state (also referred to as STR or S2RAM), if supported, offers significant
+energy savings as everything in the system is put into a low-power state, 
except
+for memory, which should be placed into the self-refresh mode to retain its
+contents.  All of the steps carried out when entering `Standby`_ are also
+carried out during transitions to S2RAM.  Additional operations may take place
+depending on the platform capabilities.  In particular, on ACPI-based systems
+the kernel passes control to the platform firmware (BIOS) as the

Re: [PATCH V3 0/9] cpufreq: transition-latency cleanups

[Rafael J. Wysocki]

On Wednesday, July 19, 2017 03:42:40 PM Viresh Kumar wrote:
> Hi Rafael,
> 
> This series tries to cleanup the code around transition-latency and its
> users. Some of the old legacy code, which may not make much sense now,
> is dropped as well. And some code consolidation is also done across
> governors.
> 
> Based of: v4.13-rc1
> Tested on: ARM64 Hikey board.

>From the first quick look this version is fine by me.

Unless I find anything of concern later, this will be queued up for 4.14.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] Power management updates for v4.12-rc3

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.12-rc3

with top-most commit bb47e964175e5fb4c163066e4373fac055fe5da0

 Merge branches 'pm-sleep' and 'powercap'

on top of commit 08332893e37af6ae779367e78e444f8f9571511d

 Linux 4.12-rc2

to receive power management updates for v4.12-rc3.

These fix RTC wakeup from suspend-to-idle broken recently, fix CPU
idleness detection condition in the schedutil cpufreq governor, fix
a cpufreq driver build failure, fix an error code path in the power
capping framework, clean up the hibernate core and update the
intel_pstate documentation.

Specifics:

 - Fix RTC wakeup from suspend-to-idle broken by the recent rework
   of ACPI wakeup handling (Rafael Wysocki).

 - Update intel_pstate driver documentation to reflect the current
   code and explain how it works in more detail (Rafael Wysocki).

   That had dependencies in both the PM and documentation trees
   which all have been merged now.

 - Fix an issue related to CPU idleness detection on systems with
   shared cpufreq policies in the schedutil governor (Juri Lelli).

 - Fix a possible build issue in the dbx500 cpufreq driver (Arnd
   Bergmann).

 - Fix a function in the power capping framework core to return
   an error code instead of 0 when there's an error (Dan Carpenter).

 - Clean up variable definition in the hibernation core (Pushkar
   Jambhlekar).

Thanks!


---

Arnd Bergmann (1):
  cpufreq: dbx500: add a Kconfig symbol

Dan Carpenter (1):
  PowerCap: Fix an error code in powercap_register_zone()

Juri Lelli (1):
  cpufreq: schedutil: use now as reference when aggregating shared
policy requests

Pushkar Jambhlekar (1):
  PM / hibernate: Declare variables as static

Rafael J. Wysocki (3):
  cpufreq: intel_pstate: Document the current behavior and user interface
  PM / wakeup: Fix up wakeup_source_report_event()
  RTC: rtc-cmos: Fix wakeup from suspend-to-idle

---

 Documentation/admin-guide/pm/cpufreq.rst  |  19 +-
 Documentation/admin-guide/pm/index.rst|   1 +
 Documentation/admin-guide/pm/intel_pstate.rst | 755 ++
 Documentation/cpu-freq/intel-pstate.txt   | 281 --
 drivers/base/power/wakeup.c   |  11 +-
 drivers/cpufreq/Kconfig.arm   |   9 +
 drivers/cpufreq/Makefile  |   2 +-
 drivers/powercap/powercap_sys.c   |   1 +
 drivers/rtc/rtc-cmos.c|   2 +-
 kernel/power/snapshot.c   |   2 +-
 kernel/sched/cpufreq_schedutil.c  |   7 +-
 11 files changed, 787 insertions(+), 303 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html