Re: [RFT PATCHv3 1/3] xhci: fix frame id calculation and checks for isoc URBs

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

On Fri, 7 Aug 2026 13:30:40 -0400, Dylan Robinson wrote:
> On Thu, Aug 6, 2026 at 8:07 PM Mathias Nyman
> <mathias.nyman@linux.intel.com> wrote:
> > With the hardware ep ctx check we will set the frame_id of the late
> > URB to point to the past, to the real time it was supposed to be
> > played back. xHC hardware will then trigger a 'missed service
> > event' for that TD as it was incapable of playing it at the correct
> > time, and then fast forward with MSE until it finds a TD with a
> > frame_id it can play, and play at the correct timeslot. Here we
> > lost the late data but playback stays in sync, as isoc transfer are
> > intended to work.  
> 
> I want to make sure I'm following along correctly. This is only true
> for host controllers that support CFC. On controllers without CFC,
> continuations are always submitted with SIA, so the controller can't
> reject expired TDs based on their Frame ID.

Yes, we are talking about the patch fixing CFC logic. You are right,
and you could only be more right with "because" in place of "so";
I tried treating old chips as if they had CFC, outcomes were weird.

> On Fri, Aug 7, 2026 at 12:48 PM Alan Stern
> <stern@rowland.harvard.edu> wrote:
> > The point under discussion is really about what happens when an
> > underrun occurs by accident -- for example, if the system is
> > temporarily overloaded.  In this situation there are two logical
> > choices of action if the class driver wants to keep the queue
> > running: Keep the alignment of iso_packet_descriptors and
> > (micro)frames as it was, which means assigning some new packets to
> > times in the past, or forget about the old alignment and start
> > fresh, which means assigning the next packet to the next available
> > future time slot.  The URB_ISO_ASAP flag is how the driver
> > communicates its choice to the HCD.  
> 
> How is the first choice realized when the host controller doesn't
> support CFC?

Currently it isn't, everything goes "ASAP" on xHCI 1.0 hardware and
underrun creates a gap. Another patch that Mathias prepared for 7.3
would align the first URB of each new stream, but nothing more.

We get the Ring Underrun event, so we know it happened. Drivers don't
know and they seem to have no trivial and robust way to detect it. To
them, URBs are completing, submissions are succeeding, all looks fine.

Potential solutions I could think of:

1. Somehow let drivers know that a fresh start is their only choice
   (some completion status, bogus start_frame, usb_submit_urb() error,
   callback, ...) and have them ready to deal with this (hard part).

2. Try to resync in xhci-hcd: quickly return newly submitted frames
   as -EXDEV until one is far enough into the future to reliably meet
   the IST and start a new "isoc data flow" from HW's point of view.
   
   Complicated by the fact that new URBs may be submitted after the
   underrun occurs but before our IRQ handler learns about it. Those
   are doomed to execute with some lag (unless unlinked). We could
   mark them -EXDEV or some such so that drivers don't trust them.

Not sure if this is desired by drivers, particularly the potential
inefficiency of the "complicated" part. I wouldn't be shocked if audio
(even specifically pro audio) was the only application in the world
that truly cares about exact scheduling.

I wonder if it should be recommended that drivers which don't care
always set URB_ISO_ASAP to opt out of any such insanity just in case?
I know that uvcvideo uses ASAP, for example.

Regards,
Michal