2014-08-01 13:33 GMT+02:00 Peter Stuge <peter@xxxxxxxx>: > Hi, > > Your kernel is ancient. You should either ask your kernel supplier > for support or switch to using a current upstream kernel if you want > help here. > > I can just give some general libusb advice. > > Pedro Erencia wrote: >> we are having a curious behaviour with the USB OTG throughput on a >> DM3730. Specifically, we get a much greater throughput with high cpu >> loads. > .. >> A test program runs that retrieves data from the board with libusb >> bulk transfers. > > Does the program use the async libusb API to ensure that multiple > transfers are submitted at any given time? > > If not, and it is calling libusb_bulk_transfer() in a loop, then the > USB controller will be idle a lot, until Linux has scheduled the > libusb program, until the program has looped around and submitted > another transfer. > > By submitting multiple transfers at once you ensure that the host > controller hardware will work independently of whatever else is going > on in the system. It's like with all DMA. You need to prepare buffers > ahead of time. > > > //Peter Hi Peter, Unfortunately we cannot change the linux kernel, we are tied to the BSP supplied. :( We are currently doing synchronous bulk transfers but we also tested the suggested approach and the results were the same. What really puzzles me is the fact that higher cpu load results in better throughput. Apart from a power management issue, i cannot find any other explanation... -- 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
