linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).