According to the USB 2.0 specification, 19 full speed interrupt endpoints (@ 64 bytes) can be scheduled. I have a couple of questions about this specification and the Linux kernel's implementation:
1. Does this number take the USB requirement that "no more than 90% of any frame be allocated for periodic full-speed transfers" into account? 2. Does the full speed limitation apply if full speed devices are connected to high speed hubs? 2a. If the high speed limitation is used: Does the scheduler multiplex each full speed device's split data packets over the 8 available micro-frames? We performed some testing, but I don't want to make assumptions on these results alone. Setup #1: Kernel 3.10.0 Connect 6 USB devices (each with 2 IN and 1 OUT interrupt endpoints @64 bytes) to USB 1.1 full speed hubs to a PC USB 2.0 port. The test application can communicate with all 18 endpoints. When we connected a 7th device, the test application is unable to open and access the device. This makes sense because that would be 21 full speed endpoints. Setup #2: Kernel 3.10.0 Connect 7 USB devices (each with 2 IN and 1 OUT interrupt endpoints @64 bytes) to USB 2.0 high speed hubs to a PC USB 2.0 port. The test application can communicate with all 21 endpoints. This appears to violate the full speed limitation; however, it wouldn't be violating the high speed limitation of 63 endpoints per micro-frame. Thanks for the help, -Nate -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
