Go to previous topic
Go to next topic
Last Post 07 Nov 2017 12:37 PM by  Adam Ford
Hidraw and 1ms interrupt interval
 1 Replies
Author Messages
Chris Keeser
New Member
New Member
Posts:1


--
06 Nov 2017 12:41 PM

    We are looking for some help on succesfully acheiving a 1 ms polling rate by the kernel on a Generic HID device.  When the generic HID device is attached to the system and the character device `/dev/hidraw0` is opened and read in a tight loop, the USB device interrupt endpoint is only read every 2 ms, not the requested 1 ms.

    Device and configuration background:

    DM3730 torpedo module using kernel 3.0.101 and BSP 2.4-4

    DM-37x# uname -r
    3.0.101-BSP-dm37x-2.4-4

    Generic HID support through /dev/hidraw and USB HID are enabled in the kernel configuration.

    USB on the SOM is handled through the TWL4030

    Custom Composite device with a Generic HID interface with the HID interrupt endpoint interval set to 1ms.  This is known working element in the system.  The device, configuration, interface and report descriptors are all working as intended, and on other systems (windows / full desktop linux) the interrupt endpoint is polled at the requested 1ms interval.  The other interface(s) in the composite device are a CDC ACM to emulate a serial port.

    Opening the /dev/hidraw device in our simlpe test program begins the process of reading reports from the interrupt endpoint, but the reads are occurring at 1/2 the rate requested in the descriptor.  There are no other devices on the USB bus, and even the CDC ACM interface is not being utilized during theses tests.  There is no other traffic on the bus at all.  Logic traces of the traffic show the Start Of Frame (SOF) every 1 ms, but the interrupt endpoint is only being polled for data every other frame.  Digging into the hid code, It appears that the URB is set up correctly to poll at the desired 1 ms rate. The theory is that the URB completion event is getting called too late (even though the endpoint query is the very first transfer after the SOF) and is missing the opportunity to re-submit the URB for the next frame, so the interrupt endpoint is only getting polled at 1/2 the desired rate (the URB is re-submitted in the URB completion event).

    Any help would be greatly appreciated and I am happy to answer any further questions about the setup and tests that have been done.

    Adam Ford
    Advanced Member
    Advanced Member
    Posts:794


    --
    07 Nov 2017 12:37 PM
    Can you try this on the other USB host port? I talked one of the SW developers who said this might help us determine if it's a driver or kernel issue.

    thanks

    adam


    ---