• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 416 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM335X: USB polling interval configuration

Bala Naresh Nalamati
Prodigy 90 points
Part Number: PROCESSOR-SDK-AM335X

Hi,

I would like to change the USB polling interval. My kernel version is 4.9.31. When i verify the code, polling interval is being configured based on USB speed.

Below is the information that I need: 

a) Configurable option for setting USB polling interval. If it is not possible, where could I directly hard code in the USB driver?

b) Could you also help understand what should be an optimal value for the polling interval? What are the consequences of increasing/decreasing this value?

Thanks,

Naresh

  • 0
    TI__Guru**** 168731 points

    Hi Naresh,

    Bala Naresh Nalamati said:
    When i verify the code, polling interval is being configured based on USB speed.

    Please elaborate what polling that you referred is?

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Hi Bin Liu,

    I referred usb_submit_urb API.  In this, urb->interval is modified to reflect the actual transfer period used. 

    Could you please help me on, Where do i refer the USB polling interval period configuration ?  Is there any sys call to modify by the user?

    Thanks,

    Naresh

  • 0 in reply to Bala Naresh Nalamati
    TI__Guru**** 168731 points

    Hi Bala,

    Can you please explain why you want to change the interval? Is this for Interrupt or Isoch transfers?

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Hi Bin Liu,

    The goal is to increase the amount of time before a USB disconnect is actually recognized to “ride through” unexpected disconnect events (which are being caused by noise spikes inside the control box).

     We want to try to keep the OS from logically disconnecting a device because of a brief disruption from noise. The device supplier suggested that if we can increase the time between polls, and increase the number of polls before deciding the device isn’t behaving properly, we may be able to only disconnect the device on a much longer disruption than the noise event.

    Hopefully this would mean we wouldn’t have to wait for the USB device to reconnect and re-initialize after every noise event anymore.

  • 0 in reply to Bala Naresh Nalamati
    TI__Guru**** 168731 points

    Hi Bala,

    Typically there are two scenarios of USB device disconnect:

    1. The device is physically removed, the USB controller will detect the DP/DM line disconnect and generate DISCONNECT interrupt, then the USB drivers will handle the interrupt and tear down the enumerated device;

    2. The device internally locks up and stops responding to the USB host transfer requests, the USB class driver would issue device reset/disconnect request to the USB controller driver, which tears down the enumerated device;

    On AM335x, the MUSB controller has additional two actions to USB VBUS droop or USB babble conditions, in which the MUSB controller will exist host mode, then in turn disconnect the enumerated devices.

    However, none of the scenarios above has a way to "increase the time between polls" which you described.

    urb->interval has nothing to do with USB device disconnect.

  • 0 in reply to Bin Liu
    Prodigy 90 points

    Hi Bin Lin,

    Spoke with the supplier on this. Can we find out how many missed host transfer requests does it take for the host to think that the device has disconnected? (How many times does the error in scenario 2 have to happen before teardown?) And if it’s possible to change that value?

  • 0 in reply to Bala Naresh Nalamati
    TI__Guru**** 168731 points

    Hi Bala,

    It is technically possible, but not practical. Any kernel driver layer above the USB core driver, even user space programs can issue the request to USB core driver to disconnect the USB devices, you likely won't be able to modify all the instances for change the disconnect policy.