* [PATCH] usb: xhci: quirk for data loss in ISOC transfers
@ 2024-11-05 9:18 Raju Rangoju
2024-11-05 9:31 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Raju Rangoju @ 2024-11-05 9:18 UTC (permalink / raw)
To: linux-usb; +Cc: mathias.nyman, gregkh, linux-kernel, Raju Rangoju, stable
During the High-Speed Isochronous Audio transfers, xHCI
controller on certain AMD platforms experiences momentary data
loss. This results in Missed Service Errors (MSE) being
generated by the xHCI.
The root cause of the MSE is attributed to the ISOC OUT endpoint
being omitted from scheduling. This can happen either when an IN
endpoint with a 64ms service interval is pre-scheduled prior to
the ISOC OUT endpoint or when the interval of the ISOC OUT
endpoint is shorter than that of the IN endpoint. Consequently,
the OUT service is neglected when an IN endpoint with a service
interval exceeding 32ms is scheduled concurrently (every 64ms in
this scenario).
This issue is particularly seen on certain older AMD platforms.
To mitigate this problem, it is recommended to adjust the service
interval of the IN endpoint to exceed 32ms (interval 8). This
adjustment ensures that the OUT endpoint will not be bypassed,
even if a smaller interval value is utilized.
Cc: stable@vger.kernel.org
Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
---
drivers/usb/host/xhci-mem.c | 5 +++++
drivers/usb/host/xhci-pci.c | 14 ++++++++++++++
drivers/usb/host/xhci.h | 1 +
3 files changed, 20 insertions(+)
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index d2900197a49e..4892bb9afa6e 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1426,6 +1426,11 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
/* Periodic endpoint bInterval limit quirk */
if (usb_endpoint_xfer_int(&ep->desc) ||
usb_endpoint_xfer_isoc(&ep->desc)) {
+ if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) &&
+ usb_endpoint_xfer_int(&ep->desc) &&
+ interval >= 9) {
+ interval = 8;
+ }
if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
udev->speed >= USB_SPEED_HIGH &&
interval >= 7) {
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index cb07cee9ed0c..a078e2e5517d 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -284,6 +284,20 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
if (pdev->vendor == PCI_VENDOR_ID_NEC)
xhci->quirks |= XHCI_NEC_HOST;
+ if (pdev->vendor == PCI_VENDOR_ID_AMD &&
+ (pdev->device == 0x13ed ||
+ pdev->device == 0x13ee ||
+ pdev->device == 0x148c ||
+ pdev->device == 0x15d4 ||
+ pdev->device == 0x15d5 ||
+ pdev->device == 0x15e0 ||
+ pdev->device == 0x15e1 ||
+ pdev->device == 0x15e5))
+ xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_9;
+
+ if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x7316)
+ xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_9;
+
if (pdev->vendor == PCI_VENDOR_ID_AMD && xhci->hci_version == 0x96)
xhci->quirks |= XHCI_AMD_0x96_HOST;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index f0fb696d5619..fa69f7ac09b5 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1624,6 +1624,7 @@ struct xhci_hcd {
#define XHCI_ZHAOXIN_HOST BIT_ULL(46)
#define XHCI_WRITE_64_HI_LO BIT_ULL(47)
#define XHCI_CDNS_SCTX_QUIRK BIT_ULL(48)
+#define XHCI_LIMIT_ENDPOINT_INTERVAL_9 BIT_ULL(49)
unsigned int num_active_eps;
unsigned int limit_active_eps;
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] usb: xhci: quirk for data loss in ISOC transfers
2024-11-05 9:18 [PATCH] usb: xhci: quirk for data loss in ISOC transfers Raju Rangoju
@ 2024-11-05 9:31 ` Greg KH
2024-11-05 9:33 ` Greg KH
2024-11-05 14:13 ` Alan Stern
2 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2024-11-05 9:31 UTC (permalink / raw)
To: Raju Rangoju; +Cc: linux-usb, mathias.nyman, linux-kernel, stable
On Tue, Nov 05, 2024 at 02:48:50PM +0530, Raju Rangoju wrote:
> During the High-Speed Isochronous Audio transfers, xHCI
> controller on certain AMD platforms experiences momentary data
> loss. This results in Missed Service Errors (MSE) being
> generated by the xHCI.
>
> The root cause of the MSE is attributed to the ISOC OUT endpoint
> being omitted from scheduling. This can happen either when an IN
> endpoint with a 64ms service interval is pre-scheduled prior to
> the ISOC OUT endpoint or when the interval of the ISOC OUT
> endpoint is shorter than that of the IN endpoint. Consequently,
> the OUT service is neglected when an IN endpoint with a service
> interval exceeding 32ms is scheduled concurrently (every 64ms in
> this scenario).
>
> This issue is particularly seen on certain older AMD platforms.
> To mitigate this problem, it is recommended to adjust the service
> interval of the IN endpoint to exceed 32ms (interval 8). This
> adjustment ensures that the OUT endpoint will not be bypassed,
> even if a smaller interval value is utilized.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
What commit id does this fix? Should it go to stable kernels, and if
so, how far back?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] usb: xhci: quirk for data loss in ISOC transfers
2024-11-05 9:18 [PATCH] usb: xhci: quirk for data loss in ISOC transfers Raju Rangoju
2024-11-05 9:31 ` Greg KH
@ 2024-11-05 9:33 ` Greg KH
2024-11-07 11:26 ` Rangoju, Raju
2024-11-05 14:13 ` Alan Stern
2 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2024-11-05 9:33 UTC (permalink / raw)
To: Raju Rangoju; +Cc: linux-usb, mathias.nyman, linux-kernel, stable
On Tue, Nov 05, 2024 at 02:48:50PM +0530, Raju Rangoju wrote:
> During the High-Speed Isochronous Audio transfers, xHCI
> controller on certain AMD platforms experiences momentary data
> loss. This results in Missed Service Errors (MSE) being
> generated by the xHCI.
>
> The root cause of the MSE is attributed to the ISOC OUT endpoint
> being omitted from scheduling. This can happen either when an IN
> endpoint with a 64ms service interval is pre-scheduled prior to
> the ISOC OUT endpoint or when the interval of the ISOC OUT
> endpoint is shorter than that of the IN endpoint. Consequently,
> the OUT service is neglected when an IN endpoint with a service
> interval exceeding 32ms is scheduled concurrently (every 64ms in
> this scenario).
>
> This issue is particularly seen on certain older AMD platforms.
> To mitigate this problem, it is recommended to adjust the service
> interval of the IN endpoint to exceed 32ms (interval 8). This
> adjustment ensures that the OUT endpoint will not be bypassed,
> even if a smaller interval value is utilized.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
> ---
> drivers/usb/host/xhci-mem.c | 5 +++++
> drivers/usb/host/xhci-pci.c | 14 ++++++++++++++
> drivers/usb/host/xhci.h | 1 +
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index d2900197a49e..4892bb9afa6e 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1426,6 +1426,11 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
> /* Periodic endpoint bInterval limit quirk */
> if (usb_endpoint_xfer_int(&ep->desc) ||
> usb_endpoint_xfer_isoc(&ep->desc)) {
> + if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) &&
> + usb_endpoint_xfer_int(&ep->desc) &&
> + interval >= 9) {
> + interval = 8;
> + }
> if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
> udev->speed >= USB_SPEED_HIGH &&
> interval >= 7) {
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index cb07cee9ed0c..a078e2e5517d 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -284,6 +284,20 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> if (pdev->vendor == PCI_VENDOR_ID_NEC)
> xhci->quirks |= XHCI_NEC_HOST;
>
> + if (pdev->vendor == PCI_VENDOR_ID_AMD &&
> + (pdev->device == 0x13ed ||
> + pdev->device == 0x13ee ||
> + pdev->device == 0x148c ||
> + pdev->device == 0x15d4 ||
> + pdev->device == 0x15d5 ||
> + pdev->device == 0x15e0 ||
> + pdev->device == 0x15e1 ||
> + pdev->device == 0x15e5))
Any need/want to name these pci devices with something we can refer to
other than a hex value?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] usb: xhci: quirk for data loss in ISOC transfers
2024-11-05 9:18 [PATCH] usb: xhci: quirk for data loss in ISOC transfers Raju Rangoju
2024-11-05 9:31 ` Greg KH
2024-11-05 9:33 ` Greg KH
@ 2024-11-05 14:13 ` Alan Stern
2024-11-07 11:25 ` Rangoju, Raju
2 siblings, 1 reply; 6+ messages in thread
From: Alan Stern @ 2024-11-05 14:13 UTC (permalink / raw)
To: Raju Rangoju; +Cc: linux-usb, mathias.nyman, gregkh, linux-kernel, stable
On Tue, Nov 05, 2024 at 02:48:50PM +0530, Raju Rangoju wrote:
> During the High-Speed Isochronous Audio transfers, xHCI
> controller on certain AMD platforms experiences momentary data
> loss. This results in Missed Service Errors (MSE) being
> generated by the xHCI.
>
> The root cause of the MSE is attributed to the ISOC OUT endpoint
> being omitted from scheduling. This can happen either when an IN
> endpoint with a 64ms service interval is pre-scheduled prior to
> the ISOC OUT endpoint or when the interval of the ISOC OUT
> endpoint is shorter than that of the IN endpoint. Consequently,
> the OUT service is neglected when an IN endpoint with a service
> interval exceeding 32ms is scheduled concurrently (every 64ms in
> this scenario).
>
> This issue is particularly seen on certain older AMD platforms.
> To mitigate this problem, it is recommended to adjust the service
> interval of the IN endpoint to exceed 32ms (interval 8). This
Do you mean "not to exceed 32 ms"?
> adjustment ensures that the OUT endpoint will not be bypassed,
> even if a smaller interval value is utilized.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
> ---
> drivers/usb/host/xhci-mem.c | 5 +++++
> drivers/usb/host/xhci-pci.c | 14 ++++++++++++++
> drivers/usb/host/xhci.h | 1 +
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
> index d2900197a49e..4892bb9afa6e 100644
> --- a/drivers/usb/host/xhci-mem.c
> +++ b/drivers/usb/host/xhci-mem.c
> @@ -1426,6 +1426,11 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
> /* Periodic endpoint bInterval limit quirk */
> if (usb_endpoint_xfer_int(&ep->desc) ||
> usb_endpoint_xfer_isoc(&ep->desc)) {
> + if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) &&
> + usb_endpoint_xfer_int(&ep->desc) &&
> + interval >= 9) {
> + interval = 8;
> + }
This change ensures that the interval is <= 32 ms.
Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] usb: xhci: quirk for data loss in ISOC transfers
2024-11-05 14:13 ` Alan Stern
@ 2024-11-07 11:25 ` Rangoju, Raju
0 siblings, 0 replies; 6+ messages in thread
From: Rangoju, Raju @ 2024-11-07 11:25 UTC (permalink / raw)
To: Alan Stern; +Cc: linux-usb, mathias.nyman, gregkh, linux-kernel, stable
On 11/5/2024 7:43 PM, Alan Stern wrote:
> On Tue, Nov 05, 2024 at 02:48:50PM +0530, Raju Rangoju wrote:
>> During the High-Speed Isochronous Audio transfers, xHCI
>> controller on certain AMD platforms experiences momentary data
>> loss. This results in Missed Service Errors (MSE) being
>> generated by the xHCI.
>>
>> The root cause of the MSE is attributed to the ISOC OUT endpoint
>> being omitted from scheduling. This can happen either when an IN
>> endpoint with a 64ms service interval is pre-scheduled prior to
>> the ISOC OUT endpoint or when the interval of the ISOC OUT
>> endpoint is shorter than that of the IN endpoint. Consequently,
>> the OUT service is neglected when an IN endpoint with a service
>> interval exceeding 32ms is scheduled concurrently (every 64ms in
>> this scenario).
>>
>> This issue is particularly seen on certain older AMD platforms.
>> To mitigate this problem, it is recommended to adjust the service
>> interval of the IN endpoint to exceed 32ms (interval 8). This
>
> Do you mean "not to exceed 32 ms"?
>
>> adjustment ensures that the OUT endpoint will not be bypassed,
>> even if a smaller interval value is utilized.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
>> ---
>> drivers/usb/host/xhci-mem.c | 5 +++++
>> drivers/usb/host/xhci-pci.c | 14 ++++++++++++++
>> drivers/usb/host/xhci.h | 1 +
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index d2900197a49e..4892bb9afa6e 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -1426,6 +1426,11 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
>> /* Periodic endpoint bInterval limit quirk */
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> usb_endpoint_xfer_isoc(&ep->desc)) {
>> + if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) &&
>> + usb_endpoint_xfer_int(&ep->desc) &&
>> + interval >= 9) {
>> + interval = 8;
>> + }
>
> This change ensures that the interval is <= 32 ms.
That's correct, thanks for pointing it out. I'll take care of this in V2.
>
> Alan Stern
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] usb: xhci: quirk for data loss in ISOC transfers
2024-11-05 9:33 ` Greg KH
@ 2024-11-07 11:26 ` Rangoju, Raju
0 siblings, 0 replies; 6+ messages in thread
From: Rangoju, Raju @ 2024-11-07 11:26 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, mathias.nyman, linux-kernel, stable
On 11/5/2024 3:03 PM, Greg KH wrote:
> On Tue, Nov 05, 2024 at 02:48:50PM +0530, Raju Rangoju wrote:
>> During the High-Speed Isochronous Audio transfers, xHCI
>> controller on certain AMD platforms experiences momentary data
>> loss. This results in Missed Service Errors (MSE) being
>> generated by the xHCI.
>>
>> The root cause of the MSE is attributed to the ISOC OUT endpoint
>> being omitted from scheduling. This can happen either when an IN
>> endpoint with a 64ms service interval is pre-scheduled prior to
>> the ISOC OUT endpoint or when the interval of the ISOC OUT
>> endpoint is shorter than that of the IN endpoint. Consequently,
>> the OUT service is neglected when an IN endpoint with a service
>> interval exceeding 32ms is scheduled concurrently (every 64ms in
>> this scenario).
>>
>> This issue is particularly seen on certain older AMD platforms.
>> To mitigate this problem, it is recommended to adjust the service
>> interval of the IN endpoint to exceed 32ms (interval 8). This
>> adjustment ensures that the OUT endpoint will not be bypassed,
>> even if a smaller interval value is utilized.
>>
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Raju Rangoju <Raju.Rangoju@amd.com>
>> ---
>> drivers/usb/host/xhci-mem.c | 5 +++++
>> drivers/usb/host/xhci-pci.c | 14 ++++++++++++++
>> drivers/usb/host/xhci.h | 1 +
>> 3 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index d2900197a49e..4892bb9afa6e 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -1426,6 +1426,11 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
>> /* Periodic endpoint bInterval limit quirk */
>> if (usb_endpoint_xfer_int(&ep->desc) ||
>> usb_endpoint_xfer_isoc(&ep->desc)) {
>> + if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_9) &&
>> + usb_endpoint_xfer_int(&ep->desc) &&
>> + interval >= 9) {
>> + interval = 8;
>> + }
>> if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
>> udev->speed >= USB_SPEED_HIGH &&
>> interval >= 7) {
>> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
>> index cb07cee9ed0c..a078e2e5517d 100644
>> --- a/drivers/usb/host/xhci-pci.c
>> +++ b/drivers/usb/host/xhci-pci.c
>> @@ -284,6 +284,20 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
>> if (pdev->vendor == PCI_VENDOR_ID_NEC)
>> xhci->quirks |= XHCI_NEC_HOST;
>>
>> + if (pdev->vendor == PCI_VENDOR_ID_AMD &&
>> + (pdev->device == 0x13ed ||
>> + pdev->device == 0x13ee ||
>> + pdev->device == 0x148c ||
>> + pdev->device == 0x15d4 ||
>> + pdev->device == 0x15d5 ||
>> + pdev->device == 0x15e0 ||
>> + pdev->device == 0x15e1 ||
>> + pdev->device == 0x15e5))
>
> Any need/want to name these pci devices with something we can refer to
> other than a hex value?
Certainly, I'll try to see if device names can be used instead.
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-11-07 11:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-05 9:18 [PATCH] usb: xhci: quirk for data loss in ISOC transfers Raju Rangoju
2024-11-05 9:31 ` Greg KH
2024-11-05 9:33 ` Greg KH
2024-11-07 11:26 ` Rangoju, Raju
2024-11-05 14:13 ` Alan Stern
2024-11-07 11:25 ` Rangoju, Raju
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox