From: Paul Menzel <pmenzel+linux-usb@molgen.mpg.de>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: `ohci_rh_resume()` called during `usb_dev_suspend()`
Date: Tue, 24 Jul 2018 16:30:05 +0200 [thread overview]
Message-ID: <a8d7fe54-5fa8-3569-f615-5ee3d967fd18@molgen.mpg.de> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1807241015250.1594-100000@iolanthe.rowland.org>
[-- Attachment #1: Type: text/plain, Size: 3694 bytes --]
Dear Alan,
Thank you for your quick response.
On 07/24/18 16:21, Alan Stern wrote:
> On Tue, 24 Jul 2018, Paul Menzel wrote:
>> Profiling the suspend to and resume/wake-up from ACPI S3 with
>> `sleepgraph.py` on an ASRock E350M1, I noticed that resume methods are
>> called during suspend.
>>
>> Here is an excerpt from the callgraph.
>>
>>> 600.376906 | 0) kworker-81 | | /* device_pm_callback_start: usb usb5, parent: 0000:00:14.5, type [suspend] */
>>> 600.376909 | 0) kworker-81 | | usb_dev_suspend() {
>>> 600.376911 | 0) kworker-81 | | usb_suspend() {
>>> 600.376913 | 0) kworker-81 | | __pm_runtime_resume() {
>>> 600.376915 | 0) kworker-81 | | _cond_resched() {
>>> 600.376917 | 0) kworker-81 | 0.565 us | rcu_all_qs();
>>> 600.376921 | 0) kworker-81 | 4.034 us | } /* _cond_resched */
>>> 600.376922 | 0) kworker-81 | 0.505 us | _raw_spin_lock_irqsave();
>>> 600.376926 | 0) kworker-81 | | rpm_resume() {
>>> 600.376928 | 0) kworker-81 | 0.573 us | _raw_spin_lock();
>>> 600.376934 | 0) kworker-81 | 0.706 us | rpm_resume();
>>> 600.376937 | 0) kworker-81 | 0.556 us | _raw_spin_lock();
>>> 600.376942 | 0) kworker-81 | 0.721 us | __rpm_get_callback();
>>> 600.376946 | 0) kworker-81 | 0.564 us | dev_pm_disable_wake_irq_check();
>>> 600.376949 | 0) kworker-81 | | rpm_callback() {
>>> 600.376952 | 0) kworker-81 | | __rpm_callback() {
>>> 600.376954 | 0) kworker-81 | | usb_runtime_resume() {
>>> 600.376956 | 0) kworker-81 | | usb_resume_both() {
>>> 600.376959 | 0) kworker-81 | | generic_resume() {
>>> 600.376960 | 0) kworker-81 | | hcd_bus_resume() {
>>> 600.376963 | 0) kworker-81 | | ohci_bus_resume [ohci_hcd]() {
>>> 600.376964 | 0) kworker-81 | 0.588 us | _raw_spin_lock_irq();
>>> 600.376968 | 0) kworker-81 | | ohci_rh_resume [ohci_hcd]() {
>>> 600.377043 | 0) kworker-81 | | msleep() {
>>
>> Please find the full callgraph and the HTML output attached.
>>
>> Is that expected?
>
> I can't tell exactly what's happening from your callgraph and HTML, but
> yes, in general it is expected.
>
> The reason is because some devices have different wakeup settings for
> runtime suspend and system suspend: A device that is enabled for wakeup
> signalling during runtime suspend often is not enabled for wakeup
> during system suspend.
>
> As a result, the device's wakeup setting has to be changed when the
> system goes to sleep, and to do that, we have to wake the device up
> temporarily if it is already in runtime suspend.
Understood. Thank you for the explanation.
Sorry for being ignorant, but I have two more questions.
1. Should this also happen, if no USB device is connected to a hub?
2. If somebody point me to the code, how the callback(?)
`pm_runtime_resume()` is hooked up in `usb_suspend()` that’d help
me to better understand, what is going on.
Kind regards and thank you very much in advance,
Paul
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
next prev parent reply other threads:[~2018-07-24 14:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 23:19 `ohci_rh_resume()` called during `usb_dev_suspend()` Paul Menzel
2018-07-24 14:21 ` Alan Stern
2018-07-24 14:30 ` Paul Menzel [this message]
2018-07-24 14:59 ` Alan Stern
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=a8d7fe54-5fa8-3569-f615-5ee3d967fd18@molgen.mpg.de \
--to=pmenzel+linux-usb@molgen.mpg.de \
--cc=linux-kernel@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).