I don’t see it. Where did you put it?
Dear WayneWWW,
maybe the upload error, please refer to my last post: A300_MBSCH_V1.3.pdf
Thanks for sharing. So these two usb ports are all typeA and not have otg function right?
Also, we just have a internal discussion and there are some questions.
-
Do you have ZED cam instead of ZED-M camera that can test? ZED-M has a hid device inside it so it is a special case and would affect the negotiation between usb device and host.
-
Does Realsense camera have similar hid interface too?
Dear WayneWWW,
-
Realsense doesn’t have hid interface
-
We will try to buy another ZED cam, but I’m not sure all ZED cams have HID or just ZED-M has hid device.
Hi Dennis,
We found the VDD power switch for USB_SS1 is controlled by VDD_5V0_IO_SYS, while USB_SS0 is controlled by USB_VBUS_EN1.
Our developer suspects VDD_5V0_IO_SYS will be turned on during boot-up, and VDD is on for USB_SS1 accordingly. Could you measure the VDDs for USB_SS0 & USB_SS1 during boot-up?
Dear WayneWWW,
We change USB_SS1 VDD Power controlled by USB_VBUS_EN1(the same as USB_SS0), both USB3.0 work fine(with USB3.0 ZED Mini), removed VDD_5V0_IO_SYS for USB_SS1.
But I have another question, both USB3.0 work fine while using JetPack3.3, just failed using JetPack4.2. Can you help to find the different between JetPack4.2 and JetPack3.3 ?
Hi Leetop,
I notice you set the regulator of usb2-2 to battery_reg but you give regulators to usb2-0 and 2-1. Do you always use such setting even on jetpack3.3? It indicates that vbus would be on right after the vdd is on. (usb2-2 is companion with your usb3-2 port which is USB_SS1).
Please note that this would cause the driver cannot control the timing of vbus. If it could work on rel-28 based release, I would suspect it just meets the timing accidentally.
Our developer suggests you to dump the usb trace on rel-28 if you want to dig into the reason.
Dear,
Yes, JetPack3.3 using USB2-2 (battery_reg) too. here are the dts of JetPack3.3 and 4.2.
BTW, How to dump the usb trace during bootup ?
"Our developer suggests you to dump the usb trace on rel-28 if you want to dig into the reason. "
JetPack3.3 ：
vbus-0-supply = <&vdd_usb0_5v>;
vbus-1-supply = <&vdd_usb1_5v>;
vbus-2-supply = <&battery_reg>;
JetPack4.2 ：
ports {
usb2-0 {
status = "okay";
mode = "otg";
vbus-supply = <&vdd_usb0_5v>;
};
usb2-1 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb1_5v>;
};
usb2-2 {
status = "okay";
mode = "host";
vbus-supply = <&battery_reg>;
};
usb3-0 {
nvidia,usb2-companion = <0>;
status = "okay";
};
usb3-1 {
nvidia,usb2-companion = <1>;
status = "okay";
};
usb3-2 {
nvidia,usb2-companion = <2>;
status = "okay";
};
};
Hi Dennis,
You need to use the bus analyzer for the trace. If you don’t have such tool, I think you need to reconfigure your hw design.
Per confirmed with our developer team, why your device can work on jetpack3.3 seems also a coincidence. The negotiation between usb host/device just meets the timing. Such timing would go wrong easily.
Dear WayneWWW,
We tried different brands carrier boards, almost they have the same problem.
It must be the software bugs for USB host/device detection timing, can you help to confirm with your developer team and give some suggestion how to modify or debug the timing in kernel4.9 (it’s too different with kernel4.4).
Thanks so much.
Hi Dennis,
What you are trying to do is not correct. The usb driver is able to control the timing only when you give it a valid regulator which is not “battery_reg”. Battery_reg is just a dummy regulator which is not actually turning ON/OFF. You need a GPIO and add one regulator inside DT to do the control.
Dear WayneWWW,
I get, but when I change “battery_reg” to “vdd_usb0_5v” or “vdd_usb1_5v”, still failed.
But my question is when I change to JetPack3.3(still using “battery_reg”) , the ZED Mini (USB3.0 + USB2.0) works fine.
JetPack4.2 change to “vdd_usb0_5v” (still failed)
usb2-0 {
status = "okay";
mode = "otg";
vbus-supply = <&vdd_usb0_5v>;
};
usb2-1 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb1_5v>;
};
usb2-2 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb0_5v>; //<&battery_reg>
};
Dear WayneWWW,
Can you help to find if there any methods to restart the USB3.0 controller, after kernel booted, like using shell commands or api callings.
Thanks so much.
Hi Dennis,
As I said, the reason that it can work with Jetpack3.3 may also be a coincidence. The correct way to control the timing is just as what you did : give something like vdd_usb0_5v to the usb controller.
However, I don’t quite understand your design here. The vdd_usb0_5v is actually using below GPIO.
vdd_usb0_5v: regulator@4 {
compatible = "regulator-fixed-sync";
reg = <4>;
regulator-name = "vdd-usb0-5v";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
<b> gpio = <&tegra_main_gpio TEGRA_MAIN_GPIO(L, 4) 0>;</b>
gpio-open-drain;
enable-active-high;
};
Is GPIO(L,4) in your design? Also, does your design ever give a regulator for any of your USB ports?
You said after using “USB_VBUS_EN1”, both ports could work. It sounds that both cases all use a power supply directly instead of given a regulator/gpio for usb driver to control. Am I right?
Dear WayneWWW,
We have two USB3.0 w/ two USB2.0 ports, and one Micro-USB2.0.
- “USB_VBUS_EN0” is used for Micro-USB2.0 Port VBUS regulator
- “USB_VBUS_EN1” is used for USB3.0/2.0 Port VBUS regulator (#USB_SS0 and one USB2.0/USB1_D Port)
- “VDD_5V0_IO_SYS” is used for USB3.0/2.0 Port VBUS regulator (#USB_SS1 and one USB2.0/USB2_D Port), the “VDD_5V0_IO_SYS” is a common power, and is powered after press power button, can’t be controled by GPIO.
What I mean is if we jump to use “USB_VBUS_EN1” to controll the two USB3.0 ports VBUS(bypass “VDD_5V0_IO_SYS”), both USB3.O works fine.
Hi Dennis,
So USB_VBUS_EN1 is your “vdd_usb1_5v” regulator?
BTW, why do you have 3 enabled usb3 ports in DT while you said there are 2x USB_SS and 1x micro USB2.0?
Dear WayneWWW,
You have got the schematic(refer to Page5), we have two USB3.0 ports(compatible with two USB2.0), and one Micro-USB2.0
Port 1: #USB_SS0(3.0) w/ USB1_D(2.0) — VDD_VBUS1_5V
Port 2: #USB_SS1(3.0) w/ USB2_D(2.0) — using “VDD_5V0_IO_SYS”, dts confiugred to “battery”(because it can’t be controlled)
Port 3. Micro-USB2.0 — VDD_VBUS0_5V
these three ports use different three diffrent Power Distribution Switches, so we configured three vbus-supply.
Ok, then I think I should just ignore the error that there are 3 usb 3.0 ports in your device tree.
Then, Why do you use the regulator of your Micro-usb2.0(port3) to your usb3.0(port2)? Is there any other extra regulator that can be used?
Dear WayneWWW,
I misunderstand about “Why do you use the regulator of your Micro-usb2.0(port3) to your usb3.0(port2)?” ?
You mean the dts configuration or hardware design? we don’t change regulator Micro-usb2.0 to usb3.0.
Yes I mean the dts config. Why did you put vdd_usb0_5v to usb2-2?
usb2-0 {
status = "okay";
mode = "otg";
vbus-supply = <&vdd_usb0_5v>;
};
usb2-1 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb1_5v>;
};
usb2-2 {
status = "okay";
mode = "host";
vbus-supply = <&vdd_usb0_5v>; //<&battery_reg>
};