AM67: USB-C DRP functionality on the J722SXH01EVM not working

Hi Douglas,

I'm looking into this, however  I will need a little more time. I will come back to you tomorrow.

Thanks,

Stan

Hi Douglas,

What is your board revision? I see in revision history older boards have issue with VBUS enable.

Thanks,

Stan

Looks like the revision number is 3A.

Hi Douglas,

Seems like this revision is already fixed in terms of VBUS enable.

You are right, USBC_ID isn't brought to the processor, therefore USB driver cannot know how to act - as a host or as a device. Thus, the only way is to configure the role of the controller is in software driver. ROM gets this information from BOOTMODE pins. SW2 must also be set accordingly in both cases.

I will check internally for confirmation since I'm not super familiar with this board yet.

Thanks,

Stan

Douglas,

I came across an internal forum thread discussing USB2 on this board. I got 2 major points:

1. the board doesn't support lane swap, therefore an usb plug will work only in the one of the two directions

2. DRVVBUS not working needs DRVVBUS pin mux config :

diff --git a/dts/upstream/src/arm64/ti/k3-j722s-evm.dts b/dts/upstream/src/arm64/ti/k3-j722s-evm.dts
index e362bfbb655..5d256e630c3 100644
--- a/dts/upstream/src/arm64/ti/k3-j722s-evm.dts
+++ b/dts/upstream/src/arm64/ti/k3-j722s-evm.dts
@@ -375,6 +375,12 @@
                bootph-all;
        };
 
+       main_usb0_pins_default: main-usb0-default-pins {
+               pinctrl-single,pins = <
+                       J722S_IOPAD(0x0254, PIN_INPUT, 0) /* (E25) USB0_DRVVBUS */
+               >;
+       };
+
        main_usb1_pins_default: main-usb1-default-pins {
                pinctrl-single,pins = <
                        J722S_IOPAD(0x0258, PIN_INPUT, 0) /* (B27) USB1_DRVVBUS */
@@ -1098,7 +1104,9 @@
 };
 
 &usb0 {
-       dr_mode = "otg";
+       pinctrl-names = "default";
+       pinctrl-0 = <&main_usb0_pins_default>;
+       dr_mode = "host";
        usb-role-switch;
 };

I have several questions/comments in regards to the previous two posts:
1. I am unclear what you are referring to with the comment about lane swapping. Is this referring to swapping the super speed lanes or to USB 2.0 functionality? For our design we are only concerned with USB 2.0 through USB-C and have had no issues with plugging in a USB drive into the EVM board. We have had some issues on our own design with USB 2.0 only working in one direction, but that went away when we reworked one of our boards to closer match the EVM.

2. For the DRVVBUS, we tried that pin mux config, but saw no change in behavior for DRVVBUS.

3. For the EVM, I am still confused by the baseline behavior of the DRVVBUS behavior on the EVM. Currently I am using the most current SDK and have SW2 set to DRP. If I turn on the board, boot into Linux, and then plug a USB-C drive into the USB-C header, nothing happens. When I measure out the signals, DRVVBUS is low and thus power to the USB-C header is off. It isn't until I run some commands driving DRVVBUS high that the system finally drives power to the header and the USB-C drive shows up in Linux. My question then is why by default DRVVBUS is not driven high by the software? With the current design of the circuit on the board, I can't think of a reason for it to by default be low. 

4. Overall our design goal is to connect USB0 from the AM67x to a USB-C header and support USB 2.0 as a DRP as well as for boot. My expectations for a USB port acting as both a host and device would have the ID pin brought back to processor, with the processor then controlling DRVVBUS to correctly set power. This matches with the typical application shown for TUSB321AI (the USB-C controller we plan to use), although the design is listed for DFP and not DRP. However, the AM67x processor does not have a dedicated USB_ID for USB0 and the software driver we are using (snps,dwc3) does not have dedicated pins for either ID or DRVVBUS. These facts indicate to us that the expect design is to just handle the ID and power control through hardware, but we are a little hesitant to copy the EVM as it doesn't seem to be working properly due to the issues I have discussed. Is the intended design for USB_ID for the AM67x to have it be controlled by hardware or should it be brought back to the processor to be controlled by software? Also are there any other reference designs using USB0 as a DRP on the AM67x we could reference aside from the EVM?

Hello Douglas,

Thank you for the inputs.

The expert supporting the query is Out of Office.

Please expect 1..2 days delay in response.

Regards,

Sreenivasa

Hi Douglas,

I'm checking internally about the history of the USB design in this board.

1. I think the e2e post is referring to swapping of the physical direction of the USB plug in the receptacle

3. DRVVBUS is not driven by software directly. The USB controller is driving the pin based on internal logic. DRVVBUS is driven high basically only in host mode (and never in peripheral mode) and when the SoC is not in a low-power mode. Software driver controls it indirectly by setting the controller in host, peripheral, or DRD mode.

4. I agree about the ID pin absence. ID was also a controller-monitored pin in older SoCs. Nowadays this function can be implemented only via GPIO.

I can see as you already stated - no ID pin signal is routed to the SoC by any means on this board. Based on this and the fact the VBUS power is controlled by board switches, I can conclude that DRD/DRP mode is not possible. Role switching can be done only manually during power down, by switching the role in the USB driver plus switching the USBC_MODE_SEL switch accordingly.

I think you can refer to the USB2.0-only design in the TMDS64EVM . The receptacle used is micro-AB and the ID controller pin is pinned out on this device, but otherwise the USB2.0 DRD concept is clear here.

Regards,

Stan

Hi Douglas,

I have reached out to the software expert.

Please expect delay in response (early next week) due to the holidays in Bangalore.

Regards,

Sreenivasa

HI Douglas,

Douglas Smith said:

For the EVM, I am still confused by the baseline behavior of the DRVVBUS behavior on the EVM. Currently I am using the most current SDK and have SW2 set to DRP. If I turn on the board, boot into Linux, and then plug a USB-C drive into the USB-C header, nothing happens. When I measure out the signals, DRVVBUS is low and thus power to the USB-C header is off. It isn't until I run some commands driving DRVVBUS high that the system finally drives power to the header and the USB-C drive shows up in Linux.

Can you try adding the below patch in linux and try testing on TI J722S EVM?

• the root-cause of the issue is the USB2.0_MUX_SEL GPIO. The following change in k3-j722s-evm.dts enables the Type-C interface in linux

diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
index 6169b2c9710f..ea74ab159848 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
@@ -668,7 +668,7 @@ p05-hog {
                        /* P05 - USB2.0_MUX_SEL */
                        gpio-hog;
                        gpios = <5 GPIO_ACTIVE_LOW>;
-                       output-high;
+                       output-low;
                };
 
                p01_hog: p01-hog {

Also, it would be great if you can try with SW2 in both DFP and DRP mode.

Regards

Gokul

Hello Douglas, 

Checking if you were able to make some progress?

Regards,

Sreenivasa