On 29/01/2024 23:17, Thinh Nguyen wrote: > [...] >> And ftrace timestamps unfortunately don't help with that, it's not >> showing how much time the device stay suspended, so it might be >> confusing and both cases could appear as the same exact scenario, even >> if they are completely different (fail vs success cases). > > That's odd.. my assumption was the timestamps to be valid. Were you able > to confirm that it's the issue with the timestamps? Perhaps check if the > other devices in the system also wakeup at the approximately same > time printed in the timestamps? > Hi Thinh, indeed - this a bit odd right? I guess this is maybe related with the way kernel keeps track of clocks on suspend - despite TSC keeps accounting on suspend (at least for all modern x86 processors IIUC), the timestamps in both tracing buffer or dmesg do not reflect suspend time. Is it different in your x86 systems? Or maybe in other architectures you have experience with? I've done a test on Steam Deck, take a look in both attachments - seems to be aligned with my perception. Also checked dmesg on my Intel laptop (i5-6300U, with "nonstop_tsc" capability) and the timestamps do not reflect the time spent in S3 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? >> >> I'm not sure about this, what do you mean by a connector controller?! > > I mean connector controller such as Type-C Port Controller (TCPC) or > some specific phy that can detect and report to a driver whether a > connection event occurs. For the lack of better term, I used connector > controller... (perhaps just connector?) Thanks for the clarification! I don't have it at hands anyway, unfortunately heh > [...] > Perhaps we can make this a generic change across different devices. See > below. > >> >> Any other debug / logs that might be useful? > > In your setup, can you check if host mode wakeup is enabled: > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c > index c5d9ac67e612..716b05ff0384 100644 > --- a/drivers/usb/host/xhci-plat.c > +++ b/drivers/usb/host/xhci-plat.c > @@ -472,6 +472,10 @@ static int xhci_plat_suspend(struct device *dev) > ret = xhci_priv_suspend_quirk(hcd); > if (ret) > return ret; > + > + dev_info(dev, "%s: device_may_wakeup: %d\n", > + __func__, !!device_may_wakeup(dev)); > + > /* > * xhci_suspend() needs `do_wakeup` to know whether host is allowed > * to do wakeup during suspend. OK, tried with this hunk alone, and this is the result: $ 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 [228.878517] usb 1-3: reset full-speed USB device number 2 using xhci_hcd [229.150502] usb 1-5: reset full-speed USB device number 3 using xhci_hcd [229.318882] PM: suspend exit > When you go through the dwc3-pci code path, the dwc3 creates the > platform device from the pci device. Perhaps it doesn't enable wakeup. > Let's confirm that. > > My suspicion is that the power management is mapped to the same PCI > PMCSR for both the host and device mode. When the device is in suspend > (D3), it gives control the the PMUs. If the PME is enabled, the PMUs > will generate PME on connection detection if the PME is enabled. When > you go through the xhci code path, wakeup may not be enabled. > > For device mode, we can handle generically by only enabling wakeup if > the following conditions are met: > if (dwc->gadget_driver && dwc->softconnect) > > Try this (totally untested): > > <patch> Thanks a bunch Thinh, with this patch applied (plus the above hunk on xhci-plat), things work both in host or device mode - I could properly suspend and resume after pressing the power button in the Steam Deck. So, how should we proceed now? Could you send a final/official version of the patch? I could test and provide my Tested-by (and proceed with backporting to Deck's kernel). Or let me know if you want/need more tests. Thanks again for all the help/support in this issue =) Cheers, Guilherme
Attachment:
trace.suspend60s.txt.gz
Description: application/gzip
[ 1581.136572] PM: suspend entry (deep) [ 1581.153993] Filesystems sync: 0.017 seconds [ 1581.158424] Freezing user space processes [ 1581.159767] Freezing user space processes completed (elapsed 0.001 seconds) [ 1581.159774] OOM killer disabled. [ 1581.159776] Freezing remaining freezable tasks [ 1581.161135] Freezing remaining freezable tasks completed (elapsed 0.001 seconds) [ 1581.161181] printk: Suspending console(s) (use no_console_suspend to debug) [ 1581.161898] wlan0: deauthenticating from e0:63:da:37:36:f4 by local choice (Reason: 3=DEAUTH_LEAVING) [ 1581.634343] ACPI: EC: interrupt blocked [ 1581.666006] ACPI: PM: Preparing to enter system sleep state S3 [ 1581.667021] ACPI: EC: event blocked [ 1581.667023] ACPI: EC: EC stopped [ 1581.667025] ACPI: PM: Saving platform NVS memory [ 1581.667669] Disabling non-boot CPUs ... [ 1581.670318] smpboot: CPU 1 is now offline [ 1581.673418] smpboot: CPU 2 is now offline [ 1581.676352] smpboot: CPU 3 is now offline [ 1581.679245] smpboot: CPU 4 is now offline [ 1581.681863] smpboot: CPU 5 is now offline [ 1581.684751] smpboot: CPU 6 is now offline [ 1581.685487] Spectre V2 : Update user space SMT mitigation: STIBP off [ 1581.687489] smpboot: CPU 7 is now offline [ 1581.688608] ACPI: PM: Low-level resume complete [ 1581.688638] ACPI: EC: EC started [ 1581.688640] ACPI: PM: Restoring platform NVS memory [ 1581.689102] LVT offset 0 assigned for vector 0x400 [ 1581.689790] Enabling non-boot CPUs ... [ 1581.689896] smpboot: Booting Node 0 Processor 1 APIC 0x1 [ 1581.693107] ACPI: \_SB_.PLTF.C001: Found 3 idle states [ 1581.693589] Spectre V2 : Update user space SMT mitigation: STIBP always-on [ 1581.693642] CPU1 is up [ 1581.693748] smpboot: Booting Node 0 Processor 2 APIC 0x2 [ 1581.697023] ACPI: \_SB_.PLTF.C002: Found 3 idle states [ 1581.697481] CPU2 is up [ 1581.697554] smpboot: Booting Node 0 Processor 3 APIC 0x3 [ 1581.700848] ACPI: \_SB_.PLTF.C003: Found 3 idle states [ 1581.701327] CPU3 is up [ 1581.701406] smpboot: Booting Node 0 Processor 4 APIC 0x4 [ 1581.704698] ACPI: \_SB_.PLTF.C004: Found 3 idle states [ 1581.705151] CPU4 is up [ 1581.705237] smpboot: Booting Node 0 Processor 5 APIC 0x5 [ 1581.708525] ACPI: \_SB_.PLTF.C005: Found 3 idle states [ 1581.709044] CPU5 is up [ 1581.709121] smpboot: Booting Node 0 Processor 6 APIC 0x6 [ 1581.712419] ACPI: \_SB_.PLTF.C006: Found 3 idle states [ 1581.712935] CPU6 is up [ 1581.713008] smpboot: Booting Node 0 Processor 7 APIC 0x7 [ 1581.716321] ACPI: \_SB_.PLTF.C007: Found 3 idle states [ 1581.716896] CPU7 is up [ 1581.718792] ACPI: PM: Waking up from system sleep state S3 [ 1581.720526] ACPI: EC: interrupt unblocked [ 1581.727819] ACPI: EC: event unblocked [ 1581.741323] nvme nvme0: Shutdown timeout set to 8 seconds [ 1581.800877] nvme nvme0: 12/0/0 default/read/poll queues [ 1582.048421] usb 1-5: reset full-speed USB device number 3 using xhci_hcd [ 1582.320325] usb 1-3: reset full-speed USB device number 2 using xhci_hcd [ 1582.503773] OOM killer enabled. [ 1582.503778] Restarting tasks ... done. [ 1582.504480] random: crng reseeded on system resumption [ 1582.505927] Bluetooth: hci0: RTL: examining hci_ver=0a hci_rev=000c lmp_ver=0a lmp_subver=8822 [ 1582.507985] Bluetooth: hci0: RTL: rom_version status=0 version=3 [ 1582.508000] Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_fw.bin [ 1582.508847] Bluetooth: hci0: RTL: loading rtl_bt/rtl8822cu_config.bin [ 1582.509047] Bluetooth: hci0: RTL: cfg_sz 6, total sz 35458 [ 1582.511146] PM: suspend exit [ 1582.815948] Bluetooth: hci0: RTL: fw version 0xffb8abd3 [ 1582.921928] Bluetooth: hci0: AOSP extensions version v1.00 [ 1582.921939] Bluetooth: hci0: AOSP quality report is supported [ 1582.922213] Bluetooth: MGMT ver 1.22 [ 1583.098188] wlan0: authenticate with e0:63:da:37:36:f4 (local address=14:d4:24:71:6d:69) [ 1583.170967] wlan0: send auth to e0:63:da:37:36:f4 (try 1/3) [ 1583.181110] wlan0: authenticated [ 1583.184241] wlan0: associate with e0:63:da:37:36:f4 (try 1/3) [ 1583.194507] wlan0: RX AssocResp from e0:63:da:37:36:f4 (capab=0x1431 status=0 aid=2) [ 1583.194863] wlan0: associated
