On Sun, Jan 21, 2024, Guilherme G. Piccoli wrote: > On 17/01/2024 21:39, Thinh Nguyen wrote: > > [...] > > That means the disconnection is initiated by the dwc3 driver. This > > should happen when you put the STEAM DECK in suspend while connected to > > the laptop. From your laptop, you should see the DECK is disconnected as > > if the cable is unplugged. > > > > If that did not happen, can you capture the dwc3 tracepoints to see > > what's wrong? > > > > You can follow this instruction to capture the tracepoints: > > https://urldefense.com/v3/__https://www.kernel.org/doc/html/latest/driver-api/usb/dwc3.html*required-information__;Iw!!A4F2R9G_pg!e5M1JBeGFMnB-XN4xtm2c-zE-U8Y6SpJ9PcwH-kc6m3H69SdPg-4-wvvM0-XZ8l4iCtlJtpvK-doVRDZBkO67w$ > > > > Hi Thinh, thanks again for your patience and suggestions! > > I've tried my best to determine the state of the USB port from my laptop > PoV when connecting the Deck there, but I was unsuccessful. The Deck > doesn't appear on laptop's lsusb output, and there's nothing on dmesg / > tracing (xhci), dynamic debug or some power interfaces I poked about > that. The way to go, IIUC, it's now trying to measure that directly in > the port, using a multimeter or some HW device for that. I don't have > that, but what I was able to do instead is collecting the traces you > asked, at least heh > > > So, I did 4 collections, all in the attached tarball. > > (1) Right after booting the Steam Deck and enabling the traces [0], I've > changed the mode of dwc3 (in the debugfs) from host to device - results > on {trace,regdump}.1 The tracepoints indicated that no gadget driver was binded. So the controller actually never started (ie. soft-connection never happened if the controller doesn't start). > > (2) Plugged the USB cable connecting the Deck to my laptop - results at > {trace,regdump}.2 and as we can see, traces are empty. Right, because as noted above, no activity is seen. > > (3) Attempt suspending the Deck (by running "echo mem > > /sys/power/state"), it failed as expected - then I've collected results > on {trace,regdump}.3 I can see the device was resumed right after. kworker/u32:10-1078 [002] ...1. 179.453703: dwc3_pci_suspend <-pci_pm_suspend kworker/u32:10-1078 [002] ...1. 179.453704: dwc3_pci_dsm <-pci_pm_suspend kworker/u32:19-1087 [005] ...1. 179.939836: dwc3_pci_resume <-dpm_run_callback > > (4) [bonus] Collected the same results of 3 (after rebooting the Deck) > but running dwc3 with this patch/quirk - it's easy to notice in the > trace, as we can see the extras readl/writel prior to suspend. In this > case, suspend works...and results are on {trace,regdump}.4-PATCHED Even in the patched version, device was resumed right after. The resume here may not trigger the system resume, but it resumed nonetheless. kworker/u32:6-356 [006] ...1. 69.600400: dwc3_pci_suspend <-pci_pm_suspend kworker/u32:6-356 [006] ...1. 69.600401: dwc3_pci_dsm <-pci_pm_suspend kworker/u32:22-1028 [001] ...1. 70.125294: dwc3_pci_resume <-dpm_run_callback > > Tests were done on kernel 6.7 mainline, no OOT drivers running. Hope it > helps to narrow down the issue, and again, thanks for your help here. > > [0] > cd /sys/kernel/tracing/ > echo 1 > events/dwc3/enable > echo :mod:dwc3 > set_ftrace_filter > echo :mod:dwc3_pci >> set_ftrace_filter > echo function > current_tracer > > > > [...] > > That means to unplug the cable connected to the STEAM DECK. Put the > > STEAM DECK to suspend. Check to see if it stays suspend or it would wake > > up right away. > > Oh, this case was tested before and it works fine =) > > > > Also, in your test, the connected host (the laptop) remained ON at all > > time while the STEAM DECK was tested for suspend right? > > > > Yes, laptop always powered ON! > Thanks for the logs and data points. The tracepoints indicate that the workaround _only_ prevented the system wakeup, not the controller. The wakeup still happen there as you can see the controller got woken up immediately after request to go into suspend in both cases, patched or not. So the workaround you provided doesn't help keeping the controller in suspend. We need to look into why that's the case, and we need to figure out where the source of the wake came from. Do you have a connector controller that can also wakeup the system? As for the workaround, if the wakeup source is the usb controller, did you try to disable wakeup? diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 6604845c397c..e395d7518022 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -359,7 +359,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct pci_device_id *id) goto err; } - device_init_wakeup(dev, true); + device_init_wakeup(dev, false); pci_set_drvdata(pci, dwc); pm_runtime_put(dev); #ifdef CONFIG_PM If it works, you can fine tune to only disable wakeup when in device mode and enable when in host mode with device_set_wakeup_enable(). Thanks, Thinh
