Fix /dev/videox device

HI!
I have a custom board with 3 CSI camera input (Analog Devices chips) and some USB ports.
I would like to have the 3 CSI camera fixed on /dev/video0, /dev/video1 and /dev/video2 and when I plug a USB camera on an USB port it get /dev/video3, /dev/video4, etc.
It’s working if I plug the camera after the boot. But if I plug it before the boot the USB camera got the /dev/video1 device.
is there any way to block the video0 to 2 only to CSI cameras? It’s configured on DT, but only for the first one (/dev/video0) it’s working.

Thanks

hello alfredosalvarani,

there’s video device registration during kernel initialization stage.
in general, you should have CSI camera connected before power-on the board.

may I know what’s your use-case to connect CSI camera after power-on?
thanks

Hello Jerry,
CSI camera are connected before power-on.
USB camera maybe connected before or after.
If I plug USB camera after the power-on, there’s no problema, USB camera goes to /dev/video3 or 4 or 5…
If i plug USB camera before power-on, USB camera goes to /dev/video1 and it’s the problem because I need, always CSI cameras on /dev/video0, /dev/video1 and /dev/video2, no matter when I connected the USB camera.

hello alfredosalvarani,

could you please share kernel init messages with above condition for reference,
for example, $ dmesg > klog.txt

BTW,
may I also know what’s your use-case for having three CSI cameras locate on /dev/video0, /dev/video1 and /dev/video2.
thanks

Here is the dmesg log for boot with USB camera connected
klog.txt (89.6 KB)

The use case for having three CSI cameras ate video0 to video2 is: My application generate a composite video with three specific sources, and I use this fixed device to access these specific videos. The user connect their video sources on specific hardware input that “flow” to /dev/video1 for example. Then If a USB camera take the place of the video source from /dev/video1, the composite image is generated wrong, because on the place the user expected the source incoming from that input will shows the image from USB camera.

hello alfredosalvarani,

it seems your CSI camera drivers (1-0071 and 1-0070) were register just after UVC drivers.
for example,

[    7.153379] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:082d)
[    7.260105] usbcore: registered new interface driver uvcvideo
[    7.260109] USB Video Class driver (1.1.1)
...
[    7.263802] tegra-vi4 15700000.vi: subdev adv748x 1-0071 txa bound
[    7.285116] ADV7482 Probe success
[    7.448941] tegra-vi4 15700000.vi: subdev adv748x 1-0070 txa bound
[    7.462001] ADV7482 Probe success

you may have a quick testing to let UVC driver register USB camera later.
for example, adding some delays.

static int uvc_probe(struct usb_interface *intf,
                     const struct usb_device_id *id)
{
...
        #add some delay here
        if (v4l2_device_register(&intf->dev, &dev->vdev) < 0)
                goto error;

Hi Jerry,
I did the modifications you suggest but it didn’t worked, I don’t know if the kernel run these lines because I put a print log in the same place and none was printed on dmesg.
Do you have another suggestion?

hello alfredosalvarani,

there’re two ways to update kernel image,
you might also refer to Flashing a Specific Partition to have partition update by enable the flash script.
i.e. $ sudo ./flash.sh -r -k kernel jetson-tx2 mmcblk0p1
there’s also cboot to choose kernel image by checking LINUX entry in the /boot/extlinux/extlinux.conf

hence,
you may remove LINUX entry for loading kernel image from partition or replacing the image of /boot/Image to make your change works.
thanks

Yes, of course I did re-flashed the board with command:
$ sudo ./flash.sh -r -k kernel jetson-tx2 mmcblk0p1
I don’t know if the usb driver even call the v4l2_device_register(&intf->dev, &dev->vdev) function, because I put a uvc_printk just before it (and a msleep too) and I can’t see it on dmesg log.
But tomorrow I’ll test it a little more.
Do you know a way to change the in-side driver load order?

hello alfredosalvarani,

my meant, you should also look into /boot/extlinux/extlinux.conf; it still loads the kernel image via LINUX entry instead the kernel you’d update to the kernel partition.
thanks

Hi Jerry you were right, the delay worked as expected.
I used a script I made to update the kernel (I had forgotten it) and “voilà”.
But I figured out that the video drivers was compiled as modules, then I compiled it inside the kernel and it worked without the additional delay.
Thank you!