Problem porting from Yocto Dunfell to Kirkstone - Cameras detected but no video devices created.

[taldhous-imetrum]

I am trying to upgrade our Yocto image for a custom carrier board with a Xavier NX processor from Dunfell (L4T 32.7.3) to Kirkstone (L4T 35.4.1), but I am having trouble getting the cameras to work.

The device tree has been updated to reflect the changes from L4T 32 to L4T 35.

On boot, the cameras are detected, but no video devices are created in /dev (i.e. no /dev/video0 or/dev/video1). Comparing the output of the command "media-ctl -d /dev/media0 -p" on Dunfell with the output from the same command on Kirkstone indicates that several v4l2 subdevs are missing:

Dunfell
=======

Media controller API version 0.1.0

Media device information
------------------------
driver          tegra194-vi5
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  0.0.0

Device topology
- entity 1: vc_mipi 9-001a (1 pad, 1 link)
            type V4L2 subdev subtype Sensor flags 0
            device node name /dev/v4l-subdev0
    pad0: Source
        [fmt:Y8_1X8/2432x828 field:none colorspace:raw]
        -> "15a00000.nvcsi--4":0 [ENABLED]

- entity 3: 15a00000.nvcsi--4 (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev1
    pad0: Sink
        <- "vc_mipi 9-001a":0 [ENABLED]
    pad1: Source
        -> "vi-output, vc_mipi 9-001a":0 [ENABLED]

- entity 6: vi-output, vc_mipi 9-001a (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
    pad0: Sink
        <- "15a00000.nvcsi--4":1 [ENABLED]

- entity 18: 15a00000.nvcsi--3 (2 pads, 0 link)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev2
    pad0: Sink
    pad1: Source

- entity 21: 15a00000.nvcsi--2 (2 pads, 0 link)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev3
    pad0: Sink
    pad1: Source

- entity 24: vc_mipi 12-001a (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev4
    pad0: Source
        [fmt:Y8_1X8/2432x828 field:none colorspace:raw]
        -> "15a00000.nvcsi--1":0 [ENABLED]

- entity 26: 15a00000.nvcsi--1 (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev5
    pad0: Sink
        <- "vc_mipi 12-001a":0 [ENABLED]
    pad1: Source
        -> "vi-output, vc_mipi 12-001a":0 [ENABLED]

- entity 29: vi-output, vc_mipi 12-001a (1 pad, 1 link)
             type Node subtype V4L flags 0
             device node name /dev/video1
    pad0: Sink
        <- "15a00000.nvcsi--1":1 [ENABLED]

Kirkstone
=========

Media controller API version 5.10.120

Media device information
------------------------
driver          tegra-camrtc-ca
model           NVIDIA Tegra Video Input Device
serial          
bus info        
hw revision     0x3
driver version  5.10.120

Device topology
- entity 1: vc_mipi 9-001a (1 pad, 0 link)
            type V4L2 subdev subtype Sensor flags 0
        pad0: Source

- entity 3: vc_mipi 12-001a (1 pad, 0 link)
            type V4L2 subdev subtype Sensor flags 0
        pad0: Source

In the Dunfell version, the boot logs show 15c10000.vi being initialised and several vi5 subdevs being "bound":

[ 13.733233] tegra194-vi5 15c10000.vi: using default number of vi channels, 36 [ 13.743957] tegra194-vi5 15c10000.vi: initialized [ 13.753795] tegra194-vi5 15c10000.vi: subdev vc_mipi 9-001a bound [ 13.754141] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--4 bound [ 13.755688] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--3 bound [ 13.756005] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--2 bound [ 13.756254] tegra194-vi5 15c10000.vi: subdev vc_mipi 12-001a bound [ 13.756427] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--1 bound

In the Kirkstone version, 15c10000.vi is initialised, but nothing is "bound":

[ 10.643724] tegra194-vi5 15c10000.vi: initialized

What might be going wrong, and where should I be looking to find the problem?

Thanks

[taldhous-imetrum]

Finally fixed this issue. The problem was that the reg indices for the ports in the tegra-capture-vi/ports node must increase uniformly (i.e 0, 1, 2, 3). Our custom carrier has four camera ports, but two are not being used and were commented out of the device tree. As these were on the middle ports, it created a gap in the reg indices sequence (which went 0, 3), which causes the initialisation of the driver to fail.