Re: [PATCH] usb: dwc3: Fix spurious wakeup when port is on device mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 01, 2024, Guilherme G. Piccoli wrote:
> On 31/01/2024 22:23, Thinh Nguyen wrote:
> > [...]
> > I just expected this to happen for S4 and not S3. Our test environment
> > is different. I guess the "local" clock is turned off for S3. Perhaps we
> > should change the trace_clock for one that doesn't stop on suspend. If
> > you're using x86 TSC clock, maybe try this next time?
> > 
> >  # echo x86-tsc > /sys/kernel/debug/tracing/trace_clock
> >
> 
> Hi Thinh, tried it now in the first test with keyboard connected in host
> mode:
> 
>             bash-1015    [002] ...1. 852256557544: dwc3_suspend
> <-dpm_run_callback
>   kworker/u32:19-1099    [004] ...1. 852259924040: dwc3_pci_suspend
> <-pci_pm_suspend
>   kworker/u32:26-1107    [002] ...1. 853901309968: dwc3_pci_resume
> <-dpm_run_callback
>             bash-1015    [006] ...1. 853944152544: dwc3_resume
> <-dpm_run_callback
>             bash-1015    [006] ...1. 853944158900:
> dwc3_core_init_for_resume <-dwc3_resume_common
> 
> So...did it work?! System was in suspend mode for ~4 min, but how do I
> map these TSC timestamps to real time? heh
> 

Looks like it, the delta looks large. But looks like you'd need to do
some conversion based on your clock frequency. That's not convenient.
You can check other clock options to see which can print proper
timestamp. In anycase, we probably don't need to pursue this too far.

> 
> >> [...]
> >> $ dmesg | grep "suspend\|xhci"
> >> [227.990149] PM: suspend entry (deep)
> >> [228.012255] printk: Suspending console(s) (use no_console_suspend to debug)
> >> [228.041056] xhci-hcd xhci-hcd.2.auto: xhci_plat_suspend:
> >> device_may_wakeup: 0
> > 
> > This confirms that the xhci platform device created by dwc3 doesn't
> > enable wakeup. This actually inline with what we thought in the
> > beginning. But from the discussion and tests you did, we can deduce
> > further what had happened now.
> > 
> > Can you test another scenario. Connect an HID device such as a keyboard
> > to the STEAM DECK. Have the DECK run as host. Put it to sleep, check to
> > see if the keyboard can remote wakeup the DECK. If remote wakeup doesn't
> > work, can you try this in addition to the previous patch?
> >
> 
> At first, it didn't work - I couldn't wakeup the system from the keyboard.
> 
> Then I added the hunk below on top of the previous patch:
> 
>         /* Perhaps we need to enable wakeup for xhci->dev? */
>         if (dwc->sys_wakeup) {
>                 device_init_wakeup(&xhci->dev, true);
>                 device_wakeup_enable(dwc->sysdev);
>         }
> 

Did you still see this print in S3?

	xhci-hcd xhci-hcd.2.auto: xhci_plat_suspend: device_may_wakeup: 0

Or was it this:

	xhci-hcd xhci-hcd.2.auto: xhci_plat_suspend: device_may_wakeup: 1

> 
> And..that also didn't work! With or without the patch (+ above hunk),
> can't wakeup from keyboard, in S3/deep.
> 
> But guess what? Keyboard *does wake* the system in s2idle, with or
> without the patch!!! Interesting ...
> 
> Notice that all my tests are on top of v6.8-rc2.
> 

Ok

> 
> > [...] 
> > No problem. I'm glad we can debug this without probing into the
> > hardward. I'll rework the patch so that it can be submitted. Your
> > Tested-by will be very helpful.
> > 
> 
> Awesome, thanks again! Please CC my email in the final patch and I'll be
> glad in testing.
> Cheers,
> 

Sure.

Thanks,
Thinh




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux