> > The driver has to set up the data structures for the transfers, which includes > scheduling when the SSPLIT and CSPLIT transactions will occur and figuring > out how much bandwidth they will consume. The transactions themselves > are handled entirely by the EHCI hardware. >
So you would expect a temporary CPU increase when a device is connected or reset since the scheduler will need to set up when the packets will be transferred. Once this is complete, the CPU should return to a lower amount as the EHCI hardware would be processing the various packet sending: setup tokens, ACK/NAK handshaking, and split packets? I ask because we are seeing much higher constant CPU usage on our target hardware (iMX535) than we are seeing on the test PC. Do you have any recommendations for a good way to confirm the target EHCI hardware is being utilized? Is there a location to instrument in one of the ehci host files (ehci-hcd.c or ehci-q.c)? > > > I don't see how you could have gotten more than 15 interrupt > > > endpoints running at the same time unless the endpoints' bInterval > > > value was larger than 1. > > > > > On all 7 devices, the IN and OUT interrupt endpoints have bInterval = > > 1 wMaxPacketSize = 64. > > Do you think this is worth pursuing? It sounds like a bug, although it might > not be. > We will re-run the tests with more rigor to confirm the results. I will post the details. -Nate -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
