Re: [RFT PATCH] xhci: fix frame id calculation for isoc transfer

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

Hi

On 5/21/26 17:20, Dylan Robinson wrote:
> On Mon, May 18, 2026 at 3:13 AM Michal Pecio wrote:
>> Underruns are the most important thing to test here
> 
> Agreed.
> 
>> Yes, this is very annoying because it's undetectable (without CFC).
>> It seems we need to handle Ring Underrun/Overrun events, somehow.
> 
> I think handling ring underrun and overrun events is probably the
> right approach here. I started putting together some tests, but ran
> out of time. I hope to spend some more time on it this weekend.
> 
> My current thinking is that for an URB submitted after an underrun or
> overrun has actually occurred, but before the xrun event is reported
> or handled, there will be no way to determine its true start frame,
> since it will have been submitted with SIA set.
> 
> However, because completions are processed in order, the HCD should
> still be able to determine by completion time whether an xrun occurred
> before completion of the URB, and could therefore indicate to the
> completion handler that the reported start_frame is uncertain.
> 
> Hopefully, USB drivers could then detect the discontinuity either:

I've been working on a solution like this

If URB is submitted after a overrun/underrun then re-calculate its
urb->start_frame based on running microframe index

If xhci driver handles the overrun/underrun event after a new URB is
already submitted then kick the urb->start_frame forward by one ESIT

If xHCI CFC is used then don't touch urb->start_frame

I promised to focus on xHCI DbC issues next week so I'll share v3 now
even if it again is not tested at all, and has some 'FIXME' cases left.
First two patches are the same as v2.

Code should work and be testable

It does change a bit how MSE (+ skip flag) + overrun/underrun cases are
handled. I haven't fully yet figured out all those cases, hopefully this
doesn't make it much worse.

Would be good to get Michal's comment on that

I
> 
> Not to repeat myself too much, but I think this discussion also helps
> illustrate the value of allowing drivers to supply a specified
> start_frame, since xrun events become much less likely when scheduling
> sufficiently far into the future. That said, I think it is worth
> sorting out these underlying frame id calculation issues first.

Maybe we could add something like a 'delay_start_by_intervals' to the
URB? telling the host that class driver wishes stream to start n intervals
after usb was submitted.

Thanks
Mathias