Re: USB-audio isochronous Missed Service Errors on AMD Zen5 client (Fire Range) -- Data Fabric idle C-state? No OS-level knob found

[Gordon Chen]

Hi Mathias, and Mario / Shyam,

Thanks Mathias -- the LTR/LTC angle is very helpful. It points at exactly
the kind of "tell the fabric to stay awake for this stream" mechanism I was
looking for, without having to burn memory bandwidth.

Following your pointer I read the capability registers via debugfs (reg-cap)
on the controller the device sits behind (0000:6b:00.3):

    HCCPARAMS1 = 0x0120ffc5   ->  bit 6 (LTC) = 1

So this xHC does advertise the Latency Tolerance Messaging Capability.

One constraint rules out the first path you described, though: the device
(Behringer Flow 8) is a USB 2.0 high-speed device -- speed = 480 Mbps,
bcdUSB 2.00, no BOS descriptor and no LTM support advertised. It therefore
never emits USB3 LTM messages, so there is nothing for the xHC to aggregate
from the device side, and I'd expect it to forward a permissive (large)
tolerance upstream by default -- which would let the fabric idle freely.

That leaves the second path you mentioned: the driver injecting a custom
latency value that the xHC factors into the shortest-tolerated-latency it
forwards. Since the xhci driver doesn't implement that yet, a few questions
before I hack a PoC together:

  - Which mechanism in the spec does this map to (4.13.x)? Is it a value the
    driver writes to a register / context that the xHC then uses for its
    upstream LTR, or is it per-device / per-endpoint? A pointer to the exact
    field would save me a lot of guessing.

  - Is there any in-tree precedent or WIP I should base the PoC on?

I'm happy to write and test it -- I have a 1:1 reproducer (count short OUT
URBs while playing audio), so I can tell immediately whether forcing a small
tolerance makes the missed-service events disappear.

And for Mario / Shyam, the other half of the chain: assuming the xHC does
forward a small latency tolerance upstream as a PCIe LTR message, does the
AMD client SoC's Data Fabric honor PCIe LTR to constrain its idle / DF
C-state entry? Or is DF idle gating independent of PCIe LTR on these parts?
That determines whether the whole approach can work at all -- the xHCI side
can express the requirement, but only if the fabric acts on it.

(As a lighter-weight variant I'm also looking at whether writing an
aggressive LTR value directly at the PCIe layer for the xHC function has any
effect -- but that hinges on the same does-DF-honor-LTR question.)

Thanks again,
Gordon Chen