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

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, May 08, 2026 at 01:20:04PM -0400, Dylan Robinson wrote:
> Perhaps, rather than treating this as a "specified start frame", it
> would be better to think of it as a "specified start service
> interval".
> 
> If a driver requests a start frame that is not specifically available
> within the periodic schedule, it seems reasonable for the HCD to place
> the transfer at another valid position within that same service
> interval. The actual start frame used could then still be reported
> back through the completed URB, which can be inspected by the driver
> if it needs to know the precise scheduling decision.
> 
> For endpoints with larger polling intervals, this "nearest valid start
> frame" approach seems appropriate, since the device cannot expect
> timing granularity finer than its polling interval anyway.

That makes sense, and it should be doable.  At least for ehci-hcd, and 
likely for xhci-hcd as well.

> > What if the HCD only supports scheduling up to 256 ms in the future, but
> > the driver asks for a start frame that is 400 ms in the future?
> 
> On macOS and Windows the submission would fail with an error. That
> seems appropriate.
> 
> For example, macOS has the following return status:
>  - kIOReturnIsoTooNew (Too far in the future)
>  - kIOReturnIsoTooOld (Too far in the past)
> 
> On Windows, the status of the URB is set to USBD_STATUS_BAD_START_FRAME.

We ought to be able to do something similar.

> > What if the periodic schedule is already full and there is no bandwidth
> > remaining to schedule the new stream?  How will the driver find out?  By
> > getting a different error code from the URB submission?
> 
> The driver needs to know if the stream cannot start. What happens currently?

Submission fails with a -ENOSPC error code.  On the other hand, if the 
schedule is set up when the alternate setting is installed, and that 
can't be done, then the usb_set_interface() call fails.

> We can ultimately only provide functionality within the limits of what
> the host platform and HCD are capable of supporting.
> 
> In general, the more precise and predictable the scheduling behavior
> is, the lower latency and better overall performance the driver can
> achieve. Falling back to unspecified scheduling may allow basic
> functionality to work, but at the cost of increased buffering, reduced
> synchronization accuracy and longer startup delay.

All right, let's say what Mathias and Michal have to say about this.

Alan Stern