Linux USB
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: dylan_robinson@motu.com, linux-usb@vger.kernel.org,
	mathias.nyman@intel.com, stern@rowland.harvard.edu
Subject: Re: [RFT PATCH] xhci: fix frame id calculation for isoc transfer
Date: Tue, 12 May 2026 11:08:10 +0200	[thread overview]
Message-ID: <20260512110810.17fbde0a.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260511192105.3756809-1-mathias.nyman@linux.intel.com>

On Mon, 11 May 2026 22:21:05 +0300, Mathias Nyman wrote:
> Always calculate estimated start frame, and set urb->start_frame

This may cause driver developers lots of grey hair when running on old
(non-CFC, xHCI 1.0, USB 3.0, "gen 1") HCs where nothing is done to
enforce frame number correctness so far.

Writing obviously bogus urb->start_frame at least was obvious :)

> Fix valid frame window start and end calculation to match xhci
> spec 4.11.2.5
> 
> Don't inclease frame id with 1 if a URB mod transfer is queued late.
> Queue it with next expected frame ID but print a message if URB is
> next expected frame id does not fir valid frame window range (URB mid
> transfer is queued late)

Failing to meet the IST is not the same as violating the 895ms limit.
The former may (or may not) cause the TD to complete with MSE instead
of Success in its interval. The latter is apparently supposed to cause
MSE completion when the HC reads the TD, even though the IST was met.

A particularly fascinating case is period > 895ms; it seems that xHCI
only allows submitting shortly before interval boundary, or "SIA".

Another nice one is ESIT >= 4096ms - exceeding MFINDEX limit.

That being said, I found that validating end_frame_id before enqueuing
doesn't take more effort than generating these warnings, and I think it
would be more productive - drivers know that their submission is lost
cause, instead of getting bizarre completions later.

As for ignoring the IST, my ASMedia chips seem to take it well. And
they specify absurdly long IST of 2ms, while actually running with
3x0.5ms URBs or less. The "less" tends to be glitchy, but I'm not yet
sure if it's xHCI problem or snd-usb-audio / other software problem.

For example, I noticed that snd-usb-audio running with 2 URBs sometimes
only resubmits when both are completed, an obviously bad idea, while at
other times it runs well for a long time. Still don't know why.

Regards,
Michal

  parent reply	other threads:[~2026-05-12  9:08 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-04 21:25 [Bug 220748] New: usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set bugzilla-daemon
2025-11-05  8:40 ` [Bug 220748] " bugzilla-daemon
2025-11-05  8:48 ` bugzilla-daemon
2025-11-05  8:53 ` bugzilla-daemon
2025-11-05  9:06 ` bugzilla-daemon
2025-11-05 15:47 ` bugzilla-daemon
2025-11-05 18:28 ` bugzilla-daemon
2025-11-05 18:30 ` bugzilla-daemon
2025-11-05 20:16 ` bugzilla-daemon
2025-11-05 21:18 ` bugzilla-daemon
2025-11-06  3:52 ` bugzilla-daemon
2025-11-06  8:27 ` bugzilla-daemon
2025-11-06  8:35 ` bugzilla-daemon
2025-11-06 15:03 ` bugzilla-daemon
2025-11-08 10:33 ` bugzilla-daemon
2025-11-08 16:09 ` bugzilla-daemon
2025-11-10 10:23 ` bugzilla-daemon
2025-11-10 10:42 ` bugzilla-daemon
2026-05-04 23:53 ` bugzilla-daemon
2026-05-04 23:54 ` bugzilla-daemon
2026-05-05  1:14 ` bugzilla-daemon
2026-05-05  9:59 ` bugzilla-daemon
2026-05-05 17:09 ` bugzilla-daemon
2026-05-05 17:10 ` bugzilla-daemon
2026-05-05 17:10 ` bugzilla-daemon
2026-05-05 17:13 ` bugzilla-daemon
2026-05-06 13:32 ` bugzilla-daemon
2026-05-06 15:03 ` bugzilla-daemon
2026-05-07  2:38   ` Alan Stern
2026-05-07 16:17     ` Dylan Robinson
2026-05-07 17:24       ` Alan Stern
2026-05-07 21:16         ` Dylan Robinson
2026-05-08  3:02           ` Alan Stern
2026-05-08 17:20             ` Dylan Robinson
2026-05-09  1:25               ` Alan Stern
2026-05-09 22:12               ` Michal Pecio
2026-05-10 12:39                 ` Dylan Robinson
2026-05-11 19:21                   ` [RFT PATCH] xhci: fix frame id calculation for isoc transfer Mathias Nyman
2026-05-11 19:36                     ` Mathias Nyman
2026-05-12  9:08                     ` Michal Pecio [this message]
2026-05-07 21:54       ` [Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set Michal Pecio
2026-05-08  3:09         ` Alan Stern
2026-05-08  9:41           ` Michal Pecio
2026-05-08 14:54             ` Alan Stern
2026-05-08 21:39         ` Dylan Robinson
2026-05-09 11:10           ` Michal Pecio
2026-05-09 20:18             ` Dylan Robinson
2026-05-11 19:15 ` bugzilla-daemon

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=20260512110810.17fbde0a.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=dylan_robinson@motu.com \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=stern@rowland.harvard.edu \
    /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