Disconnection issues in GMSL2 - MIPI CSI 2 camera drivers

Hi all,

I’m currently working on GMSL2 - MIPI CSI2 cameras drivers, i’ve seen the example in the NVIDIA sources for sensors like IMX390, and i also worked with camera modules like LI AR0820 camera from Leopard Imaging.

All the drivers doesn’t support cameras disconnection, for example to be able to get the stream, both of the image sensor, serializer and deserializer have to be powered on when the Jetson is switched on, when we disconnect the camera of the deserializer and reconnect it, we will not be able to get the stream anymore, and we have to reboot the Jetson.

Is this V4L2 freature that has to be implemented in the driver ? or is it related to Jetson platform with GMSL cameras ? Because i also worked with a MIPI CSI 2 bridge driver for a video decoder and didn’t find this kind of issue, also we’re using the GMSL cameras modules with x86 PCs and doesn’t have this kind of issue too.

Thank you per advance for any explanations or support

hello chakibdace,

did you meant you’ve physically disconnect/connect the camera module?
may I also know which JetPack release you’re working with?

Yes, that’s right, i disconnect physically the camera, and it seems that the adress of the image sensor doesn’t anymore in the i2c bus.

So i have to reboot the jetson with the camera being connected to make the image sensor detected in the i2c bus, it seems that serializer and deserializer (max9295/max9296) makes an initialization once and only when the jetson boot up.

The jetpack release is 4.4

Thank you for your support

hello chakibdace,

there’s feature called Argus Error Resiliency, which should be included in the latest JP-4.x release version.
it has capability to handle the disconnection use-case by camera software stack, please try moving to the later JP-4 version, i.e. Jetpack-4.6.3 for confirmation.

even though, may I know what’s your real use-case to physically disconnect/connect the camera module?
you may see-also similar discussion threads, such as Topic 179688 for reference,
thanks

Hi @JerryChang

Thank you for your support, i thought that this issue is due to the driver handeling of the camera module, in fact that even with using v4l2, the v4l2 tests fail, for example when i launch :

$ v4l2-ctl --stream-mmap -d /dev/video0

The driver fails to write registers to the image sensor, and when scanning with i2cdetect or trying to read registers values from the sensor, i get errors in fact that there is no image sensor detected anymore by the system, so i thought is due to a GPIO initialization of the serializer which is done only once.

The main purpose of disconnecting camera is only to disconnect one and test with another only.

Thank you

hello chakibdace,

could you please setup a terminal to keep gathering kernel logs. i.e. $ dmesg --follow
please reproduce the issue again and please also share the complete logs for reference,
thanks

Hi @JerryChang

I reproduced the issue with some logs in the camera image sensor driver, you can find two text files :

connected.txt : The camera module has been connected when the jetson boot up
disconnect_and_reconnect.txt : The camera module has been disconnected and reconnected

connected.txt (15.4 KB)
disconnect_and_reconnect.txt (113.1 KB)

When disconnecting the camera and reconnect it, it has the same behavior as it’s being disconnected, the i2c unique adress of the image sensor doesn’t appear anymore and it’s not possinle to make R/W i2c requests.

Thanks

hello chakibdace,

this looks camera device did not register to linux kernel after you disconnect it.
could you please try this kernel fixes to requests probe retry.
for example,

diff --git a/drivers/platform/tegra/rtcpu/device-group.c b/drivers/platform/tegra/rtcpu/device-group.c
index fadae24d9..4dbd10edb 100644
--- a/drivers/platform/tegra/rtcpu/device-group.c
+++ b/drivers/platform/tegra/rtcpu/device-group.c
@@ -51,7 +51,7 @@ static int get_grouped_device(struct camrtc_device_group *grp,
 
        if (pdev == NULL) {
                dev_warn(dev, "%s[%u] node has no device\n", name, index);
-               return 0;
+               return -EPROBE_DEFER;
        }

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.