Jetpack 6.0 video index problem

Autonomous Machines Jetson & Embedded Systems Jetson Orin Nano
1

We are using Jetpack 6.0 L4T 36.3 on Jetson Orin Nano Devkit. And using the customer designed carrier board. Witch has a max96712 connect on i2c@3160000 and another max96712 connect on i2c@c250000. So totally we will have 8 camera input.
The problem we have is that, the camera video index num such as video0/video1 will related to the description order of camera nodes in the device tree.
As far as we know, the order of video index num is related to the loading order of drivers.
So, when my camera nodes in the device tree is write as below:

i2c@3160000 {
	...
	camera_d@1d {
	};
	camera_c@1c {
	};
	camera_b@1b {
	};
	camera_a@1a {
	};
	...
};
i2c@c250000 {
	...
	camera_h@1h {
	};
	camera_g@1g {
	};
	camera_f@1f {
	};
	camera_e@1e {
	};
	...
};

After we insmod our camera ko module after the device boot up, the relationship between video index and camera notes in device tree is as follows:

camera_a@1a --- video0
camera_b@1b --- video1
camera_c@1c --- video2
camera_d@1d --- video3

camera_e@1e --- video4
camera_f@1f --- video5
camera_g@1g --- video6
camera_h@1h --- video7

So you will see the camera notes related to the video0~video3 or video4~video7 witch write in the device tree need to be written in reverse order.
And i2c@c250000 write after i2c@3160000 because when insmod camera ko module, camera on i2c@3160000 is the first to be probed and camera on i2c@c250000 is second.

But the other weird thing is that, after we add conf file in /etc/modules-load.d so that our camera ko module will be loaded auto by system when device boot, the the relationship between video index and camera notes in device tree turns out to be something else as follows:

camera_a@1a --- video4
camera_b@1b --- video5
camera_c@1c --- video6
camera_d@1d --- video7

camera_e@1e --- video0
camera_f@1f --- video1
camera_g@1g --- video2
camera_h@1h --- video3

And we checked the dmesg log, found that i2c@c250000 is loaded first and then i2c@3160000.

Therefore, such a problem makes it difficult to control the location of the video node, and the video node will change due to different loading conditions of camera ko module, which has a great impact on the back-end application.

So, we would like to ask, is there any way to fix the video index? Or is there another way to solve my current problem?
Thanks.

3
  1. Maybe write a script to insmod instead of modify /etc/modules-load.d
  2. Assign video # in video_register_device()
../kernel/nvidia-oot/drivers/media/platform/tegra/camera/vi/graph.c

static int tegra_vi_graph_notify_complete(struct v4l2_async_notifier *notifier)
{
        struct tegra_channel *chan =
                container_of(notifier, struct tegra_channel, notifier);
        struct tegra_vi_graph_entity *entity;
        int ret;

        dev_dbg(chan->vi->dev, "notify complete, all subdevs registered\n");

        /* Allocate video_device */
        ret = tegra_channel_init_video(chan);
        if (ret < 0) {
                dev_err(chan->vi->dev, "failed to allocate video device %s\n",
                        chan->video->name);
                return ret;
        }

        ret = video_register_device(chan->video, VFL_TYPE_VIDEO, -1);
        if (ret < 0) {
                dev_err(chan->vi->dev, "failed to register %s\n",
                        chan->video->name);
                goto register_device_error;
        }
4

Hi ShaneCCC,
To set the video num in this function, I think it’s necessary to pass some information from the device tree so that this function can know which camera it is. Do you have any suggestions on how to pass some information from the device tree to this function, or are there other ways for this function to obtain the relevant information?
Thanks.

5

You can apply the devnode like below to the function.

ov5693_a@36 {
 						compatible = "ovti,ov5693";
 						reg = <0x36>;
 						devnode = "video0";