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

[Brent Page <brentfpage@gmail.com>]

Hello,

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.  Namely, I propose multiplying the max_tt_usecs values in ehci-sched.c by the worst-case bit-stuffing multiplier, 7/6, making them
- max_tt_usecs[] = { 125, 125, 125, 125, 125, 125, 30, 0 };
+ max_tt_usecs[] = { 145, 145, 145, 145, 145, 145, 35, 0 };
After I make this simple change, along with a few other 125->145 substitutions in ehci-sched.c, my linux tablet is able to establish a steady data link with my 1023-byte-endpoint peripheral.
Obviously, 145 us is longer than a microframe, so this best-case budget will often not reflect the times when transactions occur.  But, this situation is consistent with the best-case budget in section 11.18.1 of the USB-2 spec, in which 1157 data-bytes are scheduled to occur as though no bit-stuffing necessary (i.e., the 188 bytes = 12 megabits/second * (1 byte/8 bits)* 0.125 ms that can run on the full-speed bus in a microframe are all taken taken be data-bytes).  So, after the patch, max_tt_usecs is the same as the spec's best-case budget but is just scaled by (125 us / 188 bytes) = 1/(12 megabits/s) and by the 7/6 bit-stuffing multiplier to reflect the fact that the scheduling code works in bit-stuffing-inclusive bus-time instead of data-bytes.
To try to further dispel concerns stemming from 145 > 125, I'll point out that, if a given microframe is budgeted close to 145 us of TT time using the calculations in ehci-sched.c, it will sometimes be the case that the associated transactions take less than 125 us, so they will run successfully within the microframe.  In particular, this will happen if the transactions require very little bit stuffing.

Previous EHCI scheduling work has also noted that obeying the spec entails the possibility of overcommitting the TT.  See the comments below from https://marc.info/?l=linux-usb-devel&m=115933214319141&w=4

+/* Because EHCI cannot issue ssplits in uframe 7 and USB 2.0 does not
+   allow ssplits in uframe 6, EHCI can only generate an efficient FS
+   frame by scheduling according to best-case (not worst-case) bit
+   stuffing.  Thus we purposely 'overcommit' the FS frame budget
+   within the buffering ability of the TT to buffer, and within the
+   limits of the 90/10 rule.  The TT will catch up in the microframes
+   where we cannot issue start splits.
+*/

"/* Scheduling through a TT is done by byte counting, not usec
+	  counting.  Because we cannot issue a FS/LS start split in
+	  uFrame 6 or 7, the only way to get anywhere near a full 90%
+	  of a FS frame for periodic transactions is to 'overcommit'
+	  the FS scheduling of each microframe [when considered by
+	  usecs needed for the transfer].  This is not actually
+	  overcommitting as the TT will buffer the 'excess' from any
+	  uFrame and schedule it to transmit in a later uFrame. USB
+	  2.0 11.18.4: "Scheduling of split transactions is done by
+	  the host (typically in software) based on a best-case
+	  estimate of how the full-/low-speed transacitons can be run
+	  on the downstream facing bus." */"

From,
Brent Page