Re: [Bug 220748] usb: xhci_queue_isoc_tx_prepare ignore start_frame and always assumes URB_ISO_ASAP is set

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

On Thu, 7 May 2026 12:17:00 -0400, Dylan Robinson wrote:
> On Wed, May 6, 2026 at 10:39 PM Alan Stern wrote:
> > For one thing, that would be very impractical, as every driver using
> > isochronous transfers would then have to be modified.  
> 
> Maybe adding a new flag would make more sense then.

It would surely need to be optional on per-URB basis, to avoid updating
all drivers and to enable sub-1ms URBs without gaps on HW like xHCI,
where we can't request starting frame with microframe granularity.

I suppose Windows/OSX have to be doing it this way too?

> I was confused because the documentation regarding URB_ISO_ASAP
> describes this behavior.
> 
> - For ISO there are two startup behaviors: Specified start_frame or ASAP.
> - For ASAP set ``URB_ISO_ASAP`` in transfer_flags.
> 
> However, it looks like URB_ISO_ASAP actually means something
> different: that the URB can be delayed. Is that correct?

Yes, there are many errors in Documentation/driver-api/usb. I thought
about fixing this when the bug was opened, but maybe it's better to
wait till the dust settles around xhci-hcd.

Alan pointed out that kerneldocs are more up to date, but there is
still a crucial error there: on ehci-hcd, an URB submitted too late
completes with -EXDEV instead of the submission failing with -EXDEV.
And it seems we should strive for the same in xhci-hcd, instead of
silently rescheduling such URBs to run later.

> For an ongoing stream I would expect that submitting a start_frame
> that is discontinuous and in the past would result in either a
> submission failure or immediate completion with an error status. Such
> an error would provide useful feedback to the driver because its
> occurrence would mean the stream is no longer synchronized as the
> driver expects.

The idea is that in absence of bugs (which xhci-hcd has plenty), the
stream is always synchronized as long as all URBs are completing
successfully and resubmitting before returning from their complete()
callback. Drivers don't need to "start_frame++" for this to work.

If an IRQ delay causes resubmission to be late, some or all "frames"
of the URB will complete with EXDEV.

Also, I believe such completion should occur in submission order, i.e.
only after all URBs submitted earlier have completed in some manner.

> If the driver requests a specific start frame, it should be the
> driver's responsibility to ensure it is a valid frame within the valid
> scheduling window. If the requested start frame is invalid or outside
> the host controller driver's valid scheduling window, the request
> should fail. This would be more helpful than silently fixing it upon
> submission.

There would need to be some convention how to deal with bInterval > 1.
Such endpoint doesn't use every (micro)frame and can't be scheduled
into any arbitrary one.

In such cases, xHCI spec only permits the first frame of every ESIT to
be specified, but the actual transfer will take place anywhere within
the ESIT, and we don't know when. See 4.11.2.5.

Drivers would need to be aware of such low level details.

> Currently, with non-CFC host controllers, there is no way to determine
> which frame a transfer occurs in. This is because without CFC, the
> start_frame returned in the URB is only approximate.

That's partly a bug.

Filling start_frame is only implemented for CFC HCs. On non-CFC we
could still set start_frame accurately on the first URB and later
increment it blindly. What we cannot do is ensure that the HW will
stay in sync after Missed Service. All bets are off after EXDEV.

On non-CFC we would also be forced to ignore any driver-specified
start_frame except at the beginning of a new stream.

> Currently, there is no straightforward way to inform the xhci driver
> whether a URB represents a stream start or continuation. This makes it
> difficult to detect missed service intervals or other scheduling
> discontinuities.

It's supposed to be implied that submission from a complete() callback
is a continuation. I believe one of the submitted patches fixes that.

Regards,
Michal