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-
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
>>> [...] 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...
>>>> [...]
>>> "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'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?
> [...]
> Sorry for the delay response. Just got back from break.
No need for apologies at all, thanks a bunch for your comprehensive
response!
Cheers,
Guilherme
