From: "Rangoju, Raju" <raju.rangoju@amd.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: mathias.nyman@intel.com, gregkh@linuxfoundation.org,
stable@vger.kernel.org
Subject: Re: [PATCH v4] usb: xhci: quirk for data loss in ISOC transfers
Date: Wed, 26 Mar 2025 09:31:03 +0530 [thread overview]
Message-ID: <81c922e6-8848-47a2-bd54-1a9f8b1dbdc0@amd.com> (raw)
In-Reply-To: <1c44ff09-dd26-489d-9867-8d300a3574ac@linux.intel.com>
On 1/29/2025 6:08 PM, Mathias Nyman wrote:
Hi Mathias,
Thanks for reviewing the patch and apologies for delayed response.
> On 27.1.2025 14.06, 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 not 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>
>> ---
>> Changes since v3:
>> - Bump up the enum number XHCI_LIMIT_ENDPOINT_INTERVAL_9
>>
>> Changes since v2:
>> - added stable tag to backport to all stable kernels
>>
>> Changes since v1:
>> - replaced hex values with pci device names
>> - corrected the commit message
>>
>> drivers/usb/host/xhci-mem.c | 5 +++++
>> drivers/usb/host/xhci-pci.c | 25 +++++++++++++++++++++++++
>> drivers/usb/host/xhci.h | 1 +
>> 3 files changed, 31 insertions(+)
>>
>> diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
>> index 92703efda1f7..d3182ba98788 100644
>> --- a/drivers/usb/host/xhci-mem.c
>> +++ b/drivers/usb/host/xhci-mem.c
>> @@ -1420,6 +1420,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;
>
> Commit message describes this as an issue triggered by High-Speed Isoc In
> endpoints that have interval larger than 32ms.
>
> This code limits interval to 32ms for Interrupt endpoints (any speed),
> should it be isoc instead?
The affected transfer is ISOC. However, due to INT EP service interval
of 64ms causing the ISO EP to be skipped, the WA is to reduce the INT EP
service to be less than 64ms (32ms).
>
> Are Full-/Low-speed devices really also affected?
>
No, Full-/Low-speed devices are not affected. Thanks for reviewing, I'll
re-spin the patch adding this change.
> Thanks
> Mathias
>
next prev parent reply other threads:[~2025-03-26 4:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-27 12:06 Raju Rangoju
2025-01-29 12:38 ` Mathias Nyman
2025-03-26 4:01 ` Rangoju, Raju [this message]
2025-03-26 6:47 ` Michał Pecio
2025-03-27 6:38 ` Rangoju, Raju
2025-03-27 9:34 ` Michał Pecio
2025-03-27 11:02 ` Rangoju, Raju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=81c922e6-8848-47a2-bd54-1a9f8b1dbdc0@amd.com \
--to=raju.rangoju@amd.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mathias.nyman@intel.com \
--cc=mathias.nyman@linux.intel.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®