Capture not working on second camera

I was using extperiph1 and it didn’t work.

I changed to extperiph2 after looking at the product design guide:

Looks like it is incorrect, so I will switch back to extperiph1.

But using extperiph1 will not get the data clock on the second camera:

as a reminder, the I2C transfers work on the second camera, so I2C mux switching works fine.
Issue seems to be no clock or data on the second 4-lane CSI interface.

hello alain.gautherot,

may I double confirm the Jetpack release version you’re now using?

for testing, is it possible to configure as 2-lane config?
we’ve reference camera device that used 2-lane on CSI-C and it works normally.

I am using jetpack 5.1.1/jetlinux 35.3.1, I double-checked using dpkg:

nvidia@sdj-floyd-12:~$ dpkg -l | grep jetson
ii  jetson-gpio-common                         2.1.1ubuntu1                         arm64        Jetson GPIO library package (common files)
ii  nvidia-l4t-jetson-io                       35.3.1-20230319081403                arm64        NVIDIA Jetson.IO debian package
ii  nvidia-l4t-jetsonpower-gui-tools           35.3.1-20230319081403                arm64        NVIDIA Jetson Power GUI Tools debian package
...

or “jtop”:

image

The sensor IMX492 only works with 4 lanes, unfortunately, there is no 2-lane option.

hello alain.gautherot,

please have a try to remove those clock definitions, and let driver to use default clock settings.
for example,
please remove below…
i2c@1 {
rbpcv2_imx492_c@1a {
compatible = “nvidia,imx492”;
clocks = <0x04 0x25 0x04 0x25>;
clock-names = “extperiph2\0pllp_grtba”;
mclk = “extperiph2”;

I tried it and it doesn’t help.
updated DTS dump here: output_remove_video1_clks.txt (477.5 KB)

hello alain.gautherot,

there’re some dev_dbg(), you may also enable debug logs within $public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/camera_common.c
for example,

int camera_common_s_power(struct v4l2_subdev *sd, int on)
{
...
                if (tegra_platform_is_silicon()) {
                        err = camera_common_mclk_enable(s_data);
int camera_common_mclk_enable(struct camera_common_data *s_data)
{
...
        dev_dbg(s_data->dev, "%s: enable MCLK with %lu Hz\n",
                __func__, mclk_init_rate);

it all looks fine to me (matching DTS)
dmesg_camera_common_dbg.txt (6.6 KB)

hello alain.gautherot,

ya… it looks works normally without failures.
we’ve also verified 4-lane configuration camera on CSI-C for AGX Xavier with r35.3.1.

I’ve check your previous topic again, i.e. Topic 256155.
are you still using virtual channels? I don’t see vc-id and settings for IMX492 port settings within your disassembler dtb file

for example,

		tca9548@70 {
			compatible = "nxp,pca9548";
				i2c@0 {
				rbpcv2_imx492_a@1a {
					compatible = "nvidia,imx492";
					ports {
						port@0 {
							endpoint {
								vc-id = <0>; <== also add virtual channel id here.
								port-index = <0x00>;
								bus-width = <0x04>;

furthermore,
the virtual channel ID should also with 0 for your 2nd camera, since there’s only single device connected to CSI-C.
for example,

	tegra-capture-vi {
		ports {
			port@0 {
				endpoint {
					vc-id = <0x00>;
					port-index = <0x00>;
					bus-width = <0x04>;
			
			port@1 {
				endpoint {
					vc-id = <0x01>;  <== please use  vc-id = <0>;  for this node. 
					port-index = <0x02>; 
					bus-width = <0x04>;
			i2c@1 {
				rbpcv2_imx492_c@1a {
					mode0 {
						tegra_sinterface = "serial_c";
						vc_id = [31 00];  <== you may revised it as.. vc_id = <0>;
...
					ports {
						port@0 {
							endpoint {
								vc-id = <0>; <== also add virtual channel id here.
								port-index = <0x02>;
								bus-width = <0x04>;

I don’t know if I need or have to use the virtual channels. I added the “vc-id” statements in the DTS based on the discussion thread and that’s how I got the camera devices /dev/video0 and /dev/video1 created.

I tried changing all vc-id to zero for the second camera as well as in its modes.
It doesn’t seem to help.
I tried removing the “clocks”, “clock-names” and “mclk” statements for the second camera just in case, but it didn’t help either.
here’s how the DTS look like now: jp5_fix_vi_rm_extperiph.txt (477.6 KB)

dmesg log for second camera looks the same (with added logging):

[  190.802051] imx492 31-001a: camera_common_try_fmt: size 8432 x 5648
[  190.802065] imx492 31-001a: camera_common_try_fmt: use_sensor_mode_id 1
[  190.802106] imx492 31-001a: camera_common_s_fmt(12306) size 8432 x 5648
[  190.802128] imx492 31-001a: camera_common_try_fmt: size 8432 x 5648
[  190.802132] imx492 31-001a: camera_common_try_fmt: use_sensor_mode_id 1
[  190.889564] imx492 31-001a: imx492_power_on: enter
[  190.889576] imx492 31-001a: imx492_power_on: power on2
[  190.889581] imx492 31-001a: imx492_power_on: reset 432 lo
[  190.889658] imx492 31-001a: imx492_power_on: dvdd on
[  190.889667] imx492 31-001a: imx492_power_on: iovdd on
[  190.889673] imx492 31-001a: imx492_power_on: avdd on
[  190.889801] imx492 31-001a: imx492_power_on: reset 432 hi
[  190.889819] imx492 31-001a: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[  190.890188] imx492 31-001a: camera_common_dpd_disable: csi 2
[  190.890196] imx492 31-001a: camera_common_dpd_disable: csi 3
[  191.069134] imx492 31-001a: imx492_set_mode 868: HMAX=2193 => 1202
[  191.069530] imx492 31-001a: imx492_set_mode: wrote HMAX=1202 (0x4b2) for mode 0, 8432x5648
[  193.503571] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  193.503895] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  193.505343] (NULL device *): vi_capture_control_message: NULL VI channel received
[  193.505544] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  193.505922] (NULL device *): vi_capture_control_message: NULL VI channel received
[  193.506101] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 1
[  193.506742] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  196.035588] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  196.035968] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  196.037311] (NULL device *): vi_capture_control_message: NULL VI channel received
[  196.037501] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
[  196.037723] (NULL device *): vi_capture_control_message: NULL VI channel received
[  196.037906] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_open: VI channel not found for stream- 2 vc- 1
[  196.038535] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: successfully reset the capture channel
[  196.155429] imx492 31-001a: camera_common_dpd_enable: csi 2
[  196.155444] imx492 31-001a: camera_common_dpd_enable: csi 3
[  196.155453] imx492 31-001a: camera_common_mclk_disable: disable MCLK
[  196.155464] imx492 31-001a: imx492_power_off: enter
[  196.155472] imx492 31-001a: imx492_power_off: power off2
[  196.155478] imx492 31-001a: imx492_power_off: reset lo
[  196.155622] imx492 31-001a: imx492_power_off: dvdd off
[  196.155675] imx492 31-001a: imx492_power_off: iovdd off
[  196.155685] imx492 31-001a: imx492_power_off: avdd off

hello alain.gautherot,

have you swap the camera module to confirm it’s not hardware issue?

according to those kernel logs, mclk had apply, set_mode is done.
please also add debug logs into below for checking tegra_channel_set_stream, it’s v4l control to call s_stream to enable camera stream, and then it’s VI engine wait for frames.
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c

besides, there’s timeout value of VI driver, it’s default configured as 2500ms.
i.e. vi/vi5_fops.c:#define CAPTURE_TIMEOUT_MS 2500
please try increase this if you’ve confirm s_stream is being called corrrectly.

both camera modules are functional.
I had already tried swapping them and see the same thing: camera module on first port always works, camera module on second port never works.

I changed the timeout to 10s (from default 2.5s), then enabled and added logs in various files:
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/vi5_fops.c
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/nvcsi/csi5_fops.c
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/fusa-capture/capture-vi.c
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/vi/channel.c
$public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/camera_common.c

attached are the output dmesg for camera 0 (working):
floyd12_added_debug_cam0.txt (16.0 KB)

and for camera 1 (not working, timeout):
floyd12_added_debug_cam1.txt (8.7 KB)

here’s the part you were wondering about (tegra_channel_set_stream):

[   85.455565] tegra_channel_set_stream: channel id 1, on=1    # <== channel id 0 for camera 0
[   85.455571]   vi_channel_ids[]: 0 0 0   # <== same values for camera 0, is that normal?
[   85.455576]   port[]: 2 255 255         # <== port[0] = 0 for camera 0
[   85.455579]   virtual_channel: 1        # <== virtual channel 0 for camera 0
[   85.455583]   timeout: 0
[   85.455586]   stride_align: 1
[   85.455590]   preferred_stride: 0
[   85.455593]   width_align: 1
[   85.455596]   height_align: 1
[   85.455600]   size_align: 1
[   85.455603]   valid_ports: 1
[   85.455607]   total_ports: 1
[   85.455610]   numlanes: 4
[   85.455613]   io_id: 0
[   85.455617]   num_subdevs: 2
[   85.455620]   sequence: 0
[   85.455624]   bypass 0, write isp 1, lowlat 0, state 1     # <== not sure why "write ISP" is 1 (for both cameras)
[   85.455627]   vnc_id[]: 0 0 0
[   85.455631]   link_status 1, is_slvsec 0, is_interlaced 0
[   85.455638]   num_channels 2
[   85.455642]   num_subdevs 0
[   85.455645]   bypass 0

I have captured the return value of various functions related to starting/deskewing (v4l2_subdev_call, tegra_channel_start_streaming, …), and the return values are all 0 (OK):

[   85.460015] tegra_channel_set_stream on=1: attempt 0, v4l2_subdev_call 0 -> 0
[   85.634769] tegra_channel_set_stream on=1: attempt 0, v4l2_subdev_call 1 -> 0
[   85.634802] tegra_channel_start_streaming: vi_start_streaming: 0

I’m so confused with ports, CSI ports, channels, virtual channels, that I expect I made a mistake there.
Do all port/channel settings look good to you?

Also, you mention that you’ve validated" 4-lane configuration camera on CSI-C for AGX Xavier with r35.3.1".
are the corresponding files part of jetpack 5.1.1? if not, are these something you could share or point me to?

Thanks,
Alain

hello alain.gautherot,

could you please also review the sensor specification for sensor power-on sequence,
you may confirm the sequence is within minimum waiting times.
for example,

[   85.453755] imx492 31-001a: imx492_power_on: power on2
[   85.453761] imx492 31-001a: imx492_power_on: reset 432 lo
[   85.453839] imx492 31-001a: imx492_power_on: dvdd on
[   85.453847] imx492 31-001a: imx492_power_on: iovdd on
[   85.453853] imx492 31-001a: imx492_power_on: avdd on
[   85.453903] imx492 31-001a: imx492_power_on: reset 432 hi

according to the debug messages, it looks reset signal toggle high as soon as 2.8V has applied.
it usually has minimum time interval for reset signal, i.e. >100ns
please try adding usleep_range() or msleep for putting some delay before pin state change.

there’s device tree, tegra194-camera-imx274-dual.dtsi for your reference.
it’s available via… $public_sources/kernel_src/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-imx274-dual.dtsi

I looked at the sensor spec, and there’s only a 500ns delay between vdd’s turned on and reset line driven low (inactive). For the sake of it, I just added delays before and after the reset line being driven low and high:

[   92.168439] imx492 31-001a: imx492_power_on: enter
[   92.168449] imx492 31-001a: imx492_power_on: power on2
[   92.169699] imx492 31-001a: imx492_power_on: sleep >=1ms (new)     # <== new 1ms delay
[   92.169706] imx492 31-001a: imx492_power_on: reset 432 lo
[   92.170961] imx492 31-001a: imx492_power_on: sleep >=1ms (new)     # <== new 1ms delay
[   92.170969] imx492 31-001a: imx492_power_on: dvdd on
[   92.170999] imx492 31-001a: imx492_power_on: iovdd on
[   92.171008] imx492 31-001a: imx492_power_on: avdd on
[   92.172237] imx492 31-001a: imx492_power_on: sleep >=1ms (was >=10us)     # <== increased delay from 10us to 1ms
[   92.172244] imx492 31-001a: imx492_power_on: reset 432 hi
[   92.173482] imx492 31-001a: imx492_power_on: sleep >=1ms (was >=10us)     # <== new 1ms delay
[   92.173492] imx492 31-001a: camera_common_mclk_enable: enable MCLK with 24000000 Hz
[   92.173712] imx492 31-001a: camera_common_dpd_disable: csi 2
[   92.173720] imx492 31-001a: camera_common_dpd_disable: csi 3

corresponding dmesg log looks the same, excepted the added logging entries: floyd12_added_reset_delays.txt (23.2 KB)

I would have been suprised that it made a difference since driver works fine with Jetpack 4.6.1.

I’ll have yet another looks to that dual IMX274 configuration, maybe I missed something…

Hi Jerry,
any other thoughts or suggestions?

as we don’t have 4-lane configuration camera for Xavier NX.
Xavier series sharing the same code flow to process the frames. so, we’ve checked this with CSI-C for AGX Xavier/l4t-r35.3.1 and it works normally.

hello alain.gautherot,

let’s follow-up here…

please download the debug firmware debug-camera-fw.7z (198.8 KB) for JetPack-5.1.1 / l4t-r35.3.1 release version.
you may performing a partition update to re-flash binary to the target.
please replace the debug firmware with… $OUT/Linux_for_Tegra/bootloader/camera-rtcpu-t194-rce.img
note, you should running partition flash to update camera firmware, i.e. $ sudo ./flash.sh -r -k rce-fw jetson-agx-xavier-devkit mmcblk0p1
you should revise the board-name since you’re working with a customize board,
here’s see-also Topic 226574 for sample commands to apply debug firmware with flash script.

after system boot-up, you may enable camera use-case to check the logs,
the RCE debug logs will populate to kernel logs, i.e. $ dmesg
please try running v4l2-ctl to fetch second camera and sharing the RCE debug messages.

besides, JetPack 5.1.2 is now available, this release include several camera bug fixes,
for example,

  • Enhanced error resiliency for improved stability in Argus
  • Support for multiple camera synchronization (sample argus_syncstereo added)
  • Deskew calibration support for high data rate sensors (data-rate > 1.5 Gbps)
  • Support for alternating exposures in Argus (sample argus_userAlternatingAutoexposure added)

hence,
please moving to the latest release if that’s possible.

Hi Jerry,
I moved to Jetpack 5.1.2 (R35.4.1) and flashed the debug camera FW you provided.
please find the dmesg output attached.
dmesg_rce.txt (78.1 KB)

hello alain.gautherot,

it looks some settings are missing,
please have a try overriding tegra-capture-vi -> port@1 with the default vc-id.
for example,

tegra-capture-vi {
	compatible = "nvidia,tegra-camrtc-capture-vi";
	ports {
		port@1 {
			endpoint {
				vc-id = <0x01>;   <== this is unexpected. please revise with vc-id = "0";
				port-index = <0x02>;
				bus-width = <0x04>;

besides,
sensor side settings this should also update as following.

			i2c@1 {
				rbpcv2_imx492_c@1a {
					mode0 {
						mclk_khz = "24000";
						num_lanes = [34 00];
						tegra_sinterface = "serial_c";
						vc_id = [31 00]; <== this also unexpected. please revise with vc-id = "0";

please test again, and sharing the test results.

furthermore,
please do disassembler the latest dtb file into text file for examination.
i.e. $ dtc -I dtb -O dts -o output.txt tegra194-xxx.dtb

Aaah, looks like it’s working now.

I did have vc_id = "0" in the various sensor modes, but still had the incorrect settings in the tegra-capture-vi block, like you highlighted:

	capture_vi_base: tegra-capture-vi {
		num-channels = <3>;
		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			vi_port0: port@0 {
				reg = <0>;
				rbpcv2_imx492_vi_in0: endpoint {
					vc-id = <0>;
					port-index = <0>;
					bus-width = <4>;
					remote-endpoint = <&rbpcv2_imx492_csi_out0>;
				};
			};
			vi_port1: port@1 {
				reg = <1>;
				rbpcv2_imx492_vi_in1: endpoint {
					vc-id = <0>;                     ### <== changed from <1>
					port-index = <2>;
					bus-width = <4>;
					remote-endpoint = <&rbpcv2_imx492_csi_out1>;
				};
			};
			eimx462_vi_port2: port@2 {
				reg = <2>;
				eimx462_vi_in2: endpoint {
					vc-id = <0>;                     ### <== changed from <2>
					port-index = <4>;
					bus-width = <4>;
					remote-endpoint = <&eimx462_csi_out2>;
				};
			};

		};
	};

Thanks so much for your help!

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.