I’m currently using two GMSL2 custom cameras, the first camera is using max9295a serializer and second one is using max96911D serializer, am using the setup below :
Camera - ser max9295a ==> Li deser max9296a ==> Li adapt mipi (mux tca) ==> Jetson AGX Xavier
We made a driver for the camera imager and we used max9295a and max9296a nvidia drivers for serializer and deserializer, and we configured the device tree so we can use 4 cameras gmsl2 serial link with the serial mipi interface to have 4 i2c buses for each camera
i2c 30
i2c 31
i2c 32
i2c 33
The imager and the serializer of the camera which has a max9295 are detected when i run
i2cdetect -r -y 30
but the one with the max96911D is not detected, i guess that is due to the device tree config and that there is not the correct mapping between max9296a and max96911D.
Is that any solution that i make the adress of the serializer and deserializer appearing by updating drivers and device tree ?
In general I would say your issue could be fixed by extending support in the device drivers and device tree. Just to know a little bit more about your use case, are you using separate deserializers for each camera or the same deserializer for both?
I am using for both cameras the same Deserializer, It’s the MAXIM9296A, it should be compatible for both serializer MAXIM9295A and MAXIM96911D, i thought that when creating in the device tree the bus i2c 30 i will be able to detect the camera but i guess i have to implement in the DT the mapping between the deser and ser
Yes, correct. In general your device tree would need to describe each serializer, for example, i2c 30 and i2c 31. Also if the configuration of your other serializer (MAXIM96911D) is different possibly your deserializer device driver would need to handle that case too.
@jchaves i thought that when hardware is correctly plugged, there is no driver need to detect the sensors, for example, when a device is connected in an i2c bus, using the command i2cdetect will show you all the devices that are connected in that bus, and to be able to use this latter, we have to implement a driver that use the i2c physical adress of that sensor, it’s a little bit confusing but i’ll try to figure out how to configure the hw to detect the sensors.
Well, in general I would say that if the power supplies, clocks, etc are already supplied then yes a chip would show up in the I2C bus with i2cdetect without the need of a device driver or device tree instance even, your case is more complex though, since involves a serdes pair.
Thank you a lot for your feeds back, i think that you are right, i am used to work directly with MIPI CSI 2 driver bridge like video decoders, which are not complexe as this case where there is a conversion from GMSL2 to MIPI CSI 2, my setup is the same as the following, the max9295 serializer is just remplaced by max9611D serializer
In nvidia sources, i’ve found an example of a driver for max9612 which is an alternative for max9611, but it doesnt use gmsl2, so i guess i have to adapt it and make sw kernel drivers as the following :
Thanks for the diagram, that ilustrates your topology very clearly. One suggestion that I have is that you try to develop your max9611 support as if the max9295 was not available at all (not even physically connected to the Jetson system). That way if you are able to make the max9611-max9296 pair work then you can try to merge the support for both serializers. Also you could try to make max9611 visible by developing a script with pure i2ctools commands, that way later you could just move that configuration to your drivers.
