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

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 8/8/26 00:29, Michal Pecio wrote:
> 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).

Tune urb->start_frame to be one step closer to reality could be a first step.
Give class drivers a chance to detect a difference in expected and reported
urb->start_frame

If there are already queued TDs when we receive an underrun event then add
urb->start_frame += ESIT to every queued URB

If there are no pending URBs then set flag to calculate new urb->start_frame
for the next URB when enqueued.

This is of course only for the ASAP case.
It won't be perfect, might drift especially if URBs are enqueued before we handle
the underrun event, but not too difficult to implement and better than current
situation

Thanks
Mathias