Re: TT budgeting for EHCI; accommodate 1023-byte full-speed isochronous–in endpoints

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

On Wed, 29 Apr 2026 15:32:07 -0400, Alan Stern wrote:
> On Wed, Apr 29, 2026 at 09:24:08PM +0200, Michal Pecio wrote:
> > Yes, but per spec transfers are budgeted based on wMaxPacketSize and
> > actual SSPLITs may be shorter, while subsequent transfers may still
> > remain budgeted into a future uframe.  
> 
> The actual SSPLIT will be shorter only if it is a short transfer
> (that is, shorter than the maxpacket size).  Hence there won't be a
> subsequent transactions in a future uframe, even if some are budgeted
> there.

Not for this endpoint, but another one may be budgeted next. Say, two
isoc endpoints with 188 byte budget each. In Y0 EP1 moves one byte and
leaves some time unused, near the end of Y0 EP2 SSPLIT arrives for Y1.

Seems legal, so I don't think TT can assume that it has seen the end of
periodic transfers when its queue runs empty. IDK what it does then.

> > Then I think it doesn't support 1023 byte packets at all.
> > 1023/188=5.4 and if worst case bit stuffing factor is 7/6 then up
> > to 6.3 uframes of transfer time. Completion in Y5 or Y6 and CSPLIT
> > required in Y7.  
> 
> For iso-IN, that's right.
> 
> > IOW, you play Russian Roulette with bit stuffing if you enable
> > this.  
> 
> The driver is not perfect.  No doubt about it.

This raises question how much sense there is in patches enabling such
endpoints. Maybe worth it for OUT, if they currently don't work. Or for
fans of RR, if there are no other side effects :)

> > > Adding support would complicate the driver considerably and yield
> > > relatively little benefit now that xHCI is so widespread.  
> > 
> > Fun fact: not all xHCI supports it either.  
> 
> Heh.  I'm a little surprised the xHCI implementors were able to do
> all this scheduling in hardware in the first place; it's not an easy 
> problem.

It's firmware on some 8051 or similar monstrosity. Often upgradeable.
Often upgrades exist, presumably for valid reasons.

Regards,
Michal