On Tue, 30 Jul 2013, 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? It's obvious that connecting or resetting a device forces the CPU to do extra work. That's always true, no matter what the device is used for. When the device is in use, the CPU activity will be higher than when the device isn't in use (other things being equal). That's also true for all devices. So I'm not sure what you're trying to get at, here. > 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 know anything about the iMX535, although there may be other people on this mailing list who do. The amount of work done by ehci-hcd should be more or less the same across all platforms. Of course, some platforms will perform that work more quickly than others. It's possible that the iMX535 really does take much longer to do the same amount of work, eating up a larger fraction of the total CPU time. It's easy to confirm that the EHCI hardware is being utilized: If your test program works and the data is transferred as expected, then the hardware is working. > > > > 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. Okay. Alan Stern -- 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
