AGX Xavier with Deserializer - 2 camera inputs out of 8 not working

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
,
#1

Dear Nvidia Team

We test our own camera deserializer board with a camera IMX390 and a MAX9295 Serializer. On our board, we have 4 Deserializer MAX9296.
For testing, we connect one camera to each input port of the deserializers (only one camera connected at once). Now we have the following behavior:

  • the camera gets recognized on every Input Port A of all four deserializers, we get also an image
  • for the first two deserializers, Input Port B works also fine (CAM1 and CAM3)
  • for the last two deserializers, Input Port B does not work, there is no /dev/video device (CAM5 and CAM7)

The connections are as follows:
CAM0 (MAX9295) → SIOB (MAX9296_1) → CSI_2/CSI_3
CAM1 (MAX9295) → SIOA (MAX9296_1) → CSI_2/CSI_3

CAM2 (MAX9295) → SIOB (MAX9296_2) → CSI_0/CSI_1
CAM3 (MAX9295) → SIOA (MAX9296_2) → CSI_0/CSI_1

CAM4 (MAX9295) → SIOA (MAX9296_3) → CSI_6/CSI_7
CAM5 (MAX9295) → SIOB (MAX9296_3) → CSI_6/CSI_7

CAM6 (MAX9295) → SIOA (MAX9296_4) → CSI_4/CSI_5
CAM7 (MAX9295) → SIOB (MAX9296_4) → CSI_4/CSI_5

We think there is probably something wrong with our device tree. Can you please check if you see an error in the attached files? We are not sure about the nvcsi and vi port mapping.
tegra194-camera-imx390-a00.dtsi (34.1 KB)
tegra194-p2822-0000-camera-imx390-a00.dtsi (7.9 KB)

Thank you for your support.
Best regards

#3

The port-index in the vi scope doesn’t sync with nvcsi scope.

#4

Hi ShaneCCC

Thank you for your answer. We tested already mutliple port-index settings, but so far were not able to make all cameras work. Does the device tree is correct now?
out.dts (292.9 KB)

In the forum we also saw that for the vi, the last port-index is 5 and not 6. We have to change this everywhere or only for the vi node? Can you elaborate a bit on the port mapping?
Thank you.

#5

The port-index for CAM4/5 should be 6 in nvcsi@ scope and 5 in vi@ scope.

			channel@4 {
				reg = <0x4>;

				ports {
					#address-cells = <0x1>;
					#size-cells = <0x0>;

					port@0 {
						reg = <0x0>;

						endpoint@8 {
							port-index = <0x5>;
							bus-width = <0x2>;
							remote-endpoint = <0x82>;
							linux,phandle = <0x3f>;
							phandle = <0x3f>;
						};
					};

					port@1 {
						reg = <0x1>;

						endpoint@9 {
							remote-endpoint = <0x83>;
							linux,phandle = <0x75>;
							phandle = <0x75>;
						};
					};
				};
			};

			channel@5 {
				reg = <0x5>;

				ports {
					#address-cells = <0x1>;
					#size-cells = <0x0>;

					port@0 {
						reg = <0x0>;

						endpoint@10 {
							port-index = <0x5>;
							bus-width = <0x2>;
							remote-endpoint = <0x84>;
							linux,phandle = <0x41>;
							phandle = <0x41>;
						};
					};

					port@1 {
						reg = <0x1>;

						endpoint@11 {
							remote-endpoint = <0x85>;
							linux,phandle = <0x76>;
							phandle = <0x76>;
						};
					};
				};
			};
#6

Also the num-ports in nvcsi@ scope is 8 instead of 6

#7

Thank you ShaneCCC.
We changed our device tree accordingly:
out.dts (292.9 KB)

Now we have the weird behavior that the CAM5 is ones recognized and after a reboot/poweroff, the sensor disappears.
In the dmesg we see the following message:

max9296 32-0048: max9296_sdev_register: serdes csi link is in use
max9296 33-0048: max9296_sdev_register: serdes csi link is in use

Any idea what goes wrong?

#8

Too less information to tell what going on.

#9

Hi ShaneCCC

Apparently this happens also with CAM2. Attached you can find the dmesg for when the camera is detected and for when it is not:
cam_ok.txt (77.4 KB)
cam_nok.txt (76.9 KB)
The difference is that in the unsuccessfull case, there is the error max9296 31-0048:

max9296_sdev_register: serdes csi link is in use

This message comes from the max9296 driver:

if (g_ctx->serdes_csi_link ==
priv->sources[i].g_ctx->serdes_csi_link) {
dev_err(dev,
“%s: serdes csi link is in use\n”, func);
err = -EINVAL;
goto error;
}

What additional information do you need?

#10

Maybe review the gmsl-link{} in device tree.

#11

Hi ShaneCCC

We have tried multiple different settings for the gmsl-link{} without any success.
Do we understand the settings correctly?

src-csi-port=“b”; → MAX9295 is always Port B
dst-csi-port=“a”; → is this the Jetson CSI Port (A, B, C, D, E, F, G) or the Input Port of the deserializer, meaning A or B?
serdes-csi-link=“a”; → connection of deserializer? A or B?

The error message remains always the same.

#12

Looks like it’s Max9296’s configure doesn’t matter with Jetson CSI from the source code point of view.

#13

Hi ShaneCCC
As additional information - when we switch serdes-csi-link=“a” and serdes-csi-link=“b” in our device tree, then the Camera on Port B is always working, but the one on Port A is not anymore. As this switch leads just to a switch of the I2C Proxy address of the sensor and the order of the initialization, could there something go wrong when the addresses are translated?
Can you explain the “src-csi-port”, “dst-csi-por” and “serdes-csi-link” a bit more?
Thank you.

#14

Hi Shane
We have now the following device trees:
tegra194-brla3-13x-0000-camera-imx390-a00.dtsi (7.7 KB)
tegra194-camera-imx390-brla3-13x.dtsi (33.9 KB)

And we get the following dmesg output:
dmesg.txt (78.7 KB)

Were we see this message:

[ 1.796317] pca954x 2-0070: vcc-pullup regulator not found

[ 1.801069] max9295 31-0062: prim-ser already exists
[ 1.801266] max9295: probe of 31-0062 failed with error -17

Do you have an idea what our problem is?
We use the Multiplexer TCA9546APWR from Texas Instruments, what do we need to use for the “compatible=” option in the device tree?
Thank you.