Feature #4914


support for second E1 line in firmware

Added by laforge over 1 year ago. Updated 4 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:
Actions #1

Updated by tnt 5 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 50

Kind of hit an issue ... XHCI.

The minimal wMaxPacketSize we can use is 292. This is 256 byte nominal size, 32 byte added because we might need to transfer 1 more frame from time to time because usb clock is not synced to E1 clock and then 4 bytes for the header. The overhead of an isochronous transfer on the bus is 9 bytes ( 2 SYNC bytes, 2 PID bytes, 2 Endpoint + CRC bytes, 2 CRC bytes, and a 1-byte interpacket delay )

We need 4 endpoints so that's a total of 4 * (292 + 9) = 1204 bytes which is only ~ 80 % of the available frame time. Spec says isoc can take up to 90% so there is some margin.

There is also the interrupt and feedback endpoints that have to be scheduled but those are not everyframe so they can be interleaved and still leave plenty of room to fit some bulk and control transfers.

And this works fine on OHCI/EHCI controllers.

But on XHCI all the scheduling logic is handled inside the controller, controlled by some internal firmware we can't touch ... and in the controllers I have that firmware refuses that configuration with "not enough bandwidth".

Actions #2

Updated by tnt 4 months ago

  • % Done changed from 50 to 90

Patches for this are in review in gerrit.

The XHCI issue remains, but on good systems it works fine, tested for several hours with no issues.

Actions #3

Updated by tnt 4 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)