• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 102 subscribers
  • Views 642 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.

TUSB1211 Transceiver Linux driver

Mattis Fjallstrom
Prodigy 40 points

We're using a TI 1211 USB transceiver with an OMAP3630 processor.


We want the device to be always on, and always in gadget mode. We have the 12 pins for ULPI connected.


It seems, however, that the Linux driver expects (at least) one more pin. The variable in the driver is called vbus_state, and it looks for interrupts on this pin to schedule work. What I can't seem to find, however, is any reference to what pin on the PHY this corresponds to. NXT? SOF? Is it supposed to be VBUS (through a pull-down of some sort), as the name of the variable suggests?


Along that line - I've seen mentions on this forum of using the 1211 with the generic ULPI driver. Is that a better approach when we don't need any of the other features of the 1211?


EDIT: We're using a 3.10 kernel from AOSP, the driver in question is in <kernel>/drivers/usb/phy/phy-tusb.c.

  • 0
    TI__Expert 4475 points
    Hi Mattis,

    In this forum we are not supported the OMAP3630 processor. For any questions please contact with your nearest TI representative.

    BR
    Ivan
  • 0
    TI__Mastermind 29520 points

    Hello Mattis,


    OMAP3630 has NXT signals muxed on following balls:

    T26 - hsusb0_nxt
    AE3 - hsusb3_tll_nxt

    AG9 - hsusb1_nxt
              hsusb1_tll_nxt

    AH7 - hsusb2_nxt; hsusb2_tll_nxt

    The current implementation of ULPI in OMAP3630 includes a method for manual, software-controlled generation of PHY- side register accesses supporting the following features:
    • Access to vendor-specific or optional PHY-side registers
    • Carkit operation (including interrupt, PHY-side registers)
    • Access to vendor ID, product ID, scratch and debug registers

    If you want to use SOF (Start of frame) in TUSB1211, you must connect an external transceiver as TWL5030. OMAP3630 doesn't have SOF pin.

    In the carkit mode, the interface must connect to the TI TWL5030 companion chip for proper use.
    The 12-pin/8-bit data SDR ULPI interface is selected through the USBOTG.OTG_INTERFSEL[1:0] PHYSEL field and must be set to 0x1.

    See section 22.1.6.1.3.2 TWL5030 - CEA-936-A Carkit Interconnections in OMAP3630 TRM.

    Please see following patches - https://lists.ubuntu.com/archives/kernel-team/2010-October/013053.html
    http://patchwork.ozlabs.org/patch/65748/

    Along that line - I've seen mentions on this forum of using the 1211 with the generic ULPI driver. Is that a better approach when we don't need any of the other features of the 1211?

    - Yes, it is the right approach.

    Best regards,

    Yanko

  • 0 in reply to Yanko Todorov-XID
    Prodigy 40 points

    Hi Yanko,


    Very helpful, thank you!

    I wanted to use the generic ULPI driver, but found some complications. For starters, it doesn't register itself as a usb phy layer. The musb driver creates a read and write operation for ULPI, but doesn't call otg_ulpi_create - I can't seem to find how the two will connect. Do I need to write a wrapper around phy-ulpi.c, or am I missing something?


    Cheers,

    Mattis

  • 0 in reply to Mattis Fjallstrom
    Prodigy 40 points
    Problem may be solved - generic ULPI with the NOP driver seems to work just fine. Made my day.
  • 0 in reply to Mattis Fjallstrom
    TI__Mastermind 29520 points
    Hello Mattis,

    I am glad to hear that.

    For more information about similar problem, you can take a look on following thread:
    e2e.ti.com/.../555778

    linux/include/linux/usb/ulpi.h:
    #if IS_ENABLED(CONFIG_USB_ULPI)
    struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
    unsigned int flags);
    #else
    static inline struct usb_phy *otg_ulpi_create(struct usb_phy_io_ops *ops,
    unsigned int flags)
    {

    You can check in .config file if your CONFIG_USB_ULPI is enabled:
    board-support/linux/.config:
    # CONFIG_USB_ISP1301 is not set
    # CONFIG_USB_RCAR_PHY is not set
    # CONFIG_USB_ULPI is not set
    CONFIG_USB_GADGET=y
    CONFIG_USB_GADGET_DEBUG=y

    Best regards,
    Yanko