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" <chengordon326@gmail.com>]

Hi all,

A quick correction and a sharper question after probing the PCIe side.

I checked the controller's PCIe config (lspci -vvv): the xHC function
(0000:6b:00.3) has no Latency Tolerance Reporting extended capability at all
and reports DevCap2 LTR-. Its upstream root port (00:08.1) is LTR- as well.
So the PCIe-layer variant I floated in my last mail is a dead end -- there
is no LTR register to write, and neither the endpoint nor the root port
advertises the mechanism.

That leaves an apparent contradiction I'd appreciate help squaring:

  - USB/xHCI layer: HCCPARAMS1 LTC = 1 (the controller advertises Latency
    Tolerance Messaging Capability).
  - PCIe layer: the same function is LTR- (no LTR capability at all).

So if I issue a Set LTV command (the driver-injected path you mentioned),
where does the xHC actually forward that aggregated tolerance value to the
fabric, given it has no PCIe LTR egress? Is there an internal sideband path
to the DF on these integrated AMD controllers, or does LTC only affect USB
link power states on this silicon -- in which case Set LTV would never reach
the Data Fabric?

If it's an internal/sideband path (Mario / Shyam?), a Set LTV PoC is still
worth trying. If LTC is purely USB-link-scoped here, it won't touch the DF
idle problem and I should look elsewhere. That distinction decides whether I
write the PoC at all.

Thanks,
Gordon Chen