Cameras not detected on orin devkit + jetpack6 (R36.x)

[alain.gautherot]

Hello,

I have a working setup with orin devkit + jetpack 5.1.2 + 3 cameras.
I’m trying to get jetpack6 (r36.x) to work and followed the online documentation:

• created overlay
• added overlay to configuration (.conf) file

OVERLAY_DTB_FILE="${OVERLAY_DTB_FILE},tegra234-p3737-camera-raptorp2-overlay.dtbo”;

• selected overlay using jetson-io

DEFAULT JetsonIO    ## new JetsonIO entry created

MENU TITLE L4T boot options

LABEL primary
      MENU LABEL primary kernel
      LINUX /boot/Image
      FDT /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb
      INITRD /boot/initrd
      APPEND ${cbootargs} root=PARTUUID=c6e6854a-e5c7-404a-a9a8-e1a854ece885 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0 

LABEL JetsonIO
	MENU LABEL Custom Header Config: <CSI Jetson Camera Raptor-P2>
	LINUX /boot/Image
	FDT /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb
	INITRD /boot/initrd
	APPEND ${cbootargs} root=PARTUUID=c6e6854a-e5c7-404a-a9a8-e1a854ece885 rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 console=ttyAMA0,115200 firmware_class.path=/etc/firmware fbcon=map:0 net.ifnames=0 nospectre_bhb video=efifb:off console=tty0
	OVERLAYS /boot/tegra234-p3737-camera-raptorp2-overlay.dtbo

• port drivers from R35 to R36 per documentation

as far as I can tell, probe() and remove() have slightly changed:

#if KERNEL_VERSION(6, 3, 0) <= LINUX_VERSION_CODE
static int imxXXX_probe(struct i2c_client *client)
#else
static int imxXXX_probe(struct i2c_client *client,
	const struct i2c_device_id *id)
#endif
...
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 1, 0)
static void imxXXX_remove(struct i2c_client *client)
#else
static int imxXXX_remove(struct i2c_client *client)
#endif

• reboot

• insert drivers using “sudo insmod”

I don’t see any error reported, but no sign of probe() being called and no /dev/video* entries are created.

I decompiled/dumped:

• /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb: dts.txt (313.4 KB)
• /boot/tegra234-p3737-camera-raptorp2-overlay.dtbo: fdtdump.txt (478.5 KB)
• /proc/device-tree: fs.txt (435.4 KB)

but can’t find anything suspicious.
How do I go about debugging this?
is there any log I can look at to find why drivers are not probe()'ing?

Thanks,
Alain

[ShaneCCC]

Which one is your sensor? None of them are enable? All of the status are disalbed.

	tegra-camera-platform {
		tpg_max_iso = <0x3bc400>;
		vi_bw_margin_pct = <0x19>;
		max_lane_speed = <0xe4e1c0>;
		vi_peak_byte_per_pixel = <0x02>;
		num_csi_lanes = <0x10>;
		max_pixel_rate = <0xb71b0>;
		compatible = "nvidia, tegra-camera-platform";
		min_bits_per_pixel = <0x0a>;
		isp_bw_margin_pct = <0x19>;
		isp_peak_byte_per_pixel = <0x05>;
		phandle = <0x392>;

		modules {

			module1 {
				badge = "imx492_topright";
				position = "topright";
				status = "disabled";
				orientation = "0";
				phandle = <0x396>;

				drivernode0 {
					devname = "imx492 31-001a";
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9546@70/i2c@1/imx492_c@1a";
					phandle = <0x397>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/lens_imx492@RBPCV2/";
					phandle = <0x398>;
				};
			};

			module4 {
				badge = "e3333_bottomright_P5V27C";
				position = "bottomright";
				status = "disabled";
				orientation = "1";
				phandle = <0x39f>;

				drivernode0 {
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9548@77/i2c@4/ov5693_e@36";
					phandle = <0x3a0>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/e3333_lens_ov5693@P5V27C/";
					phandle = <0x3a1>;
				};
			};

			module2 {
				badge = "imx415_bottomleft";
				position = "bottomleft";
				status = "disabled";
				orientation = "0";
				phandle = <0x399>;

				drivernode0 {
					devname = "imx415 32-001a";
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9546@70/i2c@2/imx415_e@1a";
					phandle = <0x39a>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/lens_imx492@RBPCV2/";
					phandle = <0x39b>;
				};
			};

			module0 {
				badge = "imx492_topleft";
				position = "topleft";
				status = "disabled";
				orientation = "0";
				phandle = <0x393>;

				drivernode0 {
					devname = "imx492 30-001a";
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9546@70/i2c@0/imx492_a@1a";
					phandle = <0x394>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/lens_imx492@RBPCV2/";
					phandle = <0x395>;
				};
			};

			module5 {
				badge = "e3333_topright_P5V27C";
				position = "topright";
				status = "disabled";
				orientation = "1";
				phandle = <0x3a2>;

				drivernode0 {
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9548@77/i2c@5/ov5693_g@36";
					phandle = <0x3a3>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/e3333_lens_ov5693@P5V27C/";
					phandle = <0x3a4>;
				};
			};

			module3 {
				badge = "imx415_bottomright";
				position = "bottomright";
				status = "disabled";
				orientation = "0";
				phandle = <0x39c>;

				drivernode0 {
					devname = "imx415 33-001a";
					pcl_id = "v4l2_sensor";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/i2c@3180000/tca9546@70/i2c@3/imx415_g@1a";
					phandle = <0x39d>;
				};

				drivernode1 {
					pcl_id = "v4l2_lens";
					status = "disabled";
					sysfs-device-tree = "/sys/firmware/devicetree/base/bus@0/lens_imx492@RBPCV2/";
					phandle = <0x39e>;
				};
			};
		};
	};

[alain.gautherot]

right and I’m wondering where this comes from.
I have:

• 2 x 4-lane IMX492 as /dev/video0 and 1
• 1 x 4-lane IMX415 as /dev/video2

so I’m wondering if overlay generation failed for some reason.
Should /boot/dtb/kernel_tegra234-p3737-0000+p3701-0005-nv.dtb have been updated after overlay selection with jetson-io?
is there any log to look at somewhere?

[ShaneCCC]

Please check below doc.

https://docs.nvidia.com/jetson/archives/r36.2/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html#device-registration

[alain.gautherot]

that’s the link I was looking at.
Looks like the [use Jetson-IO] (Sensor Software Driver Programming — NVIDIA Jetson Linux Developer Guide 1 documentation) option didn’t work for me.

It seemed like this is what worked for me: Sensor Software Driver Programming — NVIDIA Jetson Linux Developer Guide 1 documentation

does that make any sense?

I also have 2 (other) issues:

• after a “sudo apt update” and “sudo apt upgrade”, drivers won’t load and system log will indicate that version of symbols don’t match anymore:
  is that expected?
  is it possible to fallback to compiling the driver into the kernel like in jetpack5?

[   11.409797] li_imx492: disagrees about version of symbol tegracam_v4l2subdev_unregister
[   11.409804] li_imx492: Unknown symbol tegracam_v4l2subdev_unregister (err -22)
[   11.409961] li_imx492: disagrees about version of symbol tegracam_v4l2subdev_register
[   11.409962] li_imx492: Unknown symbol tegracam_v4l2subdev_register (err -22)
[   11.409970] li_imx492: disagrees about version of symbol tegracam_device_unregister
[   11.409972] li_imx492: Unknown symbol tegracam_device_unregister (err -22)
[   11.410002] li_imx492: disagrees about version of symbol tegracam_get_privdata
[   11.410004] li_imx492: Unknown symbol tegracam_get_privdata (err -22)
[   11.410023] li_imx492: disagrees about version of symbol camera_common_mclk_enable
[   11.410024] li_imx492: Unknown symbol camera_common_mclk_enable (err -22)
[   11.410035] li_imx492: disagrees about version of symbol camera_common_mclk_disable
[   11.410036] li_imx492: Unknown symbol camera_common_mclk_disable (err -22)
[   11.410041] li_imx492: disagrees about version of symbol tegracam_set_privdata
[   11.410043] li_imx492: Unknown symbol tegracam_set_privdata (err -22)
[   11.410049] li_imx492: disagrees about version of symbol tegracam_device_register
[   11.410050] li_imx492: Unknown symbol tegracam_device_register (err -22)

• the third camera IMX415 is detected as /dev/video2 but no frame data coming back
  Dumping the parameters (v4l2-ctl -d 2 --all), I see the parameter limits are incorrect (frame_rate, gain, etc), they look like taken from one of the /dev/video0 or /dev/video1.
  The device tree (dtc -I fs -O dts /proc/device-tree) looks correct and has the proper limits.
  Could it be an issue with jetpack6?

[ShaneCCC]

Check the trace log for capture failed by v4l2-ctl

https://elinux.org/Jetson/l4t/Camera_BringUp#Steps_to_enable_more_debug_messages

[alain.gautherot]

so it turns out that cameras are not detected in the order I was expecting.
there used to be a field to set which node the camera would be assigned to:
devnode = “video0”;

does that still exist with Jetpack6?

I used to v4l2-ctl and see that frames are produced by the sensor

~$ v4l2-ctl --verbose --set-fmt-video=width=3840,height=2160,pixelformat=RG10 --set-ctrl sensor_mode=0,bypass_mode=0 --stream-mmap -d 0
VIDIOC_QUERYCAP: ok
VIDIOC_S_EXT_CTRLS: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture:
	Width/Height      : 3840/2160
	Pixel Format      : 'RG10' (10-bit Bayer RGRG/GBGB)
	Field             : None
	Bytes per Line    : 7680
	Size Image        : 16588800
	Colorspace        : sRGB
	Transfer Function : Default (maps to sRGB)
	YCbCr/HSV Encoding: Default (maps to ITU-R 601)
	Quantization      : Default (maps to Full 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: 16588800 ts: 1917.217291 (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 16588800 ts: 1917.228381 delta: 11.090 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 16588800 ts: 1917.239472 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 16588800 ts: 1917.250563 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      4 bytesused: 16588800 ts: 1917.461285 delta: 210.722 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      5 bytesused: 16588800 ts: 1917.472376 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      6 bytesused: 16588800 ts: 1917.483466 delta: 11.090 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      7 bytesused: 16588800 ts: 1917.494557 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      8 bytesused: 16588800 ts: 1917.505648 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      9 bytesused: 16588800 ts: 1917.516738 delta: 11.090 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:     10 bytesused: 16588800 ts: 1917.527829 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:     11 bytesused: 16588800 ts: 1917.538920 delta: 11.091 ms (error, ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:     12 bytesused: 16588800 ts: 1917.550010 delta: 11.090 ms (error, ts-monotonic, ts-src-eof)

camrtc log seems fine:

# tracer: nop
#
# entries-in-buffer/entries-written: 1447/1447   #P:8
#
#                                _-------=> irqs-off
#                               / _------=> need-resched
#                              | / _-----=> need-resched-lazy
#                              || / _----=> hardirq/softirq
#                              ||| / _---=> preempt-depth
#                              |||| / _--=> preempt-lazy-depth
#                              ||||| / _-=> migrate-disable
#                              |||||| /     delay
#           TASK-PID     CPU#  |||||||  TIMESTAMP  FUNCTION
#              | |         |   |||||||      |         |
        v4l2-ctl-5717    [001] .......  1255.549481: tegra_channel_open: vi-output, imx415 11-001a
        v4l2-ctl-5717    [001] .......  1255.561783: tegra_channel_set_power: imx415 11-001a : 0x1
        v4l2-ctl-5717    [001] .......  1255.561793: camera_common_s_power: status : 0x1
        v4l2-ctl-5717    [001] .......  1255.585552: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-5717    [001] .......  1255.585555: csi_s_power: enable : 0x1
        v4l2-ctl-5717    [001] .......  1255.586052: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
 vi-output, imx4-5718    [003] .......  1255.598781: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.598789: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.598790: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.598792: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
        v4l2-ctl-5717    [002] .......  1255.598810: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-5717    [002] .......  1255.598818: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-5717    [002] .......  1255.598820: csi_s_stream: enable : 0x1
        v4l2-ctl-5717    [002] .......  1255.599133: tegra_channel_set_stream: imx415 11-001a : 0x1
 vi-output, imx4-5719    [007] .......  1255.660510: tegra_channel_capture_frame: sof:1275.312988096
 vi-output, imx4-5719    [007] .......  1255.660513: tegra_channel_capture_frame: eof:1275.312998816
 vi-output, imx4-5719    [007] .......  1255.671388: tegra_channel_capture_frame: sof:1275.324078720
 vi-output, imx4-5719    [007] .......  1255.671390: tegra_channel_capture_frame: eof:1275.324089440
 vi-output, imx4-5719    [007] .......  1255.682464: tegra_channel_capture_frame: sof:1275.335169376
 vi-output, imx4-5719    [007] .......  1255.682465: tegra_channel_capture_frame: eof:1275.335180096
 vi-output, imx4-5719    [007] .......  1255.693544: tegra_channel_capture_frame: sof:1275.346260000
 vi-output, imx4-5719    [007] .......  1255.693546: tegra_channel_capture_frame: eof:1275.346270720
 vi-output, imx4-5718    [003] .......  1255.899902: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.899918: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.899920: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5718    [003] .......  1255.899922: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5719    [007] .......  1255.904770: tegra_channel_capture_frame: sof:1275.556982112
 vi-output, imx4-5719    [007] .......  1255.904772: tegra_channel_capture_frame: eof:1275.556992864
 vi-output, imx4-5718    [003] .......  1255.905162: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
 vi-output, imx4-5719    [007] .......  1255.915389: tegra_channel_capture_frame: sof:1275.568072736
 vi-output, imx4-5719    [007] .......  1255.915391: tegra_channel_capture_frame: eof:1275.568083520
 vi-output, imx4-5718    [003] .......  1255.915595: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:7248 pid:5718 tid:5718
...

But system log (dmesg) indicates an error:

[ 1891.307142] imx415 11-001a: imx415_power_off: power off
[ 1897.463759] imx415 11-001a: imx415_power_on: power on
[ 1897.564570] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 256
[ 1897.575669] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 2, flags: 0, err_data 256
[ 1897.586777] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 3, flags: 0, err_data 256
[ 1897.598532] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 4, flags: 0, err_data 256
[ 1897.809057] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 23, flags: 0, err_data 256
[ 1897.819502] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 24, flags: 0, err_data 256
[ 1897.830575] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 25, flags: 0, err_data 256
...
[ 1900.248467] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 243, flags: 0, err_data 256
[ 1900.259429] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 244, flags: 0, err_data 256
[ 1900.270518] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 245, flags: 0, err_data 256
[ 1900.281612] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 246, flags: 0, err_data 256
[ 1900.292699] tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 247, flags: 0, err_data 256
[ 1900.347148] imx415 11-001a: imx415_power_off: power off

what does that error mean?
Note that this driver works fine on Jetpack 5.1.2. Only change for Jetpack6 was the change in API for
probe() and remove().

[ShaneCCC]

The video node was assign by system from the free.
For the error you can increase the timeout in the vi5_fops.c to try.

Thanks

[alain.gautherot]

is there no way with jetpack6 to reserve /dev/videoXXX for a given camera like “devnode” in Jetpack5?

I suppose you mean the CAPTURE_TIMEOUT_MS define.
It was 2500ms originally and I had already bumped up to 5000ms, so definitely not an issue.

the IMX415 is configured for 90fps in 10-bit, 60fps for 12-bit.
In both cases, I see that same error “tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame XXX, flags: 0, err_data 256”

Looking further in system log, I do see an error reported imx415_power_get(), code=-22 (EINVALID?)

$ sudo dmesg | grep imx415
[sudo] password for nvidia: 
[   10.211712] imx415 11-001a: probing v4l2 sensor at addr 0x1a, adapter is 11: alain/imx415/1
[   10.211783] imx415 11-001a: imx415_power_get failed to set parent clock: -22
[   10.211804] imx415 11-001a: supply vana not found, using dummy regulator
[   10.211877] imx415 11-001a: supply vif not found, using dummy regulator
[   10.211904] imx415 11-001a: supply vdig not found, using dummy regulator
[   10.211961] imx415 11-001a: tegracam sensor driver:imx415_v2.0.6
[   10.213384] imx415 11-001a: imx415_power_on: power on
[   10.237266] imx415 11-001a: imx415_power_off: power off
[   10.237381] tegra-camrtc-capture-vi tegra-capture-vi: subdev imx415 11-001a bound
[   10.263097] imx415 11-001a: detected imx415 sensor

Offending code is the following:

	pw->mclk = devm_clk_get(dev, mclk_name);
	if (IS_ERR(pw->mclk)) {
		dev_err(dev, "unable to get clock %s\n", mclk_name);
		return PTR_ERR(pw->mclk);
	}

	parent = devm_clk_get(dev, "pllp_grtba");
	if (IS_ERR(parent)) {
		dev_err(dev, "devm_clk_get failed for pllp_grtba");
	} else {
		if (clk_set_parent(pw->mclk, parent) < 0) {
			dev_dbg(dev, "%s failed to set parent clock\n", __func__);
		}
	}

Both pw->mclk and parent are non-null, so I’m wondering why clk_set_parent() would return an error.

[ShaneCCC]

1. You need to modify the tegracam to assign specific number in v4l2 video register API.

2. I don’t think the clock could be the root cause. The error message could be your device tree didn’t define the regulator but IMX415 driver acquire it in the power_xx funtion.

3. Did you boost the clocks to try.

sudo jetson_clocks
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

[alain.gautherot]

about 1)
I don’t understand how to “modify the tegracam to assign specific number in v4l2 video register API”.
do you mean update the kernel?

about 2)
you’re probably right, it may be a red herring.
I looked at the other driver that is working, and set_parent_clk() also returns error -22.
I checked the device tree and I have the following regulators selected for all cameras:

avdd-reg = "vana";
dvdd-reg = "vdig";
iovdd-reg = "vif";

I made sure that regulators were enabled in power_get() and issue is still there.

about 3)
I tried and it didn’t help.

[ShaneCCC]

1. Yes you need modify the kernel for it.

[alain.gautherot]

looking at the error message:
“tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 256”

does it mean that error is encoded as bit 8 as found in file Linux_for_Tegra/source/nvidia-oot/include/soc/tegra/camrtc-capture.h:

/** A line has more pixels than expected width, pixels dropped */
define CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE MK_BIT32(8)

If so, does that mean that “line_length” value is incorrect in the DTS?

[ShaneCCC]

It doesn’t matter with the line_length but the output size.

[alain.gautherot]

ok, but am I following the right lead, is the error I’m seeing related to CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE?

I’m asking because I don’t see anywhere this flag is set in the kernel code:

$ grep -R CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE Linux_for_Tegra/source/
/Linux_for_Tegra/source/nvidia-oot/include/soc/tegra/camrtc-capture.h:#define CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE		MK_BIT32(8)
/Linux_for_Tegra/source/out/nvidia-linux-header/include/soc/tegra/camrtc-capture.h:#define CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE		MK_BIT32(8)

[ShaneCCC]

It’s unpublic sources.

Thanks

[alain.gautherot]

This is not getting anywhere. Let me ask again!

Does
“err_data 256”
in “tegra-camrtc-capture-vi tegra-capture-vi: corr_err: discarding frame 1, flags: 0, err_data 256”
correspond to CAPTURE_CHANNEL_ERROR_PIXEL_LONG_LINE?

[ShaneCCC]

Suppose yes, you can get the trace log to confirm.

https://elinux.org/Jetson/l4t/Camera_BringUp#Steps_to_enable_more_debug_messages

[alain.gautherot]

it looks like the path /sys/kernel/debug/camrtc/log-level doesn’t exist on jetpack6.
it does on jetpack5.

anyway, I had already captured that trace (see earlier in this discussion). I tried again just for the sake of it and no error is showing as far as I can see:

root@sdj-orindk-02:/home/nvidia# cat /sys/kernel/debug/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 1186/1186   #P:8
#
#                                _-------=> irqs-off
#                               / _------=> need-resched
#                              | / _-----=> need-resched-lazy
#                              || / _----=> hardirq/softirq
#                              ||| / _---=> preempt-depth
#                              |||| / _--=> preempt-lazy-depth
#                              ||||| / _-=> migrate-disable
#                              |||||| /     delay
#           TASK-PID     CPU#  |||||||  TIMESTAMP  FUNCTION
#              | |         |   |||||||      |         |
        v4l2-ctl-3877    [002] .......   456.380973: tegra_channel_open: vi-output, imx415 11-001a
        v4l2-ctl-3877    [002] .......   456.393646: tegra_channel_set_power: imx415 11-001a : 0x1
        v4l2-ctl-3877    [002] .......   456.393655: camera_common_s_power: status : 0x1
        v4l2-ctl-3877    [002] .......   456.417571: tegra_channel_set_power: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3877    [002] .......   456.417574: csi_s_power: enable : 0x1
        v4l2-ctl-3877    [002] .......   456.418557: tegra_channel_capture_setup: vnc_id 0 W 3840 H 2160 fmt c4
 vi-output, imx4-3878    [002] .......   456.428568: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.428573: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.428573: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.428574: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
        v4l2-ctl-3877    [003] .......   456.429062: tegra_channel_set_stream: enable : 0x1
        v4l2-ctl-3877    [003] .......   456.429070: tegra_channel_set_stream: 13e00000.host1x:nvcsi@15a00000- : 0x1
        v4l2-ctl-3877    [003] .......   456.429073: csi_s_stream: enable : 0x1
        v4l2-ctl-3877    [003] .......   456.429810: tegra_channel_set_stream: imx415 11-001a : 0x1
 vi-output, imx4-3879    [000] .......   456.491052: tegra_channel_capture_frame: sof:476.181907008
 vi-output, imx4-3879    [000] .......   456.491054: tegra_channel_capture_frame: eof:476.181917760
 vi-output, imx4-3879    [001] .......   456.501984: tegra_channel_capture_frame: sof:476.192997696
 vi-output, imx4-3879    [001] .......   456.501987: tegra_channel_capture_frame: eof:476.193008448
 vi-output, imx4-3879    [003] .......   456.513230: tegra_channel_capture_frame: sof:476.204088384
 vi-output, imx4-3879    [003] .......   456.513232: tegra_channel_capture_frame: eof:476.204099136
 vi-output, imx4-3879    [003] .......   456.524144: tegra_channel_capture_frame: sof:476.215179072
 vi-output, imx4-3879    [003] .......   456.524145: tegra_channel_capture_frame: eof:476.215189792
 vi-output, imx4-3878    [002] .......   456.730593: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.730608: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.730610: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3878    [002] .......   456.730612: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3879    [003] .......   456.735054: tegra_channel_capture_frame: sof:476.425902048
 vi-output, imx4-3879    [003] .......   456.735057: tegra_channel_capture_frame: eof:476.425912800
 vi-output, imx4-3878    [003] .......   456.735111: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3879    [003] .......   456.746153: tegra_channel_capture_frame: sof:476.436992736
 vi-output, imx4-3879    [003] .......   456.746156: tegra_channel_capture_frame: eof:476.437003456
 vi-output, imx4-3878    [003] .......   456.746202: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
 vi-output, imx4-3879    [003] .......   456.757055: tegra_channel_capture_frame: sof:476.448083424
 vi-output, imx4-3879    [003] .......   456.757056: tegra_channel_capture_frame: eof:476.448094144
 vi-output, imx4-3878    [003] .......   456.757097: vi_task_submit: class_id:48 ch:0 syncpt_id:36 syncpt_thresh:3576 pid:3878 tid:3878
...

[ShaneCCC]

OK, looks like the trace log on JP6.x different with JP5.x
I am going to check it.