From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pm@lists.linux-foundation.org, linux-omap@vger.kernel.org,
Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com>,
Magnus Damm <magnus.damm@gmail.com>,
LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>
Subject: Re: [linux-pm] calling runtime PM from system PM methods
Date: Sun, 19 Jun 2011 21:36:51 +0200 [thread overview]
Message-ID: <201106192136.51572.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1106191042510.11375-100000@netrider.rowland.org>
On Sunday, June 19, 2011, Alan Stern wrote:
> On Sun, 19 Jun 2011, Rafael J. Wysocki wrote:
>
> > Well, that was kind of difficult to debug, but not impossible. :-)
> >
> > The problem here turns out to be related to the SCSI subsystem.
> > Namely, when the AHCI controller is suspended, it uses the SCSI error
> > handling mechanism for scheduling the suspend operation (I'm still at a little
> > loss why that is necessary, but Tejun says it is :-)). This (after several
> > convoluted operations) causes scsi_error_handler() to be woken up and
> > it calls scsi_autopm_get_host(shost), which returns error code (-EAGAIN),
> > because the runtime PM has been disabled at the host level.
>
> Oh no. I was afraid something like this was going to happen
> eventually.
>
> It's clear that we don't want runtime PM kicking in while the SCSI
> error handler is running. That's why I added the
> scsi_autopm_get_host(). But this also means we will run into trouble
> if the error handler needs to be used during a power transition.
>
> > This happens because scsi_autopm_get_host() uses
> > pm_runtime_get_sync(&shost->shost_gendev) and returns error code when
> > shost_gendev.power.disable_depth is nonzero.
>
> Maybe get_sync doesn't need to return an error if the runtime status is
> already ACTIVE. I'm not sure about this; it's just an idea...
Well, if disable_depth > 0, ACTIVE isn't really well defined. As I said,
though, I think it makes sense for pm_runtime_get_sync() to return 0 when
disable_depth > 0, because the grabbing of a reference is successful anyway and
the caller may assume that the device is accessible in that case.
In the meantime I rethought the __pm_runtime_disable() part of my previous
patch and I now think it's not necessary to complicate it any more. Of course,
we need not check if runtime resume is pending in __device_suspend(), because
we've done it already in dpm_prepare(), but the barrier part should better be
done in there too.
Updated patch is appended.
Thanks,
Rafael
---
drivers/base/power/main.c | 6 ++++++
drivers/base/power/runtime.c | 10 ++++++----
2 files changed, 12 insertions(+), 4 deletions(-)
Index: linux-2.6/drivers/base/power/main.c
===================================================================
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -521,6 +521,9 @@ static int device_resume(struct device *
if (!dev->power.is_suspended)
goto Unlock;
+ pm_runtime_get_noresume(dev);
+ pm_runtime_enable(dev);
+
if (dev->pwr_domain) {
pm_dev_dbg(dev, state, "power domain ");
error = pm_op(dev, &dev->pwr_domain->ops, state);
@@ -557,6 +560,7 @@ static int device_resume(struct device *
End:
dev->power.is_suspended = false;
+ pm_runtime_put_noidle(dev);
Unlock:
device_unlock(dev);
@@ -896,6 +900,8 @@ static int __device_suspend(struct devic
if (error)
async_error = error;
+ else if (dev->power.is_suspended)
+ __pm_runtime_disable(dev, false);
return error;
}
Index: linux-2.6/drivers/base/power/runtime.c
===================================================================
--- linux-2.6.orig/drivers/base/power/runtime.c
+++ linux-2.6/drivers/base/power/runtime.c
@@ -455,12 +455,14 @@ static int rpm_resume(struct device *dev
dev_dbg(dev, "%s flags 0x%x\n", __func__, rpmflags);
repeat:
- if (dev->power.runtime_error)
+ if (dev->power.runtime_error) {
retval = -EINVAL;
- else if (dev->power.disable_depth > 0)
- retval = -EAGAIN;
- if (retval)
goto out;
+ } else if (dev->power.disable_depth > 0) {
+ if (!(rpmflags & RPM_GET_PUT))
+ retval = -EAGAIN;
+ goto out;
+ }
/*
* Other scheduled or pending requests need to be canceled. Small
next prev parent reply other threads:[~2011-06-19 19:36 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 0:05 calling runtime PM from system PM methods Kevin Hilman
2011-06-02 14:18 ` [linux-pm] " Alan Stern
2011-06-02 17:10 ` Kevin Hilman
2011-06-02 18:38 ` Alan Stern
2011-06-06 18:29 ` Rafael J. Wysocki
2011-06-06 19:16 ` Alan Stern
2011-06-06 22:25 ` Kevin Hilman
2011-06-07 13:55 ` Alan Stern
2011-06-07 21:32 ` Rafael J. Wysocki
2011-06-07 22:34 ` Kevin Hilman
2011-06-08 22:50 ` Kevin Hilman
2011-06-09 5:29 ` Magnus Damm
2011-06-09 13:56 ` Alan Stern
2011-06-10 14:36 ` Mark Brown
2011-06-10 14:51 ` Alan Stern
2011-06-10 15:21 ` Mark Brown
2011-06-10 15:45 ` Alan Stern
2011-06-10 15:57 ` Mark Brown
2011-06-10 17:17 ` Alan Stern
2011-06-10 17:31 ` Mark Brown
2011-06-10 18:38 ` Rafael J. Wysocki
2011-06-10 18:42 ` Mark Brown
2011-06-10 20:27 ` Rafael J. Wysocki
2011-06-10 21:27 ` Alan Stern
2011-06-11 11:42 ` Mark Brown
2011-06-11 20:56 ` Rafael J. Wysocki
2011-06-13 12:22 ` [linux-pm] " Mark Brown
2011-06-10 18:49 ` Rafael J. Wysocki
2011-06-10 18:54 ` Mark Brown
2011-06-10 20:45 ` Rafael J. Wysocki
2011-06-10 23:52 ` Kevin Hilman
2011-06-11 16:42 ` Alan Stern
2011-06-11 22:46 ` Rafael J. Wysocki
2011-06-12 15:59 ` Alan Stern
2011-06-12 18:27 ` Rafael J. Wysocki
2011-06-15 21:54 ` Kevin Hilman
2011-06-16 0:01 ` Rafael J. Wysocki
2011-06-16 1:17 ` Kevin Hilman
2011-06-16 14:27 ` Alan Stern
2011-06-16 22:48 ` Rafael J. Wysocki
2011-06-17 19:47 ` Rafael J. Wysocki
2011-06-17 20:04 ` Alan Stern
2011-06-17 21:29 ` Rafael J. Wysocki
2011-06-18 11:08 ` Rafael J. Wysocki
2011-06-18 15:31 ` Alan Stern
2011-06-18 21:01 ` Rafael J. Wysocki
2011-06-18 23:57 ` Rafael J. Wysocki
2011-06-19 1:42 ` Alan Stern
2011-06-19 14:04 ` Rafael J. Wysocki
2011-06-19 15:01 ` Alan Stern
2011-06-19 19:36 ` Rafael J. Wysocki [this message]
2011-06-20 14:39 ` Alan Stern
2011-06-20 19:53 ` Rafael J. Wysocki
2011-06-16 22:30 ` Rafael J. Wysocki
2011-06-10 23:14 ` Kevin Hilman
2011-06-11 16:27 ` Alan Stern
2011-06-11 23:13 ` Rafael J. Wysocki
2011-06-06 18:01 ` 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=201106192136.51572.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=khilman@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=magnus.damm@gmail.com \
--cc=paul@pwsan.com \
--cc=stern@rowland.harvard.edu \
--cc=tj@kernel.org \
/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).