Hi Thinh, thanks for your response. I'll clarify inline below: On 04/12/2023 22:23, Thinh Nguyen wrote: > [...] >>> It was noticed that on plugging a low-power USB source on Steam >>> Deck USB-C port (handled by dwc3), if such port is on device role, > > I'm not clear of the testing sequence here. Can you clarify further? Is > this device operating as host mode but then it switches role to device > mode when no device is connected? > Exactly this. We have a driver that changes between host/device mode according to ACPI notifications on port connect. But to make tests/discussion easier and eliminate more variables, we just dropped this driver and do it manually. So the steps are: (A) host mode test 1) Put the port on host mode using debugfs interface. 2) Wait 30 seconds, plug a cable connecting the Steam Deck to a laptop - we call this connection a "low-power source", since it seems to charge slowly the Deck. 3) Suspend the Deck after some seconds (S3/deep) - success (B) device mode test 1) Put the port on device mode using debugfs interface. 2) Wait 30 seconds, plug a cable connecting the Steam Deck to a laptop. 3) Suspend the Deck after some seconds (S3/deep) - fails 3a) If pcie_pme is using MSIs, it fails showing that a wakeup interrupt is pending, in this case the Steam Deck effectively doesn't enter suspend. 3b) if PCIe PME is not using MSIs, Deck suspends and right after (less than a second), wakes up properly. >>> the HW somehow keep asseting the PCIe PME line and triggering a >>> wakeup event on S3/deep suspend (that manifests as a PME wakeup >>> interrupt, failing the suspend path). That doesn't happen when the USB >>> port is on host mode or if the USB device connected is not a low-power >>> type (for example, a connected keyboard doesn't reproduce that). > > Is the PME continuously generating non-stop? Did you test this in USB3 > speed? Does this happen for every low-power device or just this specific > low-power device? It seems PME is continuously being generated, yes. I tested by connecting to my laptop as mentioned, I guess others tested different scenarios, not always reproduces. An example: a keyboard or a disk connected when the USB port is on device mode doesn't reproduce. Also, I think I didn't test "in USB3 speed" - could you detail more, not sure if I understood that properly. > [...] > Even if you masked all the interrupts, and the events are still > generating? Did you check if the driver handled wakeup from PME and > properly restore the controller? > Ok, let me clarify a bit. From the ACPI perspective, I was able to check from kernel that some GPEs were generated on resume when the issue happens (and potentially even when the issue doesn't happen, in host mode for example). So, what I did was masking all these GPEs using the kernel sysfs interface. After masking, the issue still reproduces but the GPEs count doesn't increase. Regarding the PME interrupt now: if MSI is used on PME, I can see an increase of 1 in every suspend/resume attempt (checking /proc/interrupts). Now if MSIs are not used, guess what? There was no increase in the interrupt at all. I didn't mask the PME interrupt on PCIe PME driver...but even with PME driver disabled, IIRC the problem reproduces. "Did you check if the driver handled wakeup from PME and properly restore the controller?" <- I think I didn't - how do you suggest me to check that? What I've noticed is that either the system can't suspend, or if no MSIs are used on PCIe PME, it suspends and resumes right after, with success. In this latter case, dwc3 works normally again, resume is successful. Let me know if you want me to check any other path or function called, etc. > [...] > > Some platforms may need a soft reset before a change to prtcapdir. This > may break some setups. This seems to be a workaround and should not be > treated as part of a normal flow. OK, do you have any other idea of a register change that is softer than changing "prtcapdir" and could prevent the issue? Also, would that workaround makes sense as...a quirk? We could guard it for Deck's HW exclusively, using DMI if you think it does make sense...or the dwc3 quirks (already have some for AMD right?) I'm CCing Piyush and Huang from AMD, since this is AMD HW. Any other suggestions are much appreciated. Thanks, Guilherme
