Linux/AM5748: VBUS / ID detection with USB-C

Christian Leeb

Part Number: AM5748
Other Parts Discussed in Thread: TUSB320

Tool/software: Linux

On customer design we we have two USB-C ports

We use TI's TUSB320s connected to AM5748 USB controller 1 & 2.

Looking at the IDK57x reference design, we see that ID and Vbus detection is using PMIC blocks their output is connected to AM5748 GPIOs. In the device tree the OMAP USB controller is connected via extcon:

Please have a look at the device tree fragments below (indentation is lost, sorry):

This is the USB2 definition (in dra7.dtsi):

omap_dwc3_2@488c0000 {

compatible = "ti,dwc3";

ti,hwmods = "usb_otg_ss2";

reg = <0x488c0000 0x10000>;

interrupts = <0x0 0x57 0x4>;

#address-cells = <0x1>;

#size-cells = <0x1>;

utmi-mode = <0x2>;

ranges;

usb2: usb@488d0000 {

compatible = "snps,dwc3";

reg = <0x488d0000 0x17000>;

interrupts = <0x0 0x49 0x4 0x0 0x49 0x4 0x0 0x57 0x4>;

interrupt-names = "peripheral", "host", "otg";

phys = <0xf7>;

phy-names = "<2-phy";

maximum-speed = "high-speed";

dr_mode = "otg";

snps,dis_u3_susphy_quirk;

snps,dis_u2_susphy_quirk;

snps,dis_metastability_quirk;

}

Below, the extcon is add both to omap_dwc3_2 and its child, usb2.

Note that the extcon does not add the actual two GPIOs, but rather a link to the PMIC’s USB functionality. So we would be forced to use two PMICs for two USB ports!

&omap_dwc3_2 {

extcon = <&extcon_usb2>;

};

&usb2 {

extcon = <&extcon_usb2>;

...

Here, the PMIC’s USB functionality “tps659038_usb” is defined, part of the PMIC definition.

tps659038: tps659038@58 {

….

extcon_usb2: tps659038_usb {

compatible = "ti,palmas-usb-vid";

ti,enable-vbus-detection;

ti,enable-id-detection;

/* ID & VBUS GPIOs provided in board dts */

}

Eventually, the actually used GPIOs are added to the tps659038_usb

&extcon_usb2 {

id-gpio = <&gpio3 16 GPIO_ACTIVE_HIGH>;

vbus-gpio = <&gpio3 26 GPIO_ACTIVE_HIGH>;

The bottom line is that the way the omap_dwc3 USB driver is designed it does not seem to allow to connect it to other devices/GPIOs than a TI-PMIC’s USB block. Or maybe it is allowing but I cannot find any related documentation.

When we look at the TUSB320:

- it has an ID pin output which we could connect to a GPIO of the AM5748: how can we connected this GPIO in device tree to omap_dwc3_2?

- it generates an interrupt on Vbus detection ( ATTACHED_STATE = Attached.SNK/SRC): how can we connected this in device tree to omap_dwc3_2?

Regards, Chris

over 7 years ago

0 RonB over 7 years ago

TI__Mastermind 30856 points

Chris,

Thanks for the post. I'll need to consult with some developers and get back to your with our input. Thanks.

0 RonB over 6 years ago in reply to RonB

TI__Mastermind 30856 points

Hi Chris,

AM57x boards have been using PMIC to route VBUS/ID, so they use "ti,palmas-usb-vid". DRA7xx boards use GPIO for VBUS/ID, and use "extcon-usb-gpio". So, there is a validated path to using GPIOs for each of these.

If the type-C chip is connected to GPIO then you can use "extcon-usb-gpio" driver to manage those GPIOS, much like the DRA7xx boards do. You will have to provide VBUS and ID gpios to that driver like so.

extcon_usb1: extcon_usb1 {
    compatible = "linux,extcon-usb-gpio";
    id-gpio = <&pcf_gpio_21 1 GPIO_ACTIVE_HIGH>;
    vbus-gpio = <&pcf_lcd 14 GPIO_ACTIVE_HIGH>;
};

Again, the DR7xx DTS files should be a great resource for this.

Please note that Type-C bus states don't have a 1:1 mapping to ID:VBUS states. ID should be straight forward based on Type-C role i.e. low for Downstream Facing Port (DFP), high for UFP (Upstream Facing Port). VBUS should be high only if it is in UFP (device mode) and VBUS is provided by the external host.

I hope this addresses your question. Thanks.

Processors

Processors forum

Linux/AM5748: VBUS / ID detection with USB-C