Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1342535 > unrolled thread
| Started by | Derek Basehore <dbasehore@chromium.org> |
|---|---|
| First post | 2016-02-25 01:20 +0100 |
| Last post | 2016-03-02 10:30 +0100 |
| Articles | 5 — 2 participants |
Back to article view | Back to linux.kernel
[PATCH v1 1/3] PM / sleep: Check legacy pm callbacks for direct complete Derek Basehore <dbasehore@chromium.org> - 2016-02-25 01:20 +0100
[PATCH v1 3/3] scsi: allow scsi devices to use direct complete Derek Basehore <dbasehore@chromium.org> - 2016-02-25 01:20 +0100
[PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete Derek Basehore <dbasehore@chromium.org> - 2016-02-25 01:20 +0100
Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete Ulf Hansson <ulf.hansson@linaro.org> - 2016-03-01 21:50 +0100
Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete Ulf Hansson <ulf.hansson@linaro.org> - 2016-03-02 10:30 +0100
| From | Derek Basehore <dbasehore@chromium.org> |
|---|---|
| Date | 2016-02-25 01:20 +0100 |
| Subject | [PATCH v1 1/3] PM / sleep: Check legacy pm callbacks for direct complete |
| Message-ID | <r5ROW-40H-7@gated-at.bofh.it> |
This adds checks for legacy pm callbacks when setting no_pm_callbacks.
This fixes an issue where these suspend/resume callbacks were
incorrectly ignored during suspend/resume with direct complete.
Fixes: 4534d9d881f9 "PM / sleep: Go direct_complete if driver has..."
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
---
drivers/base/power/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 6e7c3cc..e0017d9 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1764,8 +1764,10 @@ void device_pm_check_callbacks(struct device *dev)
{
spin_lock_irq(&dev->power.lock);
dev->power.no_pm_callbacks =
- (!dev->bus || pm_ops_is_empty(dev->bus->pm)) &&
- (!dev->class || pm_ops_is_empty(dev->class->pm)) &&
+ (!dev->bus || (!dev->bus->resume && !dev->bus->suspend &&
+ pm_ops_is_empty(dev->bus->pm))) &&
+ (!dev->class || (!dev->class->resume && !dev->class->suspend &&
+ pm_ops_is_empty(dev->class->pm))) &&
(!dev->type || pm_ops_is_empty(dev->type->pm)) &&
(!dev->pm_domain || pm_ops_is_empty(&dev->pm_domain->ops)) &&
(!dev->driver || pm_ops_is_empty(dev->driver->pm));
--
2.7.0.rc3.207.g0ac5344
[toc] | [next] | [standalone]
| From | Derek Basehore <dbasehore@chromium.org> |
|---|---|
| Date | 2016-02-25 01:20 +0100 |
| Subject | [PATCH v1 3/3] scsi: allow scsi devices to use direct complete |
| Message-ID | <r5ROW-40H-11@gated-at.bofh.it> |
| In reply to | #1342535 |
This allows scsi devices to remain runtime suspended for system suspend. Since runtime suspend is stricter than system suspend callbacks, this is just returning a positive number for the prepare callback. Signed-off-by: Derek Basehore <dbasehore@chromium.org> Reviewed-by: Eric Caruso <ejcaruso@chromium.org> --- drivers/scsi/scsi_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c index b44c1bb..7af76ad 100644 --- a/drivers/scsi/scsi_pm.c +++ b/drivers/scsi/scsi_pm.c @@ -178,7 +178,7 @@ static int scsi_bus_prepare(struct device *dev) /* Wait until async scanning is finished */ scsi_complete_async_scans(); } - return 0; + return 1; } static int scsi_bus_suspend(struct device *dev) -- 2.7.0.rc3.207.g0ac5344
[toc] | [prev] | [next] | [standalone]
| From | Derek Basehore <dbasehore@chromium.org> |
|---|---|
| Date | 2016-02-25 01:20 +0100 |
| Subject | [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete |
| Message-ID | <r5ROW-40H-13@gated-at.bofh.it> |
| In reply to | #1342535 |
This tries to runtime suspend devices that are still active for direct
complete. This is for cases such as autosuspend delays which leaves
devices able to runtime suspend but still active. It's beneficial in
this case to runtime suspend the device to take advantage of direct
complete when possible.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
---
drivers/base/power/main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index e0017d9..9693032 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1380,7 +1380,12 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
goto Complete;
if (dev->power.direct_complete) {
- if (pm_runtime_status_suspended(dev)) {
+ /*
+ * Check if we're runtime suspended. If not, try to runtime
+ * suspend for autosuspend cases.
+ */
+ if (pm_runtime_status_suspended(dev) ||
+ !pm_runtime_suspend(dev)) {
pm_runtime_disable(dev);
if (pm_runtime_status_suspended(dev))
goto Complete;
--
2.7.0.rc3.207.g0ac5344
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-03-01 21:50 +0100 |
| Subject | Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete |
| Message-ID | <r7Zp0-5Vk-17@gated-at.bofh.it> |
| In reply to | #1342537 |
On 25 February 2016 at 01:11, Derek Basehore <dbasehore@chromium.org> wrote:
> This tries to runtime suspend devices that are still active for direct
> complete. This is for cases such as autosuspend delays which leaves
> devices able to runtime suspend but still active. It's beneficial in
> this case to runtime suspend the device to take advantage of direct
> complete when possible.
Unfortunate this doesn't work. In the device_prepare() phase the PM
core prevents runtime suspend via a call to pm_runtime_get_noresume().
Kind regards
Uffe
>
> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
> Reviewed-by: Eric Caruso <ejcaruso@chromium.org>
> ---
> drivers/base/power/main.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index e0017d9..9693032 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1380,7 +1380,12 @@ static int __device_suspend(struct device *dev, pm_message_t state, bool async)
> goto Complete;
>
> if (dev->power.direct_complete) {
> - if (pm_runtime_status_suspended(dev)) {
> + /*
> + * Check if we're runtime suspended. If not, try to runtime
> + * suspend for autosuspend cases.
> + */
> + if (pm_runtime_status_suspended(dev) ||
> + !pm_runtime_suspend(dev)) {
> pm_runtime_disable(dev);
> if (pm_runtime_status_suspended(dev))
> goto Complete;
> --
> 2.7.0.rc3.207.g0ac5344
>
[toc] | [prev] | [next] | [standalone]
| From | Ulf Hansson <ulf.hansson@linaro.org> |
|---|---|
| Date | 2016-03-02 10:30 +0100 |
| Subject | Re: [PATCH v1 2/3] PM / sleep: try to runtime suspend for direct complete |
| Message-ID | <r8bgu-5FN-5@gated-at.bofh.it> |
| In reply to | #1347014 |
On 2 March 2016 at 09:31, dbasehore . <dbasehore@chromium.org> wrote: > > On Mar 1, 2016 12:41, "Ulf Hansson" <ulf.hansson@linaro.org> wrote: >> >> On 25 February 2016 at 01:11, Derek Basehore <dbasehore@chromium.org> >> wrote: >> > This tries to runtime suspend devices that are still active for direct >> > complete. This is for cases such as autosuspend delays which leaves >> > devices able to runtime suspend but still active. It's beneficial in >> > this case to runtime suspend the device to take advantage of direct >> > complete when possible. >> >> Unfortunate this doesn't work. In the device_prepare() phase the PM >> core prevents runtime suspend via a call to pm_runtime_get_noresume(). >> >> Kind regards >> Uffe >> > > A call to pm_runtime_put_sync_suspend should work. We can't do this > earlier, because we don't know if the device will actually use > direct_complete due to its children. Calling pm_runtime_put_noidle may > allow another pm_runtime_put to runtime suspend the device, but we're > trying to do that anyways. Also, we can't just call ...put_sync since that > might not suspend due to autosuspend delays. > > We just need to balance the call with another get_noresume after. Am I > missing anything? Yes. The important part that you need to take into consideration is the sysfs intererface for runtime PM of devices. It allows userspace to prevent runtime PM suspend (pm_runtime_forbid()). Therefore, you simply can not rely on the regular runtime PM APIs to put a device into low power state during system PM. In cases of a runtime PM centric subsystem/driver, it can instead use pm_runtime_force_suspend(). Kind regards Uffe
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web