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

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 1 Jun 2026 13:44:25 +0000, Gordon Chen wrote:
> 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.

Hi,

I wrote a small debugfs interface for people to play with, it just
issues the Set LTV command with given BELT parameter. You know it
worked when you see "INFO unknown command type 20" in dmesg.

See USB 3.2 spec 8.5.6.2 for details of the BELT value. TL;DR:

1024 + latency_us, must be given in decimal and latency_us <= 1023

The spec says this only matters for non-isoc endpoints, so I guess HW
is expected to be smart enough to manage it itself when isoc is active.
Ergo, it will probably make jack all difference and we can comfortably
go back to blaming AMD.

Please also try 7.3-rc2, just in case you are actually running into
known (hopefully fixed) problems with isoc URB scheduling.

Regards,
Michal

---

diff --git a/drivers/usb/host/xhci-debugfs.c b/drivers/usb/host/xhci-debugfs.c
index 0f6f97cfe0b0..5f370e5e57ff 100644
--- a/drivers/usb/host/xhci-debugfs.c
+++ b/drivers/usb/host/xhci-debugfs.c
@@ -670,6 +670,70 @@ static void xhci_debugfs_create_ports(struct xhci_hcd *xhci,
 	}
 }
 
+static int belt_show(struct seq_file *s, void *unused)
+{
+	return 0;
+}
+
+static ssize_t belt_write(struct file *file,  const char __user *ubuf,
+			       size_t count, loff_t *ppos)
+{
+	struct seq_file         *s = file->private_data;
+	struct xhci_hcd		*xhci = (struct xhci_hcd *)s->private;
+	struct xhci_command	*cmd;
+	u16			belt;
+	int			ret;
+
+	/* Decimal number */
+	ret = kstrtou16_from_user(ubuf, count, 10, &belt);
+	if (ret)
+		return ret;
+
+	cmd = xhci_alloc_command(xhci, true, GFP_KERNEL);
+	if (!cmd)
+		return -ENOMEM;
+
+	spin_lock_irq(&xhci->lock);
+	ret = xhci_queue_vendor_command(xhci, cmd, 0, 0, 0, TRB_TYPE(TRB_SET_LT) | belt << 16);
+	if (!ret)
+		xhci_ring_cmd_db(xhci);
+	spin_unlock_irq(&xhci->lock);
+	if (ret)
+		goto free;
+
+	wait_for_completion(cmd->completion);
+
+	switch (cmd->status) {
+	case COMP_SUCCESS:
+		ret = count;
+		break;
+	case COMP_TRB_ERROR:
+		ret = -EBADR;
+		break;
+	case COMP_PARAMETER_ERROR:
+		ret = -EBADRQC;
+		break;
+	default:
+		ret = -EIO;
+	}
+free:
+	xhci_free_command(xhci, cmd);
+	return ret;
+}
+
+static int belt_open(struct inode *inode, struct file *file)
+{
+	return single_open(file, belt_show, inode->i_private);
+}
+
+static const struct file_operations belt_fops = {
+	.open			= belt_open,
+	.read			= seq_read,
+	.write			= belt_write,
+	.llseek			= seq_lseek,
+	.release		= single_release,
+};
+
 static int xhci_port_bw_show(struct xhci_hcd *xhci, u8 dev_speed,
 				struct seq_file *s)
 {
@@ -901,6 +965,8 @@ void xhci_debugfs_init(struct xhci_hcd *xhci)
 
 	xhci->debugfs_slots = debugfs_create_dir("devices", xhci->debugfs_root);
 
+	debugfs_create_file("belt", 0666, xhci->debugfs_root, xhci, &belt_fops);
+
 	xhci_debugfs_create_ports(xhci, xhci->debugfs_root);
 
 	xhci_debugfs_create_bandwidth(xhci, xhci->debugfs_root);