On Tue, Jul 30, 2013 at 09:33:39PM +0000, Stoddard, Nate (GE Healthcare) wrote: > > > > > 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)? > When the transfer begins, the things are almost the same for all SoCs. The possible reason is you may use an old kernel (2.6.35), and EHCI core is improved. At your old email, you said the cpu utilities will be less at higher kernel version at PC. I think the best way is using newest kernel and newest libusb. Try to find a mx53 board which is supported by upstream kernel, and re-do the test. > > > > > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
