On 05/12/2023 11:40, Guilherme G. Piccoli wrote: > 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 Hi folks, just curious if you think the way forward would be indeed to quirk it based on DMI/device ID, or if should pursue another approach here. Suggestions are very welcome, and thanks in advance! Guilherme
