I am using a driver that I am told works in BSP 35.4.1, when ported to BSP 35.6.2 (minimal changes were needed), it loads and detects and initializes the i2c/csi camera just fine, but no /dev/videoX nodes are created.
I have enabled dynamic debugging and check that no errors or unexpected code paths are taken during probing.
The only odd thing is that I put some traces on the v4l2_async_register_subdev (called by tegracam_v4l2subdev_register), and found that there are no notifiers in the list to check for matches, and therefore no matches found.
Any idea about what could be wrong?
N.B. I do not use overlays for the camera… I have created a modified version of the jetson-agx-xavier-industrial device tree, and added the camera node directly to the right i2c bus. This has been working fine for BSP 32.7.1
The camera is connected to i2c-3 (i2c@3190000). Device tree and other info come from Framos and all used to work fine for BSP 32.7.1
I cannot fins anything worng with the new driver version, so I am assuming that something in the procedure for cameras in BSP35.6.2 has changed, or there is a bug in the kernel that has passed unnoticed (no notifier in the list makes the async subdev register almost a noop).
Right, comparing, it seems that there is this static int ov5693_debugfs_create(struct ov5693 *priv) function that appears to create something having to do with the videoX device…
I have added the bits that were not there in the nv_imx565, compared with nv_ov5693 driver that you suggested… just a call to of_match_device, probably not needed, since the probe function is called based on of matching anyway, and a call to debugfs_create_dir that creates a camera-videoX in /sys/kernel/debug/ according to devnode in the DT.
No difference. All loads OK, everything runs to completion, and I get no /dev/videoX devices created… which I keep suspecting they should appear on the call to tegracam_v4l2subdev_register, but as I see in the logs (see issue report above), the v4l2_async_register_subdev finds no notifiers registered to be told… so I keep suspecting that there is a kernel bug/patch that needs to be applied.
One weird thing I see is that, when doing an lsmod I see the gmsl serdeses bmodules being used by nv_imx565, despite not having the gmsl key in the DT, and showing that by the log initializing mipi....
I know it’s not the JP version you are using, although it could also give some insight on how newer versions of the Jetson camera capture subsystem does stuff.
err = tegracam_v4l2subdev_register(tc_dev, true);
if (err) {
dev_err(dev, "tegra camera subdev registration failed\n");
return err;
}
Hope that helps.
Please keep us posted and don’t hesitate to reach out if you need further support.
Also, just putting the option out there.
We offer custom camera driver development services, so if you were interested, we could take care of your driver so you can get back to working on actual product features.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
Sure, that line you mention is where I am pointing at… when adding some traces into v4l2_async_register_subdev, called by tegracam_v4l2_subdev_register, I see that there are no notifiers registered to be notified of this new camera appearing… so surely no /dev/vidoX nodes will be created if nobody is listening.
I wonder why, as in BSP 32.7.1 everything was working.
Anyway, I’ll look into that github to see what might be different (I suspect is the same source that Framos gave me as the closest to BSP 35.6.2), otherwise, I’ll probably should check BSP 32.7.1 to see who registers a notifier there, and why that is not happening in BSP 35.6.2.
You can also try diff-ing L4T 32.7.1 and 35.6.2 to see if there are any major changes in the camera capture subsystem that could be causing the errors.
Another options is checking a working driver from 35.6.2 and see if it performs any extra steps.
best regards,
Andrew
Embedded Software Engineer at ProventusNova
Yes, the problem is that I don’t think anybody knows of any working driver for BSP 35.6.2… and given the bugs I have seen before, I suspect there might be none, most likely never tested with any.
Anyway, Most likely tomorrow I’ll find wht notifier I need to look for.
The Framos nv_imx565 driver probe and board setup functions appear in line with the nv_ov5693 ones.
The device tree I am using was working fine in BSP 32.7.1, but I am open to some possible problem, although I have not seen any error message in dmesg.
I’ll have a look at that ov5693 device tree to see if anything seems different too.
But if there are no notifiers in the chain to be notified of the new camera appearing, clearly nothing is going to be done about creating /dev/videoX devices.
Right, looking at the BSP 32.7.1 I see that vi registers notifiers for the two cameras that are connected:
[ 145.313335] imx565 3-001a: probing v4l2 sensor
[ 145.314040] imx565 3-001a: avdd, iovdd and/or dvdd reglrs. not present, assume sensor powered independently
[ 145.315649] imx565 3-001a: tegracam sensor driver:imx565_v2.0.6
[ 145.315666] imx565 3-001a: imx565_board_setup++
[ 145.316647] imx565 3-001a: imx565_power_on: power on
[ 145.349948] imx565 3-001a: imx565_power_off: power off
[ 145.350965] imx565 3-001a: imx565_ctrls_init: Added custom control Data Rate to handler index: 9
[ 145.350976] imx565 3-001a: imx565_ctrls_init: Added custom control Test Pattern to handler index: 10
[ 145.350989] imx565 3-001a: imx565_ctrls_init: Added custom control Sensor Temp to handler index: 11
[ 145.351015] imx565 3-001a: v4l2_async_belongs: notifier v4l2_dev name: tegra194-vi5 15c10000.vi !
[ 145.351031] imx565 3-001a: v4l2_async_belongs: asd of name: /i2c@31c0000/ar1335_e@36 !
[ 145.351039] imx565 3-001a: v4l2_async_belongs: notifier v4l2_dev name: tegra194-vi5 15c10000.vi !
[ 145.351049] imx565 3-001a: v4l2_async_belongs: asd of name: /i2c@3190000/imx565_c@1a !
[ 145.351070] tegra194-vi5 15c10000.vi: subdev imx565 3-001a bound
[ 145.356170] imx565 3-001a: v4l2_async_register_subdev: Matched !
[ 145.356193] imx565 3-001a: Detected imx565 sensor
[ 145.385881] imx565 3-001a: imx565_open:
[ 145.386606] imx565 3-001a: imx565_power_on: power on
[ 145.421838] imx565 3-001a: imx565_power_off: power off
So next thing is to see where those calls are in vi5 and see why they are not called in BSP 35.6.2… maybe the DT needs to be different somehow… one thing I saw is that the of node full_name is no longer the whole path as it is in BSP 32.7.1, but just the name and address for that node in BSP35.6.2, so maybe there are some variation to consider.
Right, all that is done in nvidia/drivers/media/platform/tegra/camera/vi/graph.c: tegra_vi_graph_init, so I need to now put some traces there and find out why it does not get anything to register.
So the csi channels will be bound at the notifier registration time, while the camera endpoints will wait, as they are not powered yet and the driver is blacklisted, so the power is enabled after boot and the driver is loaded then.
The imx565 is found after the last ar1335 camera… all makes sense here.
Will move now to the BSP 35.6.2 again… easier in some ways as I don’t have to sign the kernel image each time I change something.
Right, looking into some device tree for an existing camera, seems that remote-endpoints references change from node handles to full path strings… hopefully that is all that needs to be changed.
That’s a very subtle change that would have been worth being highlighted profusely somewhere in the development guide, I guess.
The imx185 DT shows the old remote-endpoint’s commented and the new format next to them.
@ShaneCCC, A good idea… add a section on migrating from previous version(s) of BSP(s), that highlights these kind of changes, to the development guide.
Will change all those remote endpoints and test tomorrow.
Seems that there is a repeated set of sections in imx185 DT that use the node handles… I guess I’ll have to use traces anyway, but it might be just that change.
Apparently, what was vi@15c10000 before (in BSP 32.7.1) where all the mappins for CSI to VI were, now is separated, and the mappings and other camera things go into tegra-capture-vi that seems to be a separated thing in BSP 35.6.2, rather than a label as I assumed.
As the num-channels was not put there, but in vi@15c10000, then nothing is called.
[ 2.768747] tegra-camrtc-capture-vi tegra-capture-vi: tegra_capture_vi_media_controller_init: enter
[ 2.771489] tegra-camrtc-capture-vi tegra-capture-vi: tegra_vi_media_controller_init_int: enter
[ 2.780137] tegra-camrtc-capture-vi tegra-capture-vi: vi_parse_dt: full name = tegra-capture-vi
[ 2.789051] tegra-camrtc-capture-vi tegra-capture-vi: tegra_vi_media_controller_init_int: num-channels = 0
Definitely, these things need to be highlighted as thinks to look for when migrating from previous versions.