The problem:One USB port's rate can't meet the requirement for USB_CAMERA!

I have tried 1280x720p30,but it didn’t work.

Hi Wance,
The clock tree seems incorrect. When inserting USBCAM to micro USB port on Jetson-tx1, the usb1 should be turned on

root@tegra-ubuntu:~# cat /sys/kernel/debug/clock/clock_tree | grep usb1
            usb1.emc                         $ on     1            1065600000 (300000000)
                           usb1.sclk         $ on     1            408000000  (408000000)

Hi DaneLLL,

It’s OK.I use a USB-Stick to try it.

sudo cat /sys/kernel/debug/clock/clock_tree | grep usb1
usb1.emc $ on 1 204000000 (12750000)
usb1.sclk $ on 1 80218750 (80000000)

Hi Wance,
Please try if the patch helps

diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index b9268cd..f631f26 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -244,7 +244,7 @@ static int tegra_usb_phy_get_clocks(struct tegra_usb_phy *phy)
 		err = PTR_ERR(phy->sys_clk);
 		goto fail_sclk;
 	}
-	clk_set_rate(phy->sys_clk, 80000000);
+	clk_set_rate(phy->sys_clk, 408000000);
 
 	phy->emc_clk = clk_get(&phy->pdev->dev, "emc");
 	if (IS_ERR(phy->emc_clk)) {
@@ -254,7 +254,7 @@ static int tegra_usb_phy_get_clocks(struct tegra_usb_phy *phy)
 	}
 
 	if(phy->pdata->has_hostpc)
-		clk_set_rate(phy->emc_clk, 12750000);
+		clk_set_rate(phy->emc_clk, 300000000);
 	else
 		clk_set_rate(phy->emc_clk, 300000000);
 
@@ -742,7 +742,7 @@ static int tegra_usb_phy_set_clk_freq(struct tegra_usb_phy *phy,
 		if (phy->pdata->has_hostpc) {
 			DBG("%s(%d) USB_SPEED_HIGH\n",
 				__func__, __LINE__);
-			clk_set_rate(phy->emc_clk, 100000000);
+			clk_set_rate(phy->emc_clk, 300000000);
 		}
 		break;
 	case USB_SPEED_LOW:
@@ -751,7 +751,7 @@ static int tegra_usb_phy_set_clk_freq(struct tegra_usb_phy *phy,
 		if (phy->pdata->has_hostpc) {
 			DBG("%s(%d) USB_SPEED_LOW/USB_SPEED_FULL/default\n",
 				__func__, __LINE__);
-			clk_set_rate(phy->emc_clk, 12750000);
+			clk_set_rate(phy->emc_clk, 300000000);
 		}
 	}

Actually I am not able to repro it on DevKit, but let’s try to set clock higher.

We set clock higher as flowing.But the camera still doesn’t work.It is just work for the mouse、keyboard and USB-Stick.

ubuntu@tegra-ubuntu:~$ sudo cat /sys/kernel/debug/clock/clock_tree | grep usb1
usb1.emc $ on 1 1600000000 (300000000)
usb1.sclk $ on 1 408000000 (408000000)

Hi Wance,
What is the execution time of your OK and NG cases?
gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=300 ! ‘video/x-raw,width=(int)1280,height=(int)720’ ! nvvidconv ! nvoverlaysink
Setting pipeline to PAUSED …
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingInside NvxLiteH265DecoderLowLatencyInitNvxLiteH265DecoderLowLatencyInit set DPB and MjstreamingPipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
Got EOS from element “pipeline0”.
Execution ended after 0:00:10.365731664

Excuse me,how can I get the execution time?I don’t find the data from boot-up log.
If I need to input some command?

I get it. But there are some errors:

Command input:gst-launch-1.0 v4l2src device=/dev/video1 num-buffers=300 ! ‘video/x-raw,width=(int)1280,height=(int)720’ ! nvvidconv ! nvoverlaysink

Setting pipeline to PAUSED …
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingInside NvxLiteH265DecoderLowLatencyInitNvxLiteH265DecoderLowLatencyInit set DPB and MjstreamingERROR[u][/u]: Pipeline doesn’t want to pause.
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Cannot identify device ‘/dev/video1’.
Additional debug info:
v4l2_calls.c(568): gst_v4l2_open (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
system error: No such file or directory
Setting pipeline to NULL …
Freeing pipeline …

Hi Wance,
I would like you to share the steps to reproduce the issue on NVIDIA Jetson TX1 development board.
1 Which is the usb camera? If possible, I would try to get exactly the same one because I cannot reproduce the issue with the usb cameras we have.
2 What is the gst command you run to reproduce the issue?

Now,I connect a usb-camera to the usb-OTG port.The newest data as following:

Command input:gst-launch-1.0 v4l2src device=/dev/video0 num-buffers=300 ! ‘video/x-raw,width=(int)1280,height=(int)720’ ! nvvidconv ! nvoverlaysink

Setting pipeline to PAUSED …
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingInside NvxLiteH265DecoderLowLatencyInitNvxLiteH265DecoderLowLatencyInit set DPB and MjstreamingPipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock

I didn’t connect a usb-camera just now.

This is the USB-Camera I said.
External Media
This is the testing environment.I test the USB-OTG port between NVIDIA Jetson TX1 development board and myself-developed board.NVIDIA Jetson TX1 development board is same as myself-developed board of the OTG port.
External Media

There are no problem that I connect the USB-camera to other USB2.0 port.

DaneLLL,

Can I connect the port USB-OTG to camera as shown in the picyure?
I don’t know if the port support it.

Hi Wance,
It should be supported but not recommended. Actually I have tried Logitech c120,c310 and Microsoft Lifecam vx-500 but cannot observe the frame-dropping issue. Do you have other usb camera such as Logitech c310 to give it a try? Probably the issue is specific to the certain camera. And are you on r24.2.1?

One thing I notice which could be an issue (but not necessarily) is that USB2 speeds and faster require a good signal quality, and the loss of twisted pairs where the straight wires are at could be an issue. Try twisting the D+/D- wires and not allowing them to be just straight/untwisted wire sections. You may also want to twist the Vcc/GND pairs, but at a slightly different twist pitch. This might improve signal quality.

But it is ok that the same camera conneects to other USB2.0 port on myself-developed board and Jetson TX1 development board except the usb-otg port.So,I don’t know how to adjust it.If there are some different on software I need to revise?

Hi Linuxdev,

Maybe,can you sure if the USB-OTG port as a host is same with the other two USB2.0 ports about software?

I do not know of any difference between the micro-USB and the other USB2 other than the capability of being switched to device mode (default is host mode). You can use “lsusb -t” to see a tree view and verify what is connected where, and whether the mode is USB1.1/USB2/USB3, so on. When in device mode the OTG port will of course not even show up, but you have to go through significant effort to put the port in device mode; the ID pin does not auto switch mode by default on a Jetson (the software was not added to do this since it does not have a device mode by default other than recovery mode), so connecting the wrong cable type of type-B would still inappropriately remain in host mode (if there were a device mode programmed then the ID pin would automatically switch to device mode when a type-B cable is used).

Hi linuxdev,
I connect the camera to the USB-OTG port,and use “lsusb -t” to see the tree as following that it is same with USB2.0 port.

ubuntu@tegra-ubuntu:~$ lsusb -t
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/4p, 5000M
|__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xhci/5p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-ehci/1p, 480M
|__ Port 1: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
|__ Port 1: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 1: Dev 3, If 2, Class=Audio, Driver=snd-usb-audio, 480M
|__ Port 1: Dev 3, If 3, Class=Audio, Driver=snd-usb-audio, 480M

It would be OK,but it just don’t work that it’s same with Jetson TX1 development board.

I might be mixing things up, so verify if this is correct: The camera shows up under lsusb regardless of which port it is plugged in…the device works on the full-sized USB port, but does not work when on the micro-USB OTG port?

Assuming this is correct the first notable possibility is that the micro-USB OTG port is operating at USB2 speeds, while the full-sized port is operating at USB3 speeds. Many USB3 devices simply slow down when forced to use USB2 speeds, but some of those USB3 devices simply don’t function at USB2 speeds (they don’t implement the same interface under USB2 so that function does not show up for a driver to bind to). Again, assuming the device works on the full-size port but not the micro-USB port, I would check very closely and see if the camera advertises USB2 compatibility.

Hi Wance,
Please refer to Tegra K1 USB 2-0 Compliance Test Tools @ Jetson Download Center | NVIDIA Developer and ensure the micro USB OTG port passes the compliance test first.