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

[Brent Page <brentfpage@gmail.com>]

> On Apr 29, 2026, at 7:27 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> 
>> an additional csplit should be scheduled in Y0 of the next
>> frame - I'm guessing this is the sort of thing that would require an
>> FSTN?
> 
> No; FSTNs are for interrupt transfers.  But it would require extra siTD 
> nodes with backpointers, complicating the allocation and deallocation 
> algorithms.  That wouldn't be so hard to add, but I have never felt the 
> urge to do it.

Hmm, I may try to take a crack at it so that my previous proposal to inflate
the values of max_tt_usecs will always work if the bus just contains one
1023-byte iso-IN endpoint.  That is, the goal would be to fix

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

__________________________

>> The "case 2b"bullet point of 4.12.13.1 of the EHCI-1 spec says that
>> "This case can only occur for a very large isochronous IN... Software
>> must enforce this rule by scheduling the large transaction first. Large
>> is defined to be anything larger than 579 byte maximum packet size."
>> Is this being enforced at the moment in ehci-sched.c?
> 
> I don't think so.  Bandwidth is allocated to endpoints as they are 
> added, and the driver does not go back and try to rearrange the schedule 
> if something doesn't fit right.  It most certainly does not try to 
> change the allocation for endpoints that are currently in use.

It might be easy to do now that the budgeting is done working backwards
starting with the latest uframe (as of
https://marc.info/?l=linux-usb&m=131973404328622).  Pretty much, if the
byte count exceeds 579, see if the transaction can fit starting in
uframe 0.  If not, because the scheduling worked backwards to begin
with, there's no way that the schedule could be re-arranged to make the
large transaction fit while obeying the quoted rule.

Clearly, 579 is just about half the 1157
maximum_periodic_bytes_per_frame mentioned in 11.18.1, but I can't think
of why that's the threshold for a large transaction.  Sure, the
threshold guarantees that having 2 large transactions is impossible, but
that still doesn't seem to be important in the context of the reasoning
given in EHCI-1: 4.12.13.1.

>> Tangentially, why are there no csplits scheduled for the
>> 458-byte transaction enumerated in
>> https://bugzilla.kernel.org/show_bug.cgi?id=218544  ?  Tracing through
>> the ehci-sched.c code, I cannot figure out how you don't get at least
>> 3=ceil(458 * 7/6 / 188) 1s in the csplit mask.
> 
> Was that an isochronous-OUT transaction?  Those things don't use CSPLITs 
> at all.

Ah yeah, it was an iso-OUT.

From,
Brent Page