One camera works, two don't; tegra-capture-vi has timeout

Hey everyone,

I am running a multiple camera setup on a Nvidia Jetson Orin AGX with a customized deserializer board (provided by the supplier of the Nvidia device).
The imaging sensor is a Sony ISX021, the camera has an integrated MAX9295 serializer.
The deserializer board has 8 GMSL2 ports, always two are connected to one MAX9296A deserializer.

Right now, I’m able to run a single camera on any of the 8 GMSL2 ports by adjusting the device tree accordingly. Everything works as expected, frame rate and image quality looks good.

As soon as I add a second camera to the device tree and connect it to the Nvidia Orin, things start to get weird. After rebooting, both cameras are mounted properly (they show up in /dev/vid*, v4l2-compliance output also looks good).
However, when I try to launch one camera via v4l2-ctl, the camera output seems stuck (seemingly always repeating three frames):

nvidia@nvidia-desktop:~$ v4l2-ctl -d /dev/gmsl/tier4-isx021-cam1 --set-fmt-video=width=1920,height=1280,pixelformat=UYVY --set-ctrl bypass_mode=0 --stream-mmap --stream-count=100 --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
	Width/Height      : 1920/1280
	Pixel Format      : 'UYVY' (UYVY 4:2:2)
	Field             : None
	Bytes per Line    : 3840
	Size Image        : 4915200
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Limited Range)
	Flags             : 
		VIDIOC_REQBUFS returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QUERYBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_QBUF returned 0 (Success)
		VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq:      0 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      0 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      0 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 4915200 ts: 0.000000 (error, ts-monotonic, ts-src-eof)

The second camera is connected to a GMSL2 port that is not attached to the same deserializer as the first camera. That means, each camera has it’s “own” deserializer in the current two-camera setup.

The dmesg log contains the following:

[ 1715.091522] bwmgr API not supported
[ 1715.454018] tier4_isx021 31-001b: [tier4_isx021_start_one_streaming] : Parameter[enable_auto_exposure] = 1.
[ 1715.575454] tier4_isx021 31-001b: [tier4_isx021_start_one_streaming] : Enabled Auto Exposure.
[ 1715.575464] tier4_isx021 31-001b: [tier4_isx021_start_one_streaming] : fsync-mode in DTB = 0.
[ 1715.597480] tier4_isx021 31-001b: [tier4_isx021_start_one_streaming] : Prameter[enable_distortion_correction] = 1 .
[ 1716.340514] tier4_isx021 31-001b: [tier4_isx021_setup_embedded_data] : Disabling Front Embedded.
[ 1716.344645] tier4_isx021 31-001b: [tier4_isx021_setup_embedded_data] : Disabling Rear Embedded.
[ 1716.572361] tier4_max9296 31-0048: [tier4_max9296_write_reg] : Max9296 I2C write register at 0x0050:[0x02]
[ 1716.572488] tier4_isx021 31-001b: [tier4_isx021_start_one_streaming] : Camera has started streaming.
[ 1717.697994] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1717.707178] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 1717.717294] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1717.725181] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 1717.735846] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1717.743575] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1
[ 1717.754344] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 1720.513764] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1720.522912] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 1720.533194] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1720.541023] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 1720.551690] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1720.559414] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1
[ 1720.570143] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 1723.105795] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[ 1723.114961] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[ 1723.125197] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1723.132940] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=0, csi_port=0
[ 1723.143616] (NULL device *): vi_capture_control_message: NULL VI channel received
[ 1723.151343] t194-nvcsi 13e40000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 0 vc- 1
[ 1723.162125] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[ 1723.172232] tier4_max9296 31-0048: [tier4_max9296_write_reg] : Max9296 I2C write register at 0x0050:[0x00]

The same thing happens when I run the other camera that did work previously.

I don’t really get why I can run one camera without any issues + mount a second one without any issues.
But when trying to stream, both camera outputs are broken, somehow stuck.

After reading a lot in the forum, my suspicion is towards the deser_pix_clk_hz value.
It might be okay for the load coming from one camera stream, but is too much for more than two cameras. Does that make sense?

Some sections of my device tree that might help here:

	// ----- Camera modules -----
	fragment@2 {
		target-path = "/";
		__overlay__ {
			tegra-camera-platform {
				compatible = "nvidia, tegra-camera-platform";
				num_csi_lanes = <8>;
				max_lane_speed = <4000000>;
				min_bits_per_pixel = <10>;
				vi_peak_byte_per_pixel = <2>;
				vi_bw_margin_pct = <25>;
				isp_peak_byte_per_pixel = <5>;
				isp_bw_margin_pct = <25>;
				modules {
                                ...
				};
			};
		};
	};

mode of the cameras:

						mode0 {
							/*mode ISX021_MODE_1920X1280_CROP_30FPS*/
							mclk_khz = "24000";
							num_lanes = "4";
							tegra_sinterface = "serial_c";
							vc_id = "0";
							discontinuous_clk = "no";
							dpcm_enable = "false";
							cil_settletime = "0";
							dynamic_pixel_bit_depth = "16";
							csi_pixel_bit_depth = "16";
							mode_type = "yuv";
							pixel_phase = "uyvy";

							active_w = "1920";
							active_h = "1280";
							readout_orientation = "0";
							line_length = "2250";
							inherent_gain = "1";

							pix_clk_hz = "74250000";
							serdes_pix_clk_hz = "350000000";// MIPI CSI clock 1400Mhz

							gain_factor = "10";
							/* min gain value has to start from 1 in L4T R35.4.1
							https://forums.developer.nvidia.com/t/uint32-underflow-in-r35-4-1-kernel-tegracam-ctrls-c-min-gain-val/266812
							*/
							min_gain_val = "1";                   /* dB */
							max_gain_val = "300";                 /* dB */
							step_gain_val = "3";                  /* 0.3 */
							default_gain = "0";
							min_hdr_ratio = "1";
							max_hdr_ratio = "1";
							framerate_factor = "1000000";
							min_framerate = "30000000";
							max_framerate = "30000000";
							step_framerate = "1";
							default_framerate = "30000000";
							exposure_factor = "1000000";
							min_exp_time = "24";                  /* us 1 line */
							max_exp_time = "33333";
							step_exp_time = "1";
							default_exp_time = "33333";           /* us */
							embedded_metadata_height = "0";
						};

What’s the num-channels in tegra-capture-vi and nvcsi@xxx?

	// ----- tegra-capture-vi -----
	fragment@0{
		target-path = "/tegra-capture-vi";
		__overlay__ {
			num-channels = <4>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					status = "okay";
					reg = <0>;
					vi_in0: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <0>;
						bus-width = <4>;
						remote-endpoint = <&csi_out0>;
					};
				};
				port@1 {
					status = "okay";
					reg = <1>;
					vi_in1: endpoint {
						status = "okay";
						vc-id = <1>;
						port-index = <0>;
						bus-width = <4>;
						remote-endpoint = <&csi_out1>;
					};
				};
				port@2 {
					status = "okay";
					reg = <2>;
					vi_in2: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out2>;
					};
				};
				port@3 {
					status = "okay";
					reg = <3>;
					vi_in3: endpoint {
						status = "okay";
						vc-id = <1>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out3>;
					};
				};
			};
		};
	};

	// -----   NVCSI  ------
	fragment@1 {
		target-path = "/host1x@13e00000/nvcsi@15a00000";
		__overlay__ {
			num-channels = <4>;
			num-ports = <4>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			channel@0 {
				reg = <0>;
				status = "okay";
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						status = "okay";
						csi_in0: endpoint@0 {
							status = "okay";
							port-index = <0>;
							bus-width = <4>;
							remote-endpoint = <&isx021_out0>;
						};
					};
					port@1 {
						reg = <1>;
						status = "okay";
						csi_out0: endpoint@1 {
							status = "okay";
							remote-endpoint = <&vi_in0>;
						};
					};
				};
			};
			channel@1 {
				reg = <1>;
				status = "okay";
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						status = "okay";
						csi_in1: endpoint@2 {
							status = "okay";
							port-index = <0>;
							bus-width = <4>;
						};
					};
					port@1 {
						reg = <1>;
						status = "okay";
						csi_out1: endpoint@3 {
							status = "okay";
							remote-endpoint = <&vi_in1>;
						};
					};
				};
			};
			channel@2 {
				reg = <2>;
				status = "okay";
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						status = "okay";
						csi_in2: endpoint@4 {
							status = "okay";
							port-index = <2>;
							bus-width = <4>;
							remote-endpoint = <&isx021_out2>;
						};
					};
					port@1 {
						reg = <1>;
						status = "okay";
						csi_out2: endpoint@5 {
							status = "okay";
							remote-endpoint = <&vi_in2>;
						};
					};
				};
			};
			channel@3 {
				reg = <3>;
				status = "okay";
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					port@0 {
						reg = <0>;
						status = "okay";
						csi_in3: endpoint@6 {
							status = "okay";
							port-index = <2>;
							bus-width = <4>;
						};
					};
					port@1 {
						reg = <1>;
						status = "okay";
						csi_out3: endpoint@7 {
							status = "okay";
							remote-endpoint = <&vi_in3>;
						};
					};
				};
			};
		};
	};

FYI: There is no remote_endpoint configured for channel1 and channel3 here because I’ve also only configured two cameras in my device tree right now. Thus, these two endpoints wouldn’t have a counter part

So current 4 cameras, do you ever try run the the first and third[1/3] or second and fourth[2/4] combination?

I am only running 1 and 3 right now.

Did you boost the clocks to try.

sudo su
echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/emc/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate
cat /sys/kernel/debug/bpmp/debug/clk/emc/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/emc/rate

yes, I am doing that regularly before checking.

Do you think that the issue might be connected to the deser pix clock value as described in my initial post?

I don’t think so.
Do you check the trace log?

The trace log looks like this:

# tracer: nop
#
# entries-in-buffer/entries-written: 44/44   #P:12
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
        v4l2-ctl-3937    [007] ....   278.525705: tegra_channel_open: vi-output, tier4_isx021 30-001b
        v4l2-ctl-3937    [007] ....   278.531264: tegra_channel_set_power: tier4_isx021 30-001b : 0x1
        v4l2-ctl-3937    [007] ....   278.531276: camera_common_s_power: status : 0x1
        v4l2-ctl-3937    [007] ....   278.531286: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3937    [007] ....   278.531287: csi_s_power: enable : 0x1
        v4l2-ctl-3937    [007] ....   278.531634: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
        v4l2-ctl-3937    [004] ....   278.532369: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-3937    [004] ....   278.537460: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3937    [004] ....   278.537462: csi_s_stream: enable : 0x1
        v4l2-ctl-3937    [004] ....   278.537784: tegra_channel_set_stream: tier4_isx021 30-001b : 0x1
    kworker/10:0-65      [010] ....   278.563863: rtcpu_vinotify_event: tstamp:9928063233 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:317687732928 data:0x359d580010000000
    kworker/10:0-65      [010] ....   278.563865: rtcpu_vinotify_event: tstamp:9928063368 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:317687739360 data:0x0000000031000001
    kworker/10:0-65      [010] ....   278.563865: rtcpu_vinotify_event: tstamp:9928063519 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:317687774720 data:0x359d550010000000
    kworker/10:0-65      [010] ....   278.563866: rtcpu_vinotify_event: tstamp:9928063650 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:317687781568 data:0x0000000031000002
 vi-output, tier-3939    [007] ....   281.344237: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
    kworker/10:0-65      [010] ....   281.703808: rtcpu_vinotify_event: tstamp:10026433998 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:320843380896 data:0x359d580010000000
    kworker/10:0-65      [010] ....   281.703810: rtcpu_vinotify_event: tstamp:10026434133 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:320843387360 data:0x0000000031000001
    kworker/10:0-65      [010] ....   281.703811: rtcpu_vinotify_event: tstamp:10026434284 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:320843427712 data:0x359d550010000000
    kworker/10:0-65      [010] ....   281.703811: rtcpu_vinotify_event: tstamp:10026434414 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:320843434272 data:0x0000000031000002
 vi-output, tier-3939    [007] ....   284.416269: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
    kworker/10:0-65      [010] ....   284.447745: rtcpu_vinotify_event: tstamp:10111621128 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:323571754272 data:0x359d580010000000
    kworker/10:0-65      [010] ....   284.447748: rtcpu_vinotify_event: tstamp:10111621263 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:323571760736 data:0x0000000031000001
    kworker/10:0-65      [010] ....   284.447748: rtcpu_vinotify_event: tstamp:10111621416 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:323571801088 data:0x359d550010000000
    kworker/10:0-65      [010] ....   284.447749: rtcpu_vinotify_event: tstamp:10111621546 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:323571807616 data:0x0000000031000002
 vi-output, tier-3939    [007] ....   287.232170: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
    kworker/10:0-65      [010] ....   287.247694: rtcpu_vinotify_event: tstamp:10199616530 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:326387654048 data:0x359d580010000000
    kworker/10:0-65      [010] ....   287.247695: rtcpu_vinotify_event: tstamp:10199616682 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:326387660512 data:0x0000000031000001
    kworker/10:0-65      [010] ....   287.247696: rtcpu_vinotify_event: tstamp:10199616836 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:326387700896 data:0x359d550010000000
    kworker/10:0-65      [010] ....   287.247696: rtcpu_vinotify_event: tstamp:10199616967 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:326387707424 data:0x0000000031000002
 vi-output, tier-3939    [010] ....   290.048091: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
    kworker/10:0-65      [010] ....   290.103771: rtcpu_vinotify_event: tstamp:10287640840 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:329203578528 data:0x359d580010000000
    kworker/10:0-65      [010] ....   290.103772: rtcpu_vinotify_event: tstamp:10287640975 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:329203584992 data:0x0000000031000001
    kworker/10:0-65      [010] ....   290.103773: rtcpu_vinotify_event: tstamp:10287641128 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:329203620384 data:0x359d550010000000
    kworker/10:0-65      [010] ....   290.103773: rtcpu_vinotify_event: tstamp:10287641259 cch:0 vi:0 tag:VIFALC_TDSTATE channel:0x23 frame:0 vi_tstamp:329203626912 data:0x0000000031000002
        v4l2-ctl-3937    [002] ....   290.730915: tegra_channel_close: vi-output, tier4_isx021 30-001b
 vi-output, tier-3939    [010] ....   292.640084: tegra_channel_capture_setup: vnc_id 0 W 1920 H 1280 fmt 13
        v4l2-ctl-3937    [009] ....   292.649920: tegra_channel_set_stream: enable : 0x0
        v4l2-ctl-3937    [009] ....   292.649923: tegra_channel_set_stream: tier4_isx021 30-001b : 0x0
        v4l2-ctl-3937    [009] ....   292.650481: tegra_channel_set_stream: 13e40000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3937    [009] ....   292.650487: csi_s_stream: enable : 0x0
        v4l2-ctl-3937    [009] ....   292.653324: tegra_channel_set_power: tier4_isx021 30-001b : 0x0
        v4l2-ctl-3937    [009] ....   292.653337: camera_common_s_power: status : 0x0
        v4l2-ctl-3937    [009] ....   292.653348: tegra_channel_set_power: 13e40000.host1x:nvcsi@15a00000- : 0x0
        v4l2-ctl-3937    [009] ....   292.653350: csi_s_power: enable : 0x0
~                                                                            

@ShaneCCC

Still very interested in your feedback to the trace log!

In the meantime, I found out that just adding a port to my working one-camera device tree triggers the issue.

Working one-camera version:

	// ----- tegra-capture-vi -----
	fragment@0{
		target-path = "/tegra-capture-vi";
		__overlay__ {
			num-channels = <1>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					status = "okay";
					reg = <0>;
					vi_in0: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out0>;
					};
				};
			};
		};
	};

Just by adding a port which shouldn’t have an effect, the initially described issue gets triggered:

	// ----- tegra-capture-vi -----
	fragment@0{
		target-path = "/tegra-capture-vi";
		__overlay__ {
			num-channels = <2>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					status = "okay";
					reg = <0>;
					vi_in0: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out0>;
					};
				};
				port@1 {
					status = "okay";
					reg = <1>;
					vi_in1: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <0>;
						bus-width = <4>;
					};
				};
			};
		};
	};

Is that expected behavior? The first, previously working, camera is still mounted correctly, but the stream doesn’t start and receives continuous timeouts.

Just wanted to let you know since it seems a bit strange to me.
Thanks!

Shouldn’t have the same vc-id

Ok, I will try that.

Just to clarify:
To my understanding, the vc-id can be the same value as long as the port-index is different? Is that wrong?

My assumption was that I can use vc-id 0 and 1 for all the separate port-index values:

	// ----- tegra-capture-vi -----
	fragment@0{
		target-path = "/tegra-capture-vi";
		__overlay__ {
			num-channels = <4>;
			#address-cells = <1>;
			#size-cells = <0>;
			status = "okay";
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					status = "okay";
					reg = <0>;
					vi_in0: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <0>;
						bus-width = <4>;
						remote-endpoint = <&csi_out0>;
					};
				};
				port@1 {
					status = "okay";
					reg = <1>;
					vi_in1: endpoint {
						status = "okay";
						vc-id = <1>;
						port-index = <0>;
						bus-width = <4>;
						remote-endpoint = <&csi_out1>;
					};
				};
				port@2 {
					status = "okay";
					reg = <2>;
					vi_in2: endpoint {
						status = "okay";
						vc-id = <0>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out2>;
					};
				};
				port@3 {
					status = "okay";
					reg = <3>;
					vi_in3: endpoint {
						status = "okay";
						vc-id = <1>;
						port-index = <2>;
						bus-width = <4>;
						remote-endpoint = <&csi_out3>;
					};
				};
			};
		};
	};

Am I getting this wrong?

OK, I didn’t find they are different port-index.
Looks like lost the remote-endpoint =

Ok!

I removed the remote-endpoint only for testing purposes in my example device tree. As mentioned, this is a device tree that works for a single camera and I only added the port1 to it. Nothing else. In order to generate the device tree correctly, I had to remove the remote endpoint because the target doesn’t exists obviously. I think that shouldn’t be the relevant point why it’s not working. Right?

Do you have any thoughts on the kernel trace log I’ve shared? Is there anything we can learn from it?

The trace log shows didn’t receive any validate data from sensor.
Could you print the port-index/bus-width to confirm.

Do you mean the values in my device tree? Or how can I print it on my system?

Add debug print in the vi5_fops.c and csi5_fops.c

Unfortunately, I can’t find both of these files on my Jetson Orin. Where are they supposed to be located?

They are in the kernel source. You need to get the source code to modify and build it.

Hey @ShaneCCC,

turns out that the problem has to do with the device tree overlay we’ve used to get our camera device tree into the system device tree. Still figuring out what exactly is causing this, but all cameras work now.

fyi: we’re building the device tree within the Orin DevKit build environment now.

Thanks for your support!

1 Like