Capture not working on second camera

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
1

as requested, creating a separate thread which is is a continuation of thread Camera driver loaded but no /dev/videoX

After adding virtual channel to DTS, both cameras are detected as /dev/video0 and /dev/video1.
I’m able to capture from /dev/video0:

$ v4l2-ctl --set-fmt-video=width=8432,height=5648,pixelformat=RG10 --set-ctrl sensor_mode=1,bypass_mode=0 --stream-mmap -d0
<<<<<<<<<<<<<<< 13.66 fps
<<<<<<<<<<<<<< 13.66 fps
<<<<<<<<<<<<^C
$ v4l2-ctl --set-fmt-video=width=8432,height=5648,pixelformat=RG12 --set-ctrl sensor_mode=0,bypass_mode=0 --stream-mmap -d0
<<<<<<<<<<<< 10.46 fps
<<<<<<<<<<< 10.46 fps
<<<<<<<<^C

but capture hangs on second camera. dmesg shows errors

[  335.569167] imx492 31-001a: imx492_set_mode: wrote HMAX=1202 (0x4b2) for mode 0, 8432x5648
[  338.143576] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  338.143888] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
[  338.146037] (NULL device *): vi_capture_control_message: NULL VI channel received
[  338.146961] t194-nvcsi 13e10000.host1x:nvcsi@15a00000: csi5_stream_close: Error in closing stream_id=2, csi_port=2
...
2

Per @JerryChang:

please double check the power-on/off sequence,
since it’s based-on tca9548@70 to register these two cameras at… i2c@0 and i2c@1. you may examine it’s also given correct power-supply to imx492 31-001a.

4

that part of the DTS is the same between jetpack 4.6.1 (working case) and jetpack 5.1.1.

#define CAM0_PWDN	TEGRA194_MAIN_GPIO(P, 4)
#define CAM1_PWDN	TEGRA194_MAIN_GPIO(P, 5)

#define CAM_I2C_MUX 	TEGRA194_AON_GPIO(CC, 3)
#define CAMERA_I2C_MUX_BUS(x) (0x1E + x)

/ {
	i2c@3180000{
		tca9548@70 {
			compatible = "nxp,pca9548";
			reg = <0x70>;
			#address-cells = <1>;
			#size-cells = <0>;
			vcc-supply = <&p3509_vdd_1v8_cvb>;
			vcc_lp = "vcc";
			skip_mux_detect = "yes";
			force_bus_start = <CAMERA_I2C_MUX_BUS(0)>;
			status = "okay";
			i2c@0 {
				reg = <0>;
				i2c-mux,deselect-on-exit;
				#address-cells = <1>;
				#size-cells = <0>;
				status = "okay";

				rbpcv2_imx492_a@1a {
					status = "okay";
					clocks = <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>,
							 <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>;
					clock-names = "extperiph1", "pllp_grtba";
					mclk = "extperiph1";

					reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
					vana-supply = <&p3509_avdd_cam_2v8>;
					vif-supply = <&p3509_vdd_1v8_cvb>;
					vdig-supply = <&p3509_vdd_sys_en>;
				};
			};
			i2c@1 {
				reg = <1>;
				i2c-mux,deselect-on-exit;
				#address-cells = <1>;
				#size-cells = <0>;
				status = "okay";

				rbpcv2_imx492_c@1a {
					status = "okay";
					clocks = <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>,
							 <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>;
					clock-names = "extperiph1", "pllp_grtba";
					mclk = "extperiph1";

					reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
					vana-supply = <&p3509_avdd_cam_2v8>;
					vif-supply = <&p3509_vdd_1v8_cvb>;
					vdig-supply = <&p3509_vdd_sys_en>;
				};
			};
		};
	};
};

what power up/down sequence are you referring to. is that related to when overlay is applied or how sensor gets initialized in the driver?

1 Like
5

hello alain.gautherot,

(1) are those PP.04 and PP.05 defined as reset pins correctly?
please refer to debug node to check GPIOs. for example, # cat /sys/kernel/debug/gpio | grep PP

(2) please have another ways to define this pin,
here’s an example, reset-gpios = <&tegra_main_gpio 432 GPIO_ACTIVE_HIGH>;

(3) please review the sensor driver side, is sensor gets initialized correctly from driver layer?

6

(1) are those PP.04 and PP.05 defined as reset pins correctly?
(2) please have another ways to define this pin,

yes, I checked that exporting gpio 431 and 432 respectively export PP.04 and PP.05 and I checked that they are both output, high, activate low and edge=none.

(3) please review the sensor driver side, is sensor gets initialized correctly from driver layer?

yes, both cameras are initialized properly as showing in dmesg:

nvidia@sdj-floyd-12:/sys/class/gpio$ sudo dmesg | grep imx
[   11.163954] imx492 30-001a: probing v4l2 sensor: pleno/alain/8
[   11.164811] imx492 30-001a: tegracam sensor driver:imx492_v2.0.6
[   11.367111] imx492 30-001a: imx492_set_gain: val:1000000, gain:1, again:(1, 0), dgain:(1, 0)
[   11.367891] imx492 30-001a: imx492_set_exposure: val: 0
[   11.367897] imx492 30-001a: imx492_calculate_exposure_shr: val: 0
[   11.367902] imx492 30-001a: imx492_calculate_exposure_shr: shr440: 0, vmax: 0, svr: 0
[   11.367906] imx492 30-001a: imx492_calculate_exposure_shr: shr444: 12
[   11.367910] imx492 30-001a: imx492_calculate_exposure_shr: shr453: 12
[   11.368386] imx492 30-001a: imx492_set_frame_rate: val: 0, svr:0, vmax:0
[   11.369282] imx492 30-001a: imx492_set_frame_rate: PCLK:576000000, LL:9622, fps:0.00, HMAX:0, VMAX:5728, SVR=0
[   11.369359] imx492 30-001a: imx492_set_black_level: val: 0 => 0
[   11.369364] imx492 30-001a: imx492_set_black_level: write addr 3043 with 0000
[   11.369587] imx492 30-001a: imx492_set_black_level: write addr 3042 with 0000
[   11.370011] imx492 30-001a: imx492_set_gain: val:1000000, gain:1, again:(1, 0), dgain:(1, 0)
[   11.370662] imx492 30-001a: imx492_set_exposure: val: 21
[   11.370671] imx492 30-001a: imx492_calculate_exposure_shr: val: 21
[   11.370677] imx492 30-001a: imx492_calculate_exposure_shr: shr440: 5728, vmax: 5728, svr: 0
[   11.370682] imx492 30-001a: imx492_calculate_exposure_shr: shr449: 5724
[   11.370687] imx492 30-001a: imx492_calculate_exposure_shr: shr453: 5724
[   11.371084] imx492 30-001a: imx492_set_frame_rate: val: 2000000, svr:0, vmax:5728
[   11.371954] imx492 30-001a: imx492_set_frame_rate: PCLK:576000000, LL:9622, fps:2.00, HMAX:0, VMAX:5728, SVR=0
[   11.371983] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx492 30-001a bound
[   11.374648] imx492 30-001a: Probed IMX492 sensor
[   11.393522] imx492 31-001a: probing v4l2 sensor: pleno/alain/8
[   11.394365] imx492 31-001a: tegracam sensor driver:imx492_v2.0.6
[   11.596604] imx492 31-001a: imx492_set_gain: val:1000000, gain:1, again:(1, 0), dgain:(1, 0)
[   11.597336] imx492 31-001a: imx492_set_exposure: val: 0
[   11.597344] imx492 31-001a: imx492_calculate_exposure_shr: val: 0
[   11.597350] imx492 31-001a: imx492_calculate_exposure_shr: shr440: 0, vmax: 0, svr: 0
[   11.597356] imx492 31-001a: imx492_calculate_exposure_shr: shr444: 12
[   11.597361] imx492 31-001a: imx492_calculate_exposure_shr: shr453: 12
[   11.597789] imx492 31-001a: imx492_set_frame_rate: val: 0, svr:0, vmax:0
[   11.598661] imx492 31-001a: imx492_set_frame_rate: PCLK:576000000, LL:9622, fps:0.00, HMAX:0, VMAX:5728, SVR=0
[   11.598709] imx492 31-001a: imx492_set_black_level: val: 0 => 0
[   11.598716] imx492 31-001a: imx492_set_black_level: write addr 3043 with 0000
[   11.598895] imx492 31-001a: imx492_set_black_level: write addr 3042 with 0000
[   11.599148] imx492 31-001a: imx492_set_gain: val:1000000, gain:1, again:(1, 0), dgain:(1, 0)
[   11.599706] imx492 31-001a: imx492_set_exposure: val: 21
[   11.599713] imx492 31-001a: imx492_calculate_exposure_shr: val: 21
[   11.599719] imx492 31-001a: imx492_calculate_exposure_shr: shr440: 5728, vmax: 5728, svr: 0
[   11.599724] imx492 31-001a: imx492_calculate_exposure_shr: shr449: 5724
[   11.599729] imx492 31-001a: imx492_calculate_exposure_shr: shr453: 5724
[   11.600939] imx492 31-001a: imx492_set_frame_rate: val: 2000000, svr:0, vmax:5728
[   11.610091] imx492 31-001a: imx492_set_frame_rate: PCLK:576000000, LL:9622, fps:2.00, HMAX:0, VMAX:5728, SVR=0
[   11.610120] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx492 31-001a bound
[   11.667511] imx492 31-001a: Probed IMX492 sensor

I checked rail and power status with “sudo cat /sys/kernel/debug/regulator/rail_states” and “sudo cat /sys/kernel/debug/regulator/power_tree”. I see:

...
regulator.3 (vdd-3v3-cvb): OFF(0)    <== this is "ON" for jetpack4.6.1
regulator.4 (vdd-1v8-cvb): ON(1)
...
----regulator.3 (vdd-3v3-cvb)----
        Consumer List:
                regulator.5-SUPPLY: OFF [0:0:0]
        States: OFF
                Open Count: 1
                Enable Count: 0    <== this is "1" on jetpack4.6.1
        Machine Constraints:
                Min Microvolt: 3300000
                Max Microvolt: 3300000
                Always ON: 0
                Boot ON: 0
                Enable Time: 0
                Ramp Delay: 0

so I’m wondering if that “vdd-3v3-cvb” could be the issue.
I just can’t figure out how it’s being set when using jetpack4.6.1.
via DTS?
via an overlay?
or via a client kernel module which enables that rail when loaded?

7

hello alain.gautherot,

regulators were defined in device tree, and it’s kernel driver to parse it and control the power. overlay could overwrite the pre-defined device tree settings.
please refer to below, see fixed-regulators{} for default regulator settings.
$public_sources/kernel_src/hardware/nvidia/platform/t19x/jakku/kernel-dts/common/tegra194-fixed-regulator-p3509-0000-a00.dtsi

8

that’s probably a red herring.
“vdd-epb-1v0” is supplied by “vdd-3v3-cvb” and both are turned off in jetpack5, but only “vdd-epb-1v0” is turned off on jetpack4. probably a SW bug in power management that was fixed.

[    0.801798] vdd-epb-1v0: 1000 mV
[    0.801982] vdd-epb-1v0: supplied by vdd-3v3-cvb
...
[   34.128013] vdd-epb-1v0: disabling
[   34.144038] vdd-3v3-cvb: disabling   <-- missing in jetpack 4.6.1

Could the issue I’m seeing be caused by the camera I2C mux not being controlled properly?
is there any documentation apart from the product design guide to better understand how cameras are connected to Tegra?

any recommendation as to how to debug this?

9

you may toggle this within sensor driver for confirmation.
BTW, please see-also similar thread for using Cam I2C Mux, i.e. Topic 192486.

10

I forced vdd-3v3-cvb on from the camera driver and it didn’t help.

is TCA9548 part of the SoC/module or the carrier board?

if the output of “media-ctl -p” shows that all links are showing as “ENABLED”, does it mean that all clocks required for camera operations are enabled?

nvidia@sdj-floyd-12:~$ media-ctl -p
Media controller API version 5.10.104

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial
bus info
hw revision     0x3
driver version  5.10.104

Device topology
- entity 1: 13e10000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
        pad0: Sink
                <- "imx492 30-001a":0 [ENABLED]
        pad1: Source
                -> "vi-output, imx492 30-001a":0 [ENABLED]

- entity 4: 13e10000.host1x:nvcsi@15a00000- (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
        pad0: Sink
                <- "imx492 31-001a":0 [ENABLED]
        pad1: Source
                -> "vi-output, imx492 31-001a":0 [ENABLED]

- entity 35: imx492 30-001a (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev2
        pad0: Source
                [fmt:SRGGB12_1X12/8432x5648 field:none colorspace:srgb]
                -> "13e10000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 37: vi-output, imx492 30-001a (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video0
        pad0: Sink
                <- "13e10000.host1x:nvcsi@15a00000-":1 [ENABLED]

- entity 51: imx492 31-001a (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev3
        pad0: Source
                [fmt:SRGGB12_1X12/8432x5648 field:none colorspace:srgb]
                -> "13e10000.host1x:nvcsi@15a00000-":0 [ENABLED]

- entity 53: vi-output, imx492 31-001a (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
        pad0: Sink
                <- "13e10000.host1x:nvcsi@15a00000-":1 [ENABLED]

what would explain that no data seems to be received?
is there any debug that can be enabled in the kernel or nvidia drivers to help troubleshoot?

Another question: output of /sys/kernel/debug/gpio are completely different between jetpack 4.6.1 and jetpack 5.1.1.
here’s the output on jetpack 4.6.1:

gpiochipX: GPIOs 248-287, parent: platform/c2f0000.gpio, tegra-gpio-aon:
 gpio-248 (                    )
 gpio-249 (                    )
 gpio-250 (                    )
 gpio-251 (                    )
 gpio-252 (                    )
 gpio-253 (                    |pex-refclk-sel-low  ) out lo
 gpio-254 (                    )
 gpio-255 (                    )
 gpio-256 (                    )
 gpio-257 (                    )
 gpio-258 (                    )
 gpio-259 (                    )
 gpio-260 (                    )
 gpio-261 (                    )
 gpio-262 (                    )
 gpio-263 (                    )
 gpio-264 (                    |sysfs               ) in  lo
 gpio-265 (                    |?                   ) out hi
 gpio-266 (                    |sysfs               ) in  hi
 gpio-267 (                    )
 gpio-268 (GPIO12              )
 gpio-284 (                    |power-key           ) in  hi
 gpio-285 (                    )
 gpio-286 (                    )
 gpio-287 (                    )

and jetpack5, for the same device, produces:

gpiochipX: GPIOs 305-334, parent: platform/c2f0000.gpio, tegra194-gpio-aon:
 gpio-305 (PAA.00              )
 gpio-306 (PAA.01              )
 gpio-307 (PAA.02              )
 gpio-308 (PAA.03              )
 gpio-309 (PAA.04              )
 gpio-310 (PAA.05              )
 gpio-311 (PAA.06              )
 gpio-312 (PAA.07              )
 gpio-313 (PBB.00              )
 gpio-314 (PBB.01              )
 gpio-315 (PBB.02              )
 gpio-316 (PBB.03              )
 gpio-317 (PCC.00              )
 gpio-318 (PCC.01              |pwr                 ) out hi
 gpio-319 (PCC.02              )
 gpio-320 (PCC.03              )
 gpio-321 (PCC.04              )
 gpio-322 (PCC.05              )
 gpio-323 (PCC.06              )
 gpio-324 (PCC.07              )
 gpio-325 (PDD.00              )
 gpio-326 (PDD.01              )
 gpio-327 (PDD.02              )
 gpio-328 (PEE.00              )
 gpio-329 (PEE.01              )
 gpio-330 (PEE.02              )
 gpio-331 (PEE.03              )
 gpio-332 (PEE.04              |power-key           ) in  hi IRQ ACTIVE LOW
 gpio-333 (PEE.05              )
 gpio-334 (PEE.06              )

Is there a way to compare pinmux side-by-side between jetpack 4 and 5?

11

I enabled debug prints in capture-vi.c and when working, I see:

[   55.181892] tegra-camrtc-capture-vi tegra-capture-vi: vi_capture_init++
[   55.182104] tegra194-vi5 15c10000.vi: chan flags 4163
[   55.182115] tegra194-vi5 15c10000.vi: chan mask ffffffffffffffff
[   55.182119] tegra194-vi5 15c10000.vi: queue depth 4
[   55.182124] tegra194-vi5 15c10000.vi: request size 384
[   55.182148] tegra194-vi5 15c10000.vi: csi_stream_id 0
[   55.182152] tegra194-vi5 15c10000.vi: vi unit id 0
[   55.182157] tegra194-vi5 15c10000.vi: vi2 chan mask ffffffffffffffff
[   55.190628] tegra194-vi5 15c10000.vi: 0 GoS tables configured.
[   55.190637] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: sending chan_id 64 msg_id 30
[   55.191200] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: response chan_id 64 msg_id 17
[   55.191670] tegra194-vi5 15c10000.vi: vi_capture_request: sending chan_id 0 msg_id 1 buf:0
[   55.191703] tegra194-vi5 15c10000.vi: vi_capture_request: sending chan_id 0 msg_id 1 buf:1
[   55.191722] tegra194-vi5 15c10000.vi: vi_capture_status: waiting for status, timeout:2500 ms
[   55.191725] tegra194-vi5 15c10000.vi: vi_capture_request: sending chan_id 0 msg_id 1 buf:2
[   55.191733] tegra194-vi5 15c10000.vi: vi_capture_request: sending chan_id 0 msg_id 1 buf:3
[   55.195374] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: sending chan_id 0 msg_id 64
[   55.195672] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: response chan_id 0 msg_id 65
[   55.195685] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: sending chan_id 0 msg_id 54
[   55.196025] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: response chan_id 0 msg_id 55
[   55.374879] imx492 30-001a: imx492_set_mode 869: HMAX=2193 => 1202
[   55.375399] imx492 30-001a: imx492_set_mode: wrote HMAX=1202 (0x4b2) for mode 0, 8432x5648
[   55.565806] tegra194-vi5 15c10000.vi: vi_capture_ivc_status_callback: status chan_id 0 msg_id 2

for the second camera, there is no “vi_capture_ivc_status_callback” print, but the timeout message instead:

...
[   99.519245] tegra194-vi5 15c10000.vi: vi_capture_status: waiting for status, timeout:2500 ms
[   99.522792] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: sending chan_id 0 msg_id 64
[   99.522880] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: response chan_id 0 msg_id 65
[   99.522889] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: sending chan_id 0 msg_id 54
[   99.523204] tegra194-vi5 15c10000.vi: vi_capture_ivc_send_control: response chan_id 0 msg_id 55

[  102.111292] tegra194-vi5 15c10000.vi: capture status timed out       <== ### not vi_capture_ivc_status_callback ###

[  102.111312] tegra-camrtc-capture-vi tegra-capture-vi: uncorr_err: request timed out after 2500 ms
[  102.111665] tegra-camrtc-capture-vi tegra-capture-vi: err_rec: attempting to reset the capture channel
...
12

hello alain.gautherot,

GPIO number has changed since K-5.10, you may see-also developer guide, To check a GPIO number.

13

I have validated that power rail is on and reset lines are toggling correctly.
when first camera is started, I see its reset line going high:

nvidia@sdj-floyd-12:~/misc$ sudo cat /sys/kernel/debug/gpio | egrep "PP.0[45]"
 gpio-431 (PP.04               |cam_reset_gpio      ) out hi    <-- first camera nreset is high: OK
 gpio-432 (PP.05               |cam_reset_gpio      ) out lo

when second camera is started, I see its reset line going high too:

nvidia@sdj-floyd-12:~/misc$ sudo cat /sys/kernel/debug/gpio | egrep "PP.0[45]"
 gpio-431 (PP.04               |cam_reset_gpio      ) out lo
 gpio-432 (PP.05               |cam_reset_gpio      ) out hi     <-- second camera nreset is high: OK

That leaves me with an issue with clocks and probing lines CSI1_CLK_N + CSI1_CLK_P indeed show no clock on the second camera.

I’m using 4-lane camera modules, so based on the product design guide (figure 9.3, page 59), second camera should be using mclk = extperiph2 (table 9.2, page 56). I confirmed that:

nvidia@sdj-floyd-12:~/misc$ sudo cat /sys/kernel/debug/clk/clk_summary | grep extperiph
   extperiph4   0     0    0    24000000    24000000    0   0  50000
   extperiph3   0     0    0    24000000    24000000    0   0  50000
   extperiph2   1     1    0    24000000    24000000    0   0  50000   <-- on for second camera: OK
   extperiph1   1     1    0    24000000    24000000    0   0  50000   <-- on for first camera: OK

yet, still no clock on second camera when probing with a scope.

I’m assuming something is wrong in my DTS, but the nvcsi statements are the same as for jetpack 4.6.1 and they’re working with jetpack 4.6.1:

		nvcsi@15a00000 {
			num-channels = <2>;
			#address-cells = <1>;
			#size-cells = <0>;
			csi_chan0: channel@0 {
				reg = <0>;
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					csi_chan0_port0: port@0 {
						reg = <0>;
						rbpcv2_imx492_csi_in0: endpoint@0 {
							port-index = <0>;
							bus-width = <4>;
							remote-endpoint = <&rbpcv2_imx492_out0>;
						};
					};
					csi_chan0_port1: port@1 {
						reg = <1>;
						rbpcv2_imx492_csi_out0: endpoint@1 {
							remote-endpoint = <&rbpcv2_imx492_vi_in0>;
						};
					};
				};
			};
			csi_chan1: channel@1 {
				reg = <1>;
				ports {
					#address-cells = <1>;
					#size-cells = <0>;
					csi_chan1_port0: port@0 {
						reg = <0>;
						rbpcv2_imx492_csi_in1: endpoint@2 {
							port-index = <2>;
							bus-width = <4>;
							remote-endpoint = <&rbpcv2_imx492_out1>;
						};
					};
					csi_chan1_port1: port@1 {
						reg = <1>;
						rbpcv2_imx492_csi_out1: endpoint@3 {
							remote-endpoint = <&rbpcv2_imx492_vi_in1>;
						};
					};
				};
			};
		};

Now, I came across this overlay: hardware/nvidia/platform/t23x/p3768/kernel-dts/tegra234-p3767-camera-p3768-imx477-dual-4lane.dts which is for Orin, and it has an intriguing comment:

        /* IMX477 4 lane sensor module */
        fragment@0 {
                target = <&imx477_cam0>;
                __overlay__ {
                        status = "okay";
                        /* SW bug to configure CSIB in x4 lane config   <-- what is this bug???
                         * mode0 {
                         *      num_lanes = "4";
                         *      line_length = "5832";
                         *      pix_clk_hz = "600000000";
                         * };
                         * mode1 {
                         *      num_lanes = "4";
                         *      line_length = "3076";
                         *      pix_clk_hz = "600000000";
                         * };
                         */
                };
        };

it mentions a SW bug when configuring CSIB in x4 lane which looks like what I’m trying to do.
Is that bug relevant to to xavier nx + jetpack5? or is it specific to orin SoCs?

anyway, any idea what could be wrong with that CSI2 clock not coming out?
where should I look? the DTS? the overlay?

14

that’s a bug specific to Orin NX.

let’s disassembler the dtb file into text file for examination.
for example, $ dtc -I dtb -O dts -o output.txt tegra194-p3668-0001-p3509-0000.dtb

15

here’s the DTS
output.txt (477.6 KB)

my overlay is a mix of what I’ve found from the legacy plugin-manager, dual 4-lane camera configurations and the working dual IMX492 DTS for jetpack4.x:
tegra194-p3668-all-p3509-0000-camera-imx492-dual.dts (4.0 KB)

16

you may using the same mclk, extperiph1 since it’s mux by tca9548

17

I was using extperiph1 and it didn’t work.

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

image
image979×420 58.3 KB

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:

image
image682×571 100 KB

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.

18

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.

19

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.

20

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

22

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