On Thu, Jan 11, 2024, Guilherme G. Piccoli wrote: > Hi Thinh, thanks for your response! My comments are inline below: > > > On 10/01/2024 23:01, Thinh Nguyen wrote: > > [...] > > > > I assume there was a role switch negotiation to switch to device mode > > successfully here before the next step? > > Yes, exactly. We have an out-of-tree driver that reads the port state > through some ACPI message to switch modes, but to be 100% clear: > > **This OOT driver was factored out for our tests** - in other words: all > tests made were done by manually changing the port mode (via debugfs) > and waiting some seconds for that to settle. This OOT driver is not even > compiled for recent kernels (it runs in a downstream 6.1 kernel). > > > >>> 3b) if PCIe PME is not using MSIs, Deck suspends and right after (less > >>> than a second), wakes up properly. > >>> > > > > Your platform is DRD right? If that's the case, then it should be using > > level interrupt. It should not support MSI unless it's host mode only. > > > > Yes, DRD indeed - but it's the **PCI PME interrupt** that uses MSI, not > the USB PCI device. Here is an output of lspci: > > $ lspci -vknns 04:00.3 > 04:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] > VanGogh USB0 [1022:163a] (prog-if fe [USB Device]) > Subsystem: Valve Software VanGogh USB0 [1e44:1776] > Flags: bus master, fast devsel, latency 0, IRQ 26 > Memory at 80000000 (64-bit, non-prefetchable) [size=1M] > Capabilities: [48] Vendor Specific Information: Len=08 <?> > Capabilities: [50] Power Management version 3 > Capabilities: [64] Express Endpoint, MSI 00 > Capabilities: [a0] MSI: Enable- Count=1/8 Maskable- 64bit+ > Capabilities: [c0] MSI-X: Enable- Count=8 Masked- Are you showing MSI enabled? That looks like MSI is disabled. > Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 > Len=010 <?> > Kernel driver in use: dwc3-pci > Kernel modules: dwc3_pci > > Now, I **guess** this is expected, but there is a difference in > /proc/interrupt between device and host mode: > > $ grep 26: /proc/interrupts | tr -s \ # device mode > [empty] > > $ grep 26: /proc/interrupts | tr -s \ # host mode > 26: 0 0 0 0 0 0 0 0 IO-APIC 25-fasteoi xhci-hcd:usb3 Looks like it's level interrupt here. I don't see "edge" or MSI interrupt. Is the pcie_pme share the same interrupt line as the usb controller? I'm not sure how the STEAM DECK is designed. Does the OOT driver manages the power state request outside of the PCI PM for device mode and not just reading the port state? If that's the case, the issue could be in the OOT driver? > > > >>> [...] 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. > > > > I mean to ask whether this test was done while operating in SuperSpeed > > or SuperSpeed Plus. > > Well, I'm not sure if I know how to answer that heh > Checking "lsusb --tree" in host mode gives me: > > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 10000M > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M > > When I switch to device mode, there is no output (and I think this is > expected, right?). Or...the question was about the USB port in my > laptop, the one I'm connecting on the Deck? > > Apologies for my hard time understanding this one... > No problem. I was referring to connected speed. The print above doesn't show any device connected. PME generation can come from USB2 or USB3 PMU. I wanted to check if the problem was because of one of them is misbehaving, but I don't think it's related to this. > > >>>> [...] > >>> "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? > > > > If it's in device mode, and you mentioned PME, that means that the > > device was in hibernation. I assume that you're not using the mainline > > dwc3 driver if Steam Deck supports hibernation and was in hibernation > > before the connection. Otherwise, PME should not be generated. If it > > does, something is broken and requires a workaround (as the one you > > have). > > There was no hibernation (S4 state) involved, just to clarify - it's a > mem_sleep /suspend to RAM operation, usually called deep sleep / S3. And > indeed, the PME seems to be generated and prevents the mem_sleep (or it > does sleep but instantly wakes-up, which is the case with level interrupts). I was referring to the controller hibernation and not system hibernation. S3 will cause the xhci driver to put the host controller to go into hibernation and send a power state change request through PCI PM. Usually the power state change would put the core in D3 and passes the control to the PMU, and PME generation can happen then. Similar behavior applies to device mode, but the power state change may be tied to a different interface than PCI PM? Perhaps you're missing the logic/flow to update the power state change when in device mode. And perhaps putting the controller in host mode passes the control to xhci allowing the driver to properly manage the power state preventing PME from generated? It's a little difficult to debug without more info. Did you seek help from the vendor? > > I'll check both Steam Deck models (LCD and OLED) to see if both can be > quirked in the same way and provide then a simple patch doing that for > review, makes sense? > I assume you ruled out problems from bad cable or faulty laptop/device? Thanks, Thinh
