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

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

On Wed, 29 Apr 2026 13:56:01 -0400, Alan Stern wrote:
> On Wed, Apr 29, 2026 at 11:36:04AM +0200, Michal Pecio wrote:
> > The host must schedule SSPLITs assuming no bit-stuffing to prevent TT
> > buffer underrun on long OUT packets. Assuming minimum/no packet headers
> > further minimizes downstream idle. TTs are required to buffer this.  
> 
> There's a difference between scheduling and budgeting; it sounds like 
> you are mixing them up.  Roughly speaking, scheduling refers to when 
> transactions actually take place whereas budgeting is concerned with 
> when a full/low-speed transaction's SSPLITs and CSPLITs take place.

I meant "scheduling" in the sense 11.18.2 and fig 11-61 use this term -
deciding which uframe to execute SSPLITs in. Of course it's practically
equivalent to "budgeting" the downstream transaction, so fair enough.

And what I really meant is that OUT SSPLITs must carry 188 byte payload
each and their count must be appropriate, that's all. If EHCI HW always
sends 188 bytes (if available) without babysitting, that's great.

> > (BTW, periodic transfers should occur before async. Could the TT run
> > out of periodic, do async, then get an unexpected periodic
> > transaction in the next uframe? What happens?)  
> 
> This can't happen as long as each SSPLIT transfers the smaller of 188 
> bytes or the number of bytes remaining.

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.

So it seems that TT must cope with gaps. Maybe it's allowed to fill
them with async? I don't know, I haven't found clear answer yet.

> > Including packet headers for SSPLIT scheduling seems harmless unless
> > overestimated, but apparently it's not required. TTs must cope.  
> 
> Again, budgeting not scheduling, but yes.

As mentioned in the followup correction email, it seems to be required.
If nothing else, it ensures the 16 transactions per uframe limit. Not
sure if blind budgeting solely by limiting data bytes and transactions
per uframe would work as well. Probably not worth finding out.

> > BTW, does ehci-hcd support scheduling CSPLITs to Y0 of the next
> > frame? It's an edge case which likely won't occur with one 1023
> > byte endpoint, but it may occur with more periodic endpoints and
> > unlucky bit stuffing or with periodic BW limit carefully increased
> > for testing purposes.  
> 
> It does not support CSPLITs in Y7 of the current frame or Y0 of the
> next frame.  This is one of those limitations just mentioned.

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.

IOW, you play Russian Roulette with bit stuffing if you enable this.

> 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.

Regards,
Michal