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

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

> On Mon, Apr 27, 2026 at 06:24:58PM -0700, Brent Page wrote:
> > I recently encountered the ENOSPC error mentioned here
> > (https://lkml.org/lkml/2013/2/19/482) when trying to communicate
> > with a full-speed peripheral with one isochronous–in endpoint with
> > a wMaxPacketSize of 1023.  N.b., that patch was reverted
> > (https://lkml.org/lkml/2013/6/18/458).  I think it should be tried
> > again with a different approach.

Out of curiosity, what sort of device? This bug used to annoy me too at
one point, but my device was a DSL modem, not easy to experiment with.

On Tue, 28 Apr 2026 17:19:01 -0400, Alan Stern wrote:
> Section 11.18.1 is a marvel of inconsistency.  The text and the
> figure caption say that the estimate assumes no bit-stuffing, but the
> formula clearly includes a 6/7 bit-stuffing factor.

I don't think it's inconsistent, it makes sense the way you explain.

> I think what it means is that the maximum number of periodic data
> bytes that can be scheduled for one frame on a full-speed bus is
> 1157, since transaction scheduling does have to take bit-stuffing
> into account.  See the formulas in section 5.11.3.  Even that value
> is an overestimate, because it does not reserve time for packet
> headers and other forms of overhead.  Figure 11-60 shows the
> budgeting estimate for those 1157 bytes, under the assumption that
> they do not need to be bit-stuffed.

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.

(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?)

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

Separately, for go/no-go (ENOSPC) decisions, the host should consider
all overhead in order to guarantee >10% downstream time for async.
Max payload is still close to 1157 because it may be just two packets.

That's how I see it.

> Since the value of stream->ps.tt_usecs calculated in
> iso_stream_init() does include the 7/6 bit-stuffing factor, it makes
> sense to adjust the us-per-uframe values to reverse that effect for
> purposes of budgeting. It would be more in the spirit of the spec to
> do the budgeting in terms of bytes rather than microseconds, but
> since it's all estimates anyway this shouldn't matter.

Not entirely sure about it, *if* these computations are later used to
schedule SSPLIT or CSPLIT transactions. That needs to be exact IMO.

Does anyone understand why the previous attempt at enabling 1023 byte
isoc IN resulted in isoc OUT corruption?

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.

Regards,
Michal