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 majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to