V4l2 subdev ioctl problem

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
,
1

I‘m using our cutom board using Xavier NX in R3273 to test lt6911uxe chip to realize HDMI2MIPI.
When I build the driver as module and insmod it, using ioctl to test has no problem. But when I build the driver into kernel, and there is something wrong with ioctl on subdev. But it’s ok using video0 to stream in both usage.

When use VIDIOC_SUBDEV_G_FMT, I get err info said “Inappropriate ioctl for device”
I’m very confused about it and share this issue with you. Hope I can get some help, thanks！
here is the dmesg of two different usage of the driver
moudule.txt (58.5 KB)
kernel.txt (58.2 KB)

3

hello 854053437,

could you please refer to Verifying the V4L2 Sensor Driver to examine your sensor driver.

4

okay, I‘ll try
thanks

5

Hi, Jerry
here is the test result
v4l2-examine.txt (4.0 KB)
And I’m not sure this would help because in my situation devcie /dev/video0 works fine in both usage, the problem is about the /dev/v4l-subdev

6

hello 854053437,

it should not affect camera use-case, right?
could you please also check release tag to confirm your L4T version. i.e. $ cat /etc/nv_tegra_release

7

Yes, I can use gsteamer to get the hdmi-in video with no problem. Ths issue is our program will firstly use VIDIOC_SUBDEV_G_FMT to get video resolution from sub device node (/dev/v4l-subdev1) and it will get error in this stage if I build this driver inside kernel rather than build as module

our board’s L4T version is
R32(release), REVISION: 7.3, GCID:31982016, BOARD: t186ref, EABI: aarch64,

8

By the way, this driver works fine in our another board using NANO in the same L4T version. And I’m comfirmed that the kernel config is not changed between NANO and Xavier NX’s kernel.
I know nano and xavier nx boot in different flow, but I noticed that in xavier nx, the driver probed in a early time than nano.(in nano driver probed at about 6s after kernel boot, and in xavier nx it’s about 3s).
Is this will affect v4l2 subdev function?

9

hello 854053437,

you may see-also developer guide, Camera Sensor Drivers Porting.

this is helpful information. since you did not seen this with loadable kernel module as well, it may due to driver isn’t ready to cause such issue.
you may try adding some delay in kernel side for loading the driver later to workaround this.

10

okay, I’ll try to delay the driver loading time and see if will fix
Thanks

11

I add 1s and 2s delay in driver init stage, but it still not fix the problem.
Here is the dmesg of nano and xavier nx, and I found a differences between them

This is xavier nx build-in driver probe, and subdev uih,lt6911uxe bound is beforesubdev 15a00000.nvcsi

[    5.949900] tegra194-vi5 15c10000.vi: using default number of vi channels, 36
[    5.952757] tegra194-vi5 15c10000.vi: initialized
[    5.957116] tegra194-vi5 15c10000.vi: subdev uih,lt6911uxe 8-002b bound
[    5.957135] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--1 bound

And this is in xavier nx, insmod the driver module, subdev uih,lt6911uxe bound is aftersubdev 15a00000.nvcsi

[    3.418789] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--1 bound
 ..........
[    207.187801] tegra194-vi5 15c10000.vi: subdev uih,lt6911uxe 8-002b bound

In our nano borad, the driver is build-in kernel and it shows that subdev uih,lt6911uxe bound is still after subdev nvcsi

[    6.365300] vi 54080000vi: initialized
[    6.371131] vi 54080000.vi: subdev nvcsi--1 bound
[    6.375854] vi 54080000.vi: subdev uih,lt6911uxe 1-002b bound
12

hello 854053437,

could you please share the comparison of loadable kernel module and built-in driver.

13

comparison of dmesg is uploaded here

14

hello 854053437,

let’s give it a quick try by adding some delay before tegra_vi_graph_init()
for instance,

diff --git a/drivers/media/platform/tegra/camera/vi/mc_common.c 
@@ -337,6 +337,7 @@ int tegra_vi_media_controller_init(struct tegra_mc_vi *mc_vi,
                goto channels_error;
        }
 
+       usleep_range(100, 110);
        /* Setup media links between VI and external sensor subdev. */
        err = tegra_vi_graph_init(mc_vi);
15

okay, I’ll try it
thanks!

16

It seems there is no change by adding delay before tegra_vi_graph_init()

17

that’s code snippet for subdev bound.
you may try adding some debug message to confirm you’re updating it correctly.

18

I add debug message, and it seems nvcsi is bounded as the same time as our driver device

[    3.923404] tegra194-isp5 14800000.isp: initialized
[    3.930096] tegra194-vi5 15c10000.vi: using default number of vi channels, 36
[    3.932798] tegra194-vi5 15c10000.vi: initialized
[    3.937230] subdev bound init
[    3.937293] tegra194-vi5 15c10000.vi: subdev uih,lt6911uxe 8-002b bound
[    3.937323] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--1 bound

And I tried module insmod, it’s the same that only process subdev bound once

[    3.459151] tegra194-vi5 15c10000.vi: using default number of vi channels, 36
[    3.463440] tegra194-vi5 15c10000.vi: initialized
[    3.468188] subdev bound init
[    3.468273] tegra194-vi5 15c10000.vi: subdev 15a00000.nvcsi--1 bound
......
[  213.079563] lt6911uxe: loading out-of-tree module taints kernel.
[  213.081036] uih,lt6911uxe 8-002b: lt6911uxe_probe 1844: struct i2c_driver.probe
[  213.515400] uih,lt6911uxe 8-002b: check chipid ok, id:0x221
[  213.518553] tegra194-vi5 15c10000.vi: subdev uih,lt6911uxe 8-002b bound
19

hello 854053437,

could you please check the vi/graph.c, did you have below change included?
for instance,

@@ -348,22 +348,6 @@ static int tegra_vi_graph_build_links(struct tegra_channel *chan)
        return 0;
 }
 
-static void tegra_vi_graph_remove_links(struct tegra_channel *chan)
-{
-       struct tegra_vi_graph_entity *entity;
-
-       /* remove entity links and subdev for nvcsi */
-       entity = list_first_entry(&chan->entities,
-                       struct tegra_vi_graph_entity, list);
-       if (entity->entity != NULL) {
-               media_entity_remove_links(entity->entity);
-               video_unregister_device(entity->subdev->devnode);
-       }
-
-       /* remove video node for vi */
-       tegra_channel_remove_subdevices(chan);
-}
-
 static int tegra_vi_graph_notify_complete(struct v4l2_async_notifier *notifier)
 {
        struct tegra_channel *chan =
@@ -474,7 +458,8 @@ static void tegra_vi_graph_notify_unbind(struct v4l2_async_notifier *notifier,
 
        /* cleanup for complete */
        if (chan->link_status) {
-               tegra_vi_graph_remove_links(chan);
+               /* remove video node for vi */
+               tegra_channel_remove_subdevices(chan);
                tegra_channel_cleanup_video(chan);
20

hi, Jerry
I applied this patch in kernel and there is still nothing changed

21

hello 854053437,

since the latest rel-32 release version is r32.7.5, is it possible for moving forward to confirm this issue?

besides,
please sharing the test approach for running VIDIOC_SUBDEV_G_FMT to test locally with Xavier NX developer kit.