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

[Brent Page <brentfpage@gmail.com>]

> In the future, please tell your email client to wrap text lines after 72 
> columns or thereabouts.  Single-line paragraphs are hard to deal with.
Roger that

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

It is an open-source oscilloscope/function generator/spectrum
analyzer/logic analyzer called Labrador (https://espotek.com/labrador/)


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

I haven't been able to figure it out.  At first I thought that maybe it
led to SSPLITs being illegally scheduled in Y6 (USB-2 spec 11.18.14.1),
but I think that "if ((start % 8) >= 6) continue;" near line 1525 of
ehci-sched.c prevents that.  I checked, and that line was also in the
kernel at the time of the patch.


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

Yes, I am also worried about edge cases that could potentially crop up
as a result of my proposed patch.  With the patch, for one 1023-byte
isochronous-in endpoint, the CSPLIT mask is 11111100 and the SSPLIT mask
is 00000001.  I gleaned these from the debug log "ep 81: reserve iso @
0+8 (0.0+1) [1/21 us] mask fc01".  By all indications, the right-most
bit is earliest in time in these masks.  Also, I'm nearly certain that
these are in H-frame terms, as opposed to B-frame terms (illustrated in
Fig 4-21 of the EHCI-1 spec). This CSPLIT mask is consistent with the
first sentence of 11.18.4.3.c in USB-2, "For isochronous IN full-speed
transactions, for each microframe in which the full-speed transaction is
budgeted, a complete-split must be scheduled for each following
microframe. "  Ceil(1023/188)=6, so the transaction is budgeted to run
in uframes 1-6 (0-indexed H_frame terms), and csplits are appropriately
scheduled in uframes 2-7.  However, according to paragraph 3 of
11.18.4.3.c, 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?  And maybe not following this rule could lead to problems if there
are other transactions in the pipeline?

There are a few other things that I'm trying to figure out.  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 could see it possibly
becoming relevant if ehci-sched.c becomes more permissive towards large
transactions.  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.