• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 1234 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

Linux/DRA712: USB as device dis/connection event missing

Linux/DRA712: USB as device dis/connection event with IPhone using CarPlay

Christian N
Expert 1285 points
Part Number: DRA712

Tool/software: Linux

Hello Team

We have a usb port that is used to connect an iPhone and use CarPlay.

In this scenario, the port starts as host, and during the session, the iPhone will eventually ask for a role-switch. The port will then go to gadget mode. In either mode, we must keep the VBUS line high. This is ok, we are able to do this because we are not using the drvvbus line to set the state, in fact, we always keep the VBUS line high.

Keeping in mind that VBUS will always be high, so it will not change its state, then our question is how can we detect the iPhone was disconnected when we are in gadget mode (J6-USB as device and VBUS state high)?

Does DRA71x support hnp?

Thanks in advance

  • 0
    TI__Mastermind 27371 points

    Hi ChristiaN,

    Since the J6-USB is in gadget mode, one way to check if the iPhone(Host) is connected or not is by check the debugfs. Based on the USB instance being used, we can call:

    cat /sys/kernel/debug/48890000.usb/link_state

    cat /sys/kernel/debug/488b0000.usb/link_state

    If the gadget is connected to the host, we will see U0, if dis-connected we will see U3.

    >Does DRA71x support hnp?

    Yes, OTG 2.0 Host Negotiation Protocol (HNP) is supported by the USB Controller on DRA71x.

     

    Thanks,

    Praveen

  • 0 in reply to Praveen Rao
    Expert 1285 points

    Hello Praveen

    Looking at debugfs is great for development time, but
    1-We try to avoid polling mechanism.
    2-Debugfs will be removed in production boards

    Does driver provide any uevent to netlink?

  • 0 in reply to Christian N
    TI__Mastermind 27371 points
    Hi ChristiaN,

    Yes, we understand debugfs limitations. But we also know that some customers have used debugfs from userspace app/scripts in carplay usecases.

    Regarding the gadget to know when the host disconnected, we do have that mecahnism in DWC driver. Bascially, the driver does register for the USB_DEVTEN.DISCONNEVTEN event. So on disconnect, this event is set and dwc3_disconnect_gadget() is called which in turn calls the disconnect function in the registered gadget driver, which must take the required action.
    Suggest you to look into the drivers/usb/dwc3/gadget.c file for the implementation.

    Thanks,
    Praveen
  • 0 in reply to Praveen Rao
    Prodigy 25 points
    Hi Praveen,

    From your comments on the link_state we tried the following:

    In function dwc3_gadget_linksts_change_interrupt() we checked that the states are monitored and in fact variable link_state is changed. We made a modification in this function. When the sate is DWC3_LINK_STATE_U3 function dwc3_suspend_gadget() is called. What we added was to call dwc3_gadget_disconnect_interrupt() right after it (both function are called). This will eventually trigger the disconnection uevent so that applications will know that the host was disconnected. Basically the following code in dwc3_gadget_linksts_change_interrupt():

    case DWC3_LINK_STATE_U2:
    dwc3_suspend_gadget(dwc);
    break;
    case DWC3_LINK_STATE_U3:
    dwc3_suspend_gadget(dwc);
    dwc3_gadget_disconnect_interrupt(dwc);
    break;

    We have tried it and it seems to work fine. However we don't know much of the internals of this driver, so I wanted your opinion on the matter. Is this a good idea? Or could this create some issues we are not seeing?

    Regards,
    Alejandro
  • 0 in reply to Alejandro Rizzo
    TI__Mastermind 27371 points
    Hi Alejandro,

    Since this a custom requirement, the above modification looks to be ok. But please note that the code change to the the DWC3 gadget driver code will be common for all device mode functionality. So if there are more one one active gadget, then we need to make sure it does not break or cause any other issue. We suggest you to do some extensive validation to be sure this.

    regards,
    Praveen