New camera sensor port binding media-ctl output not as expected

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

Hi,
I use Orin NX devkit with JP5.1.3 and followed the steps in the camera sensor programming - port binding. I executed the media-ctl for verification on the target.

output:

/boot/dtb$ sudo media-ctl -p -d /dev/media0
Media controller API version 5.10.192

Media device information

driver tegra-camrtc-ca
model NVIDIA Tegra Video Input Device
serial
bus info
hw revision 0x3
driver version 5.10.192

Device topology

  • entity 1: 13e40000.host1x:nvcsi@15a00000- (2 pads, 0 link)
    type V4L2 subdev subtype Unknown flags 0
    pad0: Sink
    pad1: Source

The target’s final device tree converted into source:
kernel_tegra234-p3767-0000-p3768-0000-a0.txt (411.8 KB)

The steps I’ve taken were:

  1. Add include for my sensor and remove includes for other sensors in
    cvb/tegra234-p3768-0000-a0.dtsi
    on the host:

//include “tegra234-p3768-camera-rbpcv3-imx477.dtsi”
//include “tegra234-p3768-camera-rbpcv2-imx219.dtsi”
include “tegra234-camera-des960.dtsi”

  1. Built the tegra234-p3767-0000-p3768-0000-a0.dtb on the host
  2. Copied it into the target as /boot/dtb/kernel_tegra234-p3767-0000-p3768-0000-a0.dtb

The nodes in tegra234-camera-des960.dtsi are:

/{
tegra-capture-vi {
num-channels = <1>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
des960_vi_in0: endpoint {
port-index = <0>;
bus-width = <2>;
remote-endpoint = <&des960_csi_out0>;
};
};
};
};

host1x@13e00000 {
	nvcsi@15a00000 {
		num-channels = <1>;
		#address-cells = <1>;
		#size-cells = <0>;
		channel@0 {
			reg = <0>;
			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					reg = <0>;
					des960_csi_in0: endpoint@0 {
						port-index = <0>;
						bus-width = <2>;
						remote-endpoint = <&des960_out0>;
					};
				};
				port@1 {
					reg = <1>;
					des960_csi_out0: endpoint@1 {
						remote-endpoint = <&des960_vi_in0>;
					};
				};
			};
		};
	};
};

cam_i2cmux {
	i2c@0 {
		des960_cam0: des960_a@3d {
			compatible = "nvidia,des960";
			status = "okay";
			.
            .
            };

			ports {
				#address-cells = <1>;
				#size-cells = <0>;
				port@0 {
					reg = <0>;
					des960_out0: endpoint {
						port-index = <0>;
						bus-width = <2>;
						remote-endpoint = <&des960_csi_in0>;
					};
				};
			};
		};
	};
};

};

For some reason the vi and nvcsi nodes are different on the final dtb and not include the port bindings I set on my .dtsi

3

Don’t support 24bits.

csi_pixel_bit_depth = "24";
					dynamic_pixel_bit_depth = "24";
4

Thanks @ShaneCCC ,
I removed these properties but still get the same result (media device information as I posted)

This is the final dtb in source form:
tegra234-p3767-0000-p3768-0000-a0.txt (411.7 KB)

This is my .dtsi:

The setup is ti_des_960 connected to the orin nx via 2 lanes mipi.
It acts as pattern generator

5

You can’t just remove it. You need modify to correct value like 10bit or 12bit bayer output.

6

OH. I see. Thanks.
The des generates pattern in RGB 8bit so we thought its total 24bit per pixel.

7

I tried both options: 10 and 12 bit but still facing the same problem. The media-ctl doesn’t recognise the des-csi-vi pipe.

Final dts:
tegra234-p3767-0000-p3768-0000-a0.txt (411.8 KB)

8

The mode0 looks like incomplete. Please reference to any of reference dts to add complete it.

Also, the port-index should be 1 instead of 0 due to vi/csi are 1


				ports {
					#address-cells = <0x01>;
					#size-cells = <0x00>;

					port@0 {
						reg = <0x00>;

						endpoint {
							port-index = <0x00>;
							bus-width = <0x02>;
							remote-endpoint = <0x2c3>;
							phandle = <0x286>;
						};
					};
				};
			};

			rbpcv2_imx219_a@10 {
9

We have port-index property in 3 nodes:

  1. tegra-capture-vi
  2. nvcsi@15a00000
  3. port@0

In my .dtsi all of them are 0.
Should I change all of them to 1 or only the port@0 port-index you mentioned here?

10

OH I see the problem.

In the final .dts the vi/csi port index is 1. the port0@0 is 0. But that’s the problem: for some reason the final dtb “ignores” the vi/csi nodes from my .dtsi . In my .dtsi these ports are 0 and not 1.

It takes the mode0 properites from its node for example but ignores the csi/vi nodes.

11

Still have the same problems:

  1. The media-ctl output is not as expected
  2. The final dtb ignores the vi/csi nodes from my .dtsi but takes the mode0 node.

Final dts:
tegra234-p3767-0000-p3768-0000-a0.txt (412.5 KB)

(I modified port index to 1 and completed mode0 properties from imx477 reference)

12

Dump the device tree to confirm.

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
13

Hi @ShaneCCC ,
I executed the command and this is the resulted dts:
extracted_proc.txt (409.4 KB)

I don’t know if its related to the problem but after reboot when I execute i2cdetect I see the des is occasionally listed in different i2c bus (but always the same slave addr). Can this cause our problem?

14

I am sorry! What’s your expect for the media-ctl?

15

Why you sorry?

I’m expecting an output like mentioned in the devguide (“To verify the port binding result”):
https://docs.nvidia.com/jetson/archives/r35.5.0/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html#to-verify-the-port-binding-result

image
image529×693 45.8 KB

My output is not good according to the dev guide (we dont see the sensor->csi->vi pipe)

16

OK, do you check the video node?
If not, that tell the sensor probe failed to generate the video* in the /dev that would cause the different.

ls /dev/video*

17

I don’t have a /dev/video0* device since I didn’t write the driver yet. As I understood from the devguide, I can verify the device tree ports bindings prior to writing the new sensor driver (kernel module).

I do have a /dev/media0 file

18

You can have a dummy sensor driver to verify the binding.

Thanks

20

I try using my own kernel module.
Currently its not working but you help me with that in another thread:

So I close this one

21

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