From: Ulf Hansson <ulf.hansson@linaro.org>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Wolfram Sang <wsa@the-dreams.de>, Len Brown <lenb@kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Kevin Hilman <khilman@kernel.org>,
Jarkko Nikula <jarkko.nikula@linux.intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Jisheng Zhang <jszhang@marvell.com>,
John Stultz <john.stultz@linaro.org>,
Guodong Xu <guodong.xu@linaro.org>,
Sumit Semwal <sumit.semwal@linaro.org>,
Haojian Zhuang <haojian.zhuang@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 1/3] PM / core: Add SAFE_SUSPEND driver flag
Date: Tue, 29 Aug 2017 16:57:28 +0200 [thread overview]
Message-ID: <CAPDyKFrYd4ViFfouM8wd7xkg2L9B0neHt7kTOxLqcGtqBFun5A@mail.gmail.com> (raw)
In-Reply-To: <35841101.LqGbCjJMGH@aspire.rjw.lan>
On 29 August 2017 at 02:20, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> 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. It is anticipated that more than one
> flag of this kind will be necessary going forward.
>
> Define and document a SAFE_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.
This changelog is a bit too vague to me. Wouldn't it be more clear if
also adding something along the lines that this also means that
runtime resuming a device isn't needed by the subsystem/PM domain
during system sleep? Because ideally that is what you want to avoid,
right?
Moreover I am also not convinced that this solution really is the
right path. It seems like we might end up adding more bits for the
"driver_flag" field and it gets complicated. Do we really need to
distinguish between all different cases in such detail?
I will continue to review this tomorrow, however in the meantime I
have finalized a re-spin of my v3 series so I decided to post it
anyway. I am adding only one new flag to the PM core, perhaps I am
over-simplifying things, but please have look once more. I think I
have addressed all your concerns you have raised so far.
Kind regards
Uffe
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> Documentation/driver-api/pm/devices.rst | 7 +++++++
> drivers/base/dd.c | 2 ++
> include/linux/pm.h | 16 ++++++++++++++++
> 3 files changed, 25 insertions(+)
>
> Index: linux-pm/include/linux/pm.h
> ===================================================================
> --- linux-pm.orig/include/linux/pm.h
> +++ linux-pm/include/linux/pm.h
> @@ -550,6 +550,21 @@ 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.
> + *
> + * SAFE_SUSPEND: No need to runtime resume the device during system suspend.
> + *
> + * Setting SAFE_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, because the system suspend callbacks
> + * provided by it can cope with a runtime suspended device.
> + */
> +#define DPM_FLAG_SAFE_SUSPEND BIT(0)
> +
> struct dev_pm_info {
> pm_message_t power_state;
> unsigned int can_wakeup:1;
> @@ -561,6 +576,7 @@ struct dev_pm_info {
> bool is_late_suspended:1;
> bool early_init:1; /* Owned by the PM core */
> bool direct_complete:1; /* Owned by the PM core */
> + unsigned int driver_flags;
> spinlock_t lock;
> #ifdef CONFIG_PM_SLEEP
> struct list_head entry;
> Index: linux-pm/drivers/base/dd.c
> ===================================================================
> --- linux-pm.orig/drivers/base/dd.c
> +++ linux-pm/drivers/base/dd.c
> @@ -436,6 +436,7 @@ pinctrl_bind_failed:
> if (dev->pm_domain && dev->pm_domain->dismiss)
> dev->pm_domain->dismiss(dev);
> pm_runtime_reinit(dev);
> + dev->power.driver_flags = 0;
>
> switch (ret) {
> case -EPROBE_DEFER:
> @@ -841,6 +842,7 @@ static void __device_release_driver(stru
> if (dev->pm_domain && dev->pm_domain->dismiss)
> dev->pm_domain->dismiss(dev);
> pm_runtime_reinit(dev);
> + dev->power.driver_flags = 0;
>
> klist_remove(&dev->p->knode_driver);
> device_pm_check_callbacks(dev);
> 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
> @@ -729,6 +729,13 @@ state temporarily, for example so that i
> disabled. This all depends on the hardware and the design of the subsystem and
> device driver in question.
>
> +Some bus types and PM domains have a policy to runtime resume all
> +devices 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 a runtime-suspended device. The driver can indicate that
> +by setting ``DPM_FLAG_SAFE_SUSPEND`` in :c:member:`power.driver_flags` at the
> +probe time.
> +
> 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
>
>
next prev parent reply other threads:[~2017-08-29 14:57 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-23 14:42 [PATCH v2 0/9] PM / ACPI / i2c: Deploy runtime PM centric path for system sleep Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 1/9] PM / ACPI: Restore acpi_subsys_complete() Ulf Hansson
2017-08-23 22:41 ` Rafael J. Wysocki
2017-08-23 14:42 ` [PATCH v2 2/9] PM / Sleep: Remove pm_complete_with_resume_check() Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 3/9] PM / ACPI: Split code validating need for runtime resume in ->prepare() Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 4/9] PM / ACPI: Split acpi_lpss_suspend_late|resume_early() Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 5/9] PM / ACPI: Provide option to disable direct_complete for ACPI devices Ulf Hansson
2017-08-23 23:39 ` Rafael J. Wysocki
2017-08-24 0:13 ` Rafael J. Wysocki
2017-08-24 0:20 ` Rafael J. Wysocki
2017-08-24 1:03 ` Rafael J. Wysocki
2017-08-24 9:15 ` Ulf Hansson
2017-08-24 16:35 ` Rafael J. Wysocki
2017-08-24 21:50 ` Rafael J. Wysocki
2017-08-25 13:42 ` Rafael J. Wysocki
2017-08-28 1:30 ` Rafael J. Wysocki
2017-08-28 8:31 ` Ulf Hansson
2017-08-28 12:39 ` Rafael J. Wysocki
2017-08-28 12:54 ` Ulf Hansson
2017-08-28 13:40 ` Rafael J. Wysocki
2017-08-28 14:24 ` Ulf Hansson
2017-08-28 21:14 ` Rafael J. Wysocki
2017-08-25 9:28 ` Ulf Hansson
2017-08-25 12:23 ` Rafael J. Wysocki
2017-08-24 8:19 ` Ulf Hansson
2017-08-24 14:57 ` Rafael J. Wysocki
2017-08-25 9:04 ` Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 6/9] PM / ACPI: Enable the runtime PM centric approach for system sleep Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 7/9] PM / ACPI: Avoid runtime resuming device in acpi_subsys_suspend|freeze() Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 8/9] i2c: designware: Don't resume device in the ->complete() callback Ulf Hansson
2017-08-23 14:42 ` [PATCH v2 9/9] i2c: designware: Deploy the runtime PM centric approach for system sleep Ulf Hansson
2017-08-25 14:10 ` [PATCH v2 0/9] PM / ACPI / i2c: Deploy runtime PM centric path " Jarkko Nikula
2017-08-29 0:18 ` [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep handling Rafael J. Wysocki
2017-08-29 0:20 ` [PATCH 1/3] PM / core: Add SAFE_SUSPEND driver flag Rafael J. Wysocki
2017-08-29 14:57 ` Ulf Hansson [this message]
2017-08-29 15:02 ` Rafael J. Wysocki
2017-08-29 0:59 ` [PATCH 2/3] PM / ACPI: Use SAFE_SUSPEND in the generic ACPI PM domain Rafael J. Wysocki
2017-08-29 0:59 ` [PATCH 3/3] PM: i2c-designware-platdrv: System sleep handling rework Rafael J. Wysocki
2017-08-29 16:38 ` Rafael J. Wysocki
2017-08-29 16:40 ` Rafael J. Wysocki
2017-08-29 10:29 ` [PATCH 0/3] PM / ACPI / i2c: Runtime PM aware system sleep handling Johannes Stezenbach
2017-08-29 11:44 ` Ulf Hansson
2017-08-29 13:53 ` Johannes Stezenbach
2017-08-29 14:43 ` Rafael J. Wysocki
2017-08-29 15:05 ` Ulf Hansson
2017-08-29 16:44 ` Rafael J. Wysocki
2017-08-29 14:49 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAPDyKFrYd4ViFfouM8wd7xkg2L9B0neHt7kTOxLqcGtqBFun5A@mail.gmail.com \
--to=ulf.hansson@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=guodong.xu@linaro.org \
--cc=haojian.zhuang@linaro.org \
--cc=jarkko.nikula@linux.intel.com \
--cc=john.stultz@linaro.org \
--cc=jszhang@marvell.com \
--cc=khilman@kernel.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=sumit.semwal@linaro.org \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).