[参考译文] AM67：J722SXH01EVM 上的 USB-C DRP 功能无法正常工作

尊敬的 Douglas：

我正在研究这个问题、但 我需要更多的时间。 我明天会回来的。

谢谢、

Stan

尊敬的 Douglas：

您的电路板版本是什么？ 我在修订历史记录中看到、旧的电路板在 VBUS 使能时存在问题。

谢谢、

Stan

修订版本号看起来是 3A。

尊敬的 Douglas：

似乎此版本在 VBUS 使能方面已是固定的。

没错、 USBC_ID 不会带入处理器、因此 USB 驱动程序无法知道如何充当主机或设备。 因此、配置控制器角色的唯一方法是在软件驱动程序中。 ROM 从 BOOTMODE 引脚获取此信息。 在这两种情况下、也必须相应地设置 SW2。

我将在内部进行确认、因为我还不是特别熟悉此电路板。

谢谢、

Stan

Douglas,

我遇到了一个内部论坛主题、在这块电路板上讨论了 USB2。 我得到了 2 个要点：

1.电路板不支持通道交换,因此 USB 插头只能在两个方向之一上工作

2. DRVVBUS 不工作需要 DRVVBUS 引脚多路复用配置:

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;
 };

我对前两个职位有几个问题/意见：
1.我不清楚您对车道变换的评论指的是什么。 这是指交换超高速通道还是指 USB 2.0 功能？ 对于我们的设计、我们仅关注通过 USB-C 实现的 USB 2.0、并且在将 USB 驱动器插入 EVM 板时没有问题。 我们在自己的设计中遇到了一些问题、USB 2.0 仅在一个方向上工作、但这一问题在我们重新设计其中一个电路板以与 EVM 更加匹配时消失了。

对于 DRVVBUS、我们尝试了引脚多路复用配置、但 DRVVBUS 的行为没有变化。

3.对于 EVM、我仍然对 EVM 上 DRVVBUS 行为的基线行为感到困惑。 目前我正在使用最新的 SDK、并将 SW2 设置为 DRP。 如果我打开电路板、引导到 Linux、然后将 USB-C 驱动器插入 USB-C 接头、则没有任何反应。 测量输出信号时、DRVVBUS 为低电平、因此 USB-C 接头的电源关闭。 直到我运行一些将 DRVVBUS 驱动为高电平的命令后、系统才最终将电源驱动到接头、并且 Linux 中显示 USB-C 驱动器。 我的问题是、为什么默认情况下 DRVVBUS 没有由软件驱动为高电平？ 根据电路板上电路的当前设计、我无法想到默认情况下该电路较低的原因。  

4.总的来说、我们的设计目标是将 AM67x 的 USB0 连接到 USB-C 接头、并支持 USB 2.0 作为 DRP 和引导。 我对同时用作主机和设备的 USB 端口的预期是将 ID 引脚恢复到处理器、然后由处理器控制 DRVVBUS 以正确设置电源。 这与 TUSB321AI（我们计划使用的 USB-C 控制器）所示的典型应用相匹配、但该设计列出了 DFP 而不是 DRP。 但是、AM67x 处理器没有用于 USB0 的专用 USB_ID、并且我们使用的软件驱动程序 (SNP、dwc3) 没有用于 ID 或 DRVVBUS 的专用引脚。 这些事实告诉我们、预期设计只是通过硬件处理 ID 和电源控制、但我们对复制 EVM 有点犹豫、因为由于我讨论过的问题、EVM 似乎无法正常工作。 AM67x 的 USB_ID 的预期设计是由硬件控制、还是应将其带回处理器以由软件控制？ 除了 EVM 外、AM67x 上还有其他使用 USB0 作为 DRP 的参考设计吗？

您好 Douglas、

感谢您的意见。

支持查询的专家不在办公室。

请预计响应会延迟 1..2 天。

此致、

Sreenivasa.

尊敬的 Douglas：

我正在内部查看该电路板中 USB 设计的历史记录。

1.我认为 e2e 帖子是指交换插座中 USB 插头的物理方向

DRVVBUS 不直接由软件驱动。 USB 控制器根据内部逻辑驱动引脚。 DRVVBUS 基本上仅在主机模式（不会处于外设模式）下以及 SoC 未处于低功耗模式时才被驱动为高电平。 软件驱动程序通过在主机、外设或 DRD 模式下设置控制器来间接控制它。

4、我同意没有 ID PIN。 在较旧的 SoC 中、ID 也是控制器监控的引脚。 如今、该功能只能通过 GPIO 实现。

我可以看到、如您所述、在此板上、没有任何 ID 引脚信号通过任何方式路由到 SoC。 根据这种情况以及 VBUS 电源由板开关控制这一事实、我可以得出结论：DRD/DRP 模式是不可能的。 只有在断电期间、通过切换 USB 驱动器中的角色并 相应地切换 USBC_MODE_SEL 开关、才能手动切换角色。

我想您可以参考 TMDS64EVM 中的仅 USB2.0 设计 。 使用的插座是 micro-AB、ID 控制器引脚在该器件上具有引脚输出、否则 USB2.0 DRD 概念在此处很清晰。

此致、

Stan

尊敬的 Douglas：

我已经联系了软件专家。

由于班加罗尔的假日、预计响应会延迟（下周初）。

此致、

Sreenivasa.

尊敬的 Douglas：

对于 EVM、我仍然对 EVM 上 DRVVBUS 行为的基线行为感到困惑。 目前我正在使用最新的 SDK、并将 SW2 设置为 DRP。 如果我打开电路板、引导到 Linux、然后将 USB-C 驱动器插入 USB-C 接头、则没有任何反应。 测量输出信号时、DRVVBUS 为低电平、因此 USB-C 接头的电源关闭。 直到我运行一些命令将 DRVVBUS 驱动为高电平、系统才最终将电源驱动至接头、并且 USB-C 驱动器在 Linux 中显示。

您能否尝试在 Linux 中添加以下补丁、并尝试在 TI J722S EVM 上进行测试？

• 问题的根本原因是 USB2.0_MUX_SEL GPIO。 k3-j722s-evm.dts 中的以下更改在 Linux 中启用 Type-C 接口

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 {

此外、如果您可以在 DFP 和 DRP 模式下尝试使用 SW2、那会很好。

此致

Gokul

您好 Douglas、  

检查您是否能够取得一些进展？

此致、

Sreenivasa.