From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-pci@vger.kernel.org, USB list <linux-usb@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...)
Date: Tue, 31 Jul 2012 23:34:47 +0200 [thread overview]
Message-ID: <201207312334.47173.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1207311658340.1532-100000@iolanthe.rowland.org>
On Tuesday, July 31, 2012, Alan Stern wrote:
> [CC: list trimmed]
>
> On Tue, 31 Jul 2012, Rafael J. Wysocki wrote:
>
> > Now it occured to me that perhaps we don't need the current asynchronous
> > pm_runtime_get() at all. The usefulness of it is quite questionable, because
> > either we want to resume the device immediately, for which pm_runtime_get_sync()
> > should be used, or we just want to bump up the usage counter, in which cases
> > pm_runtime_get_noresume() should always be sufficient. I fail to see any
> > particularly compelling use case for pm_runtime_get() doing an asynchronous
> > resume at the moment, but perhaps that's just me.
>
> There are indeed valid uses for pm_runtime_get(). We are forced to use
> it in non-sleepable contexts when we want to resume the device as
> quickly as possible. Example: a driver receives an I/O request from an
> interrupt handler.
Is it actually suitable to be used in such contexts? It doesn't give any
guarantee that the device will be active when it returns, so the caller can't
really rely on it. The caller always has to check if the device has been
resumed before accessing it anyway, so it may as well do a _get_noresume(),
do the check and do pm_request_resume() if needed directly.
Now, as far as interrupt handlers are concerned, there are two cases: either
the device has to be active to generate an interrupt (like PCI), or the
interrupt is generated by something else on behalf of it. We don't seem to
handle the first case very well right now, because in that case the interrupt
handler will always know that the device is active, so it should do a
_get_noresume() and then change the device's status to "active" without
calling any kind of "resume", but we don't provide a helper for that. In the
second case calling pm_runtime_get() doesn't really help either. I think it's
better to do _get_noresume(), check the status and if "suspended", set a flag
for the resume callback to do something specific before returning successfully,
then call pm_request_resume() and return.
> > However, I receive reports of people using pm_runtime_get() where they really
> > should use pm_runtime_get_sync(), so I wonder if we can simply rename
> > pm_runtime_get_sync() as pm_runtime_get() and drop the asynchronous version
> > altogether?
>
> Well, IMO the naming should have been the other way around from the
> start. That is, we should have made pm_runtime_get be the synchronous
> routine and pm_runtime_get_async be the asynchronous one. But it's too
> late to change now.
I'm not sure it is too late. If we first change all the instances of
pm_runtime_get() to pm_runtime_get_async() and then all of the instances of
pm_runtime_get_sync() to pm_runtime_get(), it should be technically possible.
Of course, it would be confusing, but that's a different matter. :-)
> And no, we can't get rid of the async version.
I'm still not sure of that.
Thanks,
Rafael
next prev parent reply other threads:[~2012-07-31 21:28 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44L0.1207241312050.1164-100000@iolanthe.rowland.org>
[not found] ` <87r4s0opck.fsf@nemi.mork.no>
2012-07-25 4:08 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Bjørn Mork
2012-07-25 4:34 ` Huang Ying
2012-07-25 9:58 ` Bjørn Mork
2012-07-25 13:30 ` huang ying
2012-07-25 13:58 ` Bjørn Mork
2012-07-25 18:56 ` Rafael J. Wysocki
2012-07-25 20:02 ` Rafael J. Wysocki
2012-07-25 22:36 ` Bjørn Mork
2012-07-26 2:38 ` Huang Ying
2012-07-26 2:38 ` Huang Ying
2012-07-26 8:54 ` Huang Ying
2012-07-26 10:35 ` Bjørn Mork
2012-07-26 11:02 ` Bjørn Mork
2012-07-26 12:04 ` Bjørn Mork
2012-07-26 15:03 ` Alan Stern
2012-07-26 16:24 ` Bjørn Mork
2012-07-27 5:35 ` Huang Ying
2012-07-27 9:11 ` Bjørn Mork
2012-07-30 3:15 ` Huang Ying
2012-07-30 8:08 ` Bjørn Mork
2012-07-30 13:31 ` huang ying
2012-07-30 16:57 ` Bjørn Mork
2012-07-31 0:22 ` Huang Ying
2012-07-30 14:19 ` Alan Stern
2012-07-31 0:24 ` Huang Ying
2012-07-31 3:18 ` Huang Ying
2012-07-31 17:07 ` Alan Stern
2012-07-27 15:03 ` Alan Stern
2012-07-27 19:11 ` Rafael J. Wysocki
2012-07-27 19:39 ` Alan Stern
2012-07-27 19:54 ` Rafael J. Wysocki
2012-07-28 16:12 ` Alan Stern
2012-07-28 20:26 ` Rafael J. Wysocki
2012-07-28 21:12 ` Alan Stern
2012-07-29 13:55 ` Rafael J. Wysocki
2012-07-29 14:55 ` Alan Stern
2012-07-29 19:18 ` Rafael J. Wysocki
2012-07-31 20:31 ` Do we need asynchronous pm_runtime_get()? (was: Re: bisected regression ...) Rafael J. Wysocki
2012-07-31 21:05 ` Alan Stern
2012-07-31 21:34 ` Rafael J. Wysocki [this message]
2012-07-31 21:49 ` Rafael J. Wysocki
2012-08-01 14:36 ` Alan Stern
2012-08-01 21:24 ` Rafael J. Wysocki
2012-08-02 20:16 ` Alan Stern
2012-08-02 21:26 ` Rafael J. Wysocki
2012-08-03 2:20 ` Alan Stern
2012-08-03 3:37 ` Ming Lei
2012-08-03 14:28 ` Alan Stern
2012-08-04 19:47 ` Rafael J. Wysocki
2012-08-04 20:25 ` Alan Stern
2012-08-04 20:48 ` Rafael J. Wysocki
2012-08-04 20:48 ` Alan Stern
2012-08-04 21:15 ` Rafael J. Wysocki
2012-08-04 22:13 ` Alan Stern
2012-08-05 15:26 ` Rafael J. Wysocki
2012-08-06 13:30 ` Ming Lei
2012-08-06 14:47 ` Alan Stern
2012-08-07 1:35 ` Ming Lei
2012-08-07 11:23 ` Rafael J. Wysocki
2012-08-07 15:14 ` Ming Lei
2012-08-07 15:42 ` Alan Stern
2012-08-07 16:30 ` Ming Lei
2012-08-07 20:57 ` Rafael J. Wysocki
2012-08-07 20:45 ` Rafael J. Wysocki
2012-08-08 2:02 ` Ming Lei
2012-08-08 18:42 ` Alan Stern
2012-08-08 20:16 ` Rafael J. Wysocki
2012-08-09 5:55 ` Ming Lei
2012-08-09 10:46 ` Rafael J. Wysocki
2012-08-09 10:55 ` Ming Lei
2012-08-09 19:41 ` Rafael J. Wysocki
2012-08-10 3:19 ` Ming Lei
2012-08-10 20:29 ` Rafael J. Wysocki
2012-08-08 22:27 ` Rafael J. Wysocki
2012-08-06 15:48 ` Alan Stern
2012-08-06 20:30 ` Rafael J. Wysocki
2012-08-07 12:28 ` Rafael J. Wysocki
2012-08-07 17:15 ` Alan Stern
2012-08-07 21:31 ` Rafael J. Wysocki
2012-08-03 14:05 ` Alan Stern
2012-08-04 20:08 ` Rafael J. Wysocki
2012-08-04 20:42 ` Alan Stern
2012-08-04 20:59 ` Rafael J. Wysocki
2012-08-04 19:35 ` Rafael J. Wysocki
2012-07-29 20:12 ` bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure Jassi Brar
2012-07-29 21:44 ` Alan Stern
2012-07-25 19:51 ` [PATCH] PCI / PM: Fix messages printed by acpi_pci_set_power_state() Rafael J. Wysocki
2012-07-25 20:02 ` Alan Stern
2012-07-25 20:48 ` [PATCH][update] " 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=201207312334.47173.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=stern@rowland.harvard.edu \
/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).