On Mon, 4 Nov 2013, Cliff Brake wrote: > > As far as I can tell, the big blockage occurs when the machine has to > > analyze an input report from which it extracts 767 fields and ends up > > calling hid_process_event about 2300 times. Since each call takes > > around 60-80 microseconds, you end up with a very large latency. > > > > Why on earth are you using such enormous HID reports? > > The consumer device we are interfacing with only supports HID > transfers. Since we are trying to transfer large amounts of data, we > need to send a lot of packets, as the average HID packet size is only > ~700 bytes. > > Its a very slow and inefficient mechanism, but its the only way to > interface with this device if the linux system is the USB host. I think your real problem here is the "slow and inefficient". HID packets are encoded in a way that allows great flexibility and permits a large number of values to be stored in a single packet. All of this adds a good deal of processing overhead. The HID format is not well suited for efficient transfers of lots of data. How would things differ if the USB host were something else? > We have the same system running on a older PXA270 version of the > product (vs the current TI DM3730). It has an older OHCI 12Mbit USB > host controller (vs the current TI EHCI controller). We have _not_ > experienced these types of latencies with the older PXA270 product. > This may be another indication the problem lies in the TI EHCI > controller driver, but its odd we have not seen any issues with other > peripherals. More likely it's an indication that you aren't transferring such large amounts of data with the older host. The trace shows very clearly that the lion's share of the overhead was not in the EHCI controller driver; it was in the HID processing. Put it this way: For each packet, the EHCI controller driver required less than 0.5 ms for processing, whereas the HID layer required more than 60 ms. 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
