lkml.org 
[lkml]   [2018]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: `ohci_rh_resume()` called during `usb_dev_suspend()`
From
Date
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

[unhandled content-type:application/pkcs7-signature]
\
 
 \ /
  Last update: 2018-07-24 16:31    [W:0.059 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site