Cam I2C Mux on Jetson Xavier NX in Device Tree

Hi Everyone,

Disclaimer:
I have searched this topic quite a lot and have not yet found a solution however a number of people asking so I might also be missing something in other posts.

I am currently adapting a camera driver for a custom carrier board which will have 4 cameras.

In order to do that we want to use the I2C MUX as it is suggested in the camera dev guide.
The hardware seems alright and all contacts seem to be made accordingly.

Installed is the standard Image as found on the Nvidia website (JP v32.5) no kernel or device tree customizations (yet, we can do that if needed)

The driver is similar to the driver found in “tegra194-camer-jakku-rbpcv2-imx219.dtsi”

Given was:
mux-gpios = <&tegra_aon_gpio CAM_I2C_MUX GPIO_ACTIVE_HIGH>;

I changed this too:
mux-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 1) GPIO_ACTIVE_HIGH &tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 6) GPIO_ACTIVE_HIGH>;
(other config changes like port changes, adding camera configs, etc have also been done but I cant provide you the full file)

This is due to the fact that the GPIOs connected to the MUX Chips (a TS3A507) are pin no 212 and 216 respectively.

Unfortunately this dosent seem to work.
Only one camera can be adressed and it is the camera that would be addressed if the GPIOs wouldn’t be set all together.
Checking with oscilloscope I can see them being set at some times however they dont seem to check every cam.

Pattern is LOW LOW → HIGH HIGH → LOW LOW
I’d atleast expect it to detect two cameras at this point, but it just dosent, also checking the I2C on the board with an oscilloscope I can see that it only attempts to speak to one camera, all other I2Cs are never used.

I have the following ideas what the problem could be:

  1. Kernel Device Tree needs to be customized, if so, I’d need some instructions
  2. I am not configuring the two GPIOs correctly in the dts (like delimiter missing etc.), if so, I’d need some instructions and am also very confused why the driver compiles to begin with
  3. One or more of the GPIOs is already in use by something else, if so, I assume 1. applies
  4. Something else, if so, please explain what you think it could be.

Thank you very much for your help!
I am happy to provide snippets of the .dts and other information if needed!

hello clex.riegler,

there’s booting process to detect the register devices. had you disable plugin-manager support by Using the Main Platform Device Tree File.
please also check this device tree, this is a camera reference board with six identical camera sensor, ov5693.
i.e. $L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-p2822-0000-camera-e3333-a00.dtsi

Hi Jerry

thanks for you answer.
Regarding the file you referred me too.
I saw a similar solution in this post: Using 6 Raspberry Pi cameras with Jetson Xavier NX

As of my understanding the muxing of the I2C is “written by hand” both in the post and in the tegra194-p2822-0000-camera-e3333-a00.dtsi file and the post I linked.
Yet the tegra194-camer-jakku-rbpcv2-imx219.dtsi file seem to use a block called cam_i2cmux which I assumed to be a pre implemented muxer. Is my understanding of this wrong? Why can I not use the pre implemented muxer to solve this problem?

hello clex.riegler,

please refer to below,
it’s by default “mux” 0x10 into i2c@0 and i2c@1.

        cam_i2cmux{
                compatible = "i2c-mux-gpio";
                i2c-parent = <&cam_i2c>;
                mux-gpios = <&tegra_aon_gpio CAM_I2C_MUX GPIO_ACTIVE_HIGH>;
                i2c@0 {
                        rbpcv2_imx219_a@10 {
                                reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };
                i2c@1 {
                        rbpcv2_imx219_c@10 {
                                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };

please reference to this driver and have a try to extend the cameras for your use-case.
thanks

Hi Jerry,

thats what I am doing, my driver basically looks like this:

  cam_i2cmux{
                compatible = "i2c-mux-gpio";
                i2c-parent = <&cam_i2c>;
                mux-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 1) GPIO_ACTIVE_HIGH &tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 6) GPIO_ACTIVE_HIGH>;
                i2c@0 {
                        rbpcv2_imx219_a@10 {
                                reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };
                i2c@1 {
                        rbpcv2_imx219_b@10 {
                                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };
                i2c@2 {
                        rbpcv2_imx219_c@10 {
                                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };
                i2c@3 {
                        rbpcv2_imx219_d@10 {
                                reset-gpios = <&tegra_main_gpio CAM1_PWDN GPIO_ACTIVE_HIGH>;
                        };
                };

unfortunately only the camera that would work if no mux pins are set works all other do not answer because the mux pins are not set, they are connected correctly up until the jetson board. they can also be set however the driver does not use the and I am absolutely confused why this does not work

Specific question @JerryChang: Is my way of providing more than one GPIO pin for muxing correct?
Specifically this line:
<mux-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 1) GPIO_ACTIVE_HIGH &tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 6) GPIO_ACTIVE_HIGH>;

there’s booting process to detect the register devices. had you disable plugin-manager support by Using the Main Platform Device Tree File .
please also check this device tree, this is a camera reference board with six identical camera sensor, ov5693.
i.e. $L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x/galen/kernel-dts/common/tegra194-p2822-0000-camera-e3333-a00.dtsi

I have checked this file and have one question. Obviously only one I2C is used. How does the MUX Chip get its info on where to MUX the I2C too? AFAI can tell there are no GPIOs set in this file.
If we can clear that, i think, we can get further.

hello clex.riegler,

please access download center to download Jetson Xavier NX Product Design Guide. you should refer to [Figure 9-3. Available Camera Control Pins] for the control pins for using 4 cameras.
it’s GPIO-based i2c bus multiplexer, which uses GPIOs to route the i2c signals.
there’s kernel documentation, it also shows the paragraph to demonstrate the bindings.
for example,
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/kernel/kernel-4.9/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt

                                  +-----+  +-----+
                                  | dev |  | dev |
    +------------+                +-----+  +-----+
    | SoC        |                   |        |
    |            |          /--------+--------+
    |   +------+ |  +------+    child bus A, on GPIO value set to 0
    |   | I2C  |-|--| Mux  |
    |   +------+ |  +--+---+    child bus B, on GPIO value set to 1
    |            |     |    \----------+--------+--------+
    |   +------+ |     |               |        |        |
    |   | GPIO |-|-----+            +-----+  +-----+  +-----+
    |   +------+ |                  | dev |  | dev |  | dev |
    +------------+                  +-----+  +-----+  +-----+

hello clex.riegler,

Xavier NX’s reference driver is using TEGRA194_AON_GPIO(CC, 3) as mux-gpio. could you please have a try by using the same?
product design guide point out the pins of each cameras, please refer check for enabling multi-cam use-case.

The board we are working with has the MUX GPIOS connected to Q 1 and Q 6 respectively.
If I use CC 3 obviously nothing happens, only the “Low Low” connection of the mux is used and only the camera at the low low connection is detected.

Looping back to my question, does anything speak against the usage of Q1 and Q6?

please also access NVIDIA Jetson Nano and Jetson Xavier NX Camera Design Guide for the guidelines of camera connector.

Hi Jerry,

we have read that guide and designed our board according to this guide.
The MUX Chips was a different one since the sillicon shortage lead us to use another one (product name in the original post) The MUX Chips is also a GPIO Muxer while (if I read that data sheet correctly) the suggested Mux Chip is a chip that switches according too I2C Commands or GPIOs, correct? Could this cause a problem since our chip only switches with GPIOs?

Specifically it states in Chapter 6.1 that GPIOs can be used to switch the MUX. So we decided to go with GPIO10 and GPIO11 because they where available.

I do assume that this is a correct choice and nothing speaks against using GPIO10 and GPIO11 assuming the wiring is correct.

Specific question (and please do not provide some link again unless it answers the question):
Is it correct to write:

mux-gpios = <&tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 1) GPIO_ACTIVE_HIGH &tegra_main_gpio TEGRA194_MAIN_GPIO(Q, 6) GPIO_ACTIVE_HIGH>;

(from the longer code block earlier)
If a 4 channel MUX is used to switch between for cameras assuming all other configurations are correct and the two pins to switch between cameras are GPIO11 and GPIO10. If it is not correct, can you tell me what is the correct way of diving this?

@JerryChang

I think I finally figured out what you where trying to tell me.
The Muxer we have chosen muxes only with GPIOs however the suggest muxer uses addresses.

This could be a problem, this is also why you suggest to look at the i2c-mux-gpio.txt

Is this correct?

@JerryChang

another question, in this post you suggested that, if the i2c is muxed the way we are also doing it, cam_i2c should not be used. Is that correct? If so, why is that not in the dev guide? IMHO opinion that is essential information.

hello clex.riegler,

cam_i2cmux
the GPIO-based i2c bus multiplexer to route the i2c signals. it depends-on GPIO values 0/1 for child bus A/B.

pca9548
if you check another 6-cam example, you should also searching for tca9548_77, it’s an i2c bus multiplexer/switch (at address 0x77) will have several child bus that are numbered uniquely in a device dependent manner.

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