Hello everyone, recently I encountered a small issue while learning about camera driver development on the Orin NX (with a custom carrier board). We have rewritten the device tree and driver for the Sony IMX327 camera and modified the device tree files for the IMX219 and IMX477 cameras. As a result, all three cameras can now run and capture images on the Orin NX. Regarding the custom carrier board, it uses the TCA9548 to multiplex the CAM_I2C signal, with the 7th interface of the TCA9548 connected to a TCA9534 to control the camera power.
However, when I use the i2cdetect command, I encounter a puzzling phenomenon: If I connect only the IMX327 camera (I2C address 0x1a) to the MIPI interface of the development board without loading the corresponding device tree and driver files, the sudo i2cdetect -y -r 2 command cannot detect a device at the 0x1a address. However, the I2C addresses of the TCA9548 and TCA9534 devices are detected.
My question is: Doesn’t the i2cdetect command work by sending signals to all I2C addresses on a bus to detect whether there is an ACK signal? Theoretically, even without the device tree and driver files for the IMX327 camera, shouldn’t the i2cdetect command detect the IMX327 camera when it is connected to the MIPI interface? However, this is not the case. Why is that? The IMX219 camera exhibits the same phenomenon.
I’m not a camera guy, but I’m going to mention some things regarding i2c and device trees which are related.
Drivers in the kernel require a physical address to talk to hardware. Certain classes of devices are “plug-n-play” because there is a system of reporting information about the device and broadcasting that information to drivers. USB and PCIe are examples: The plug-in of one of those devices allows the bus itself to query what the device is and other details. The bus already knows the address of that device. When those systems broadcast information about what the device is to drivers, it is then possible for the driver to take ownership at the relevant physical address (this would be initially true in a similar way even if the memory controller is doing things with virtual addressing behind the scenes).
Other devices do not have a self-reporting mechanism, and they are not plug-n-play. You can put an i2c controller on some physical bus of the system at some particular address, but this device will never be able to report what it is and the driver will never know it is there. One has to manually name the location for the driver to know to look there. The i2c controller is one such device. The i2c mandates firmware (in the form of a device tree) to tell the drivers of a given type to look there.
One reason why this device is not self-reporting is that many of the physical pins on the Jetson module have multiple possible uses. Manufacturers of various carrier boards might redefine which function shows at a given pin just because physical wiring/traces might be more convenient or match impedance better with this alternate routing. I did not check, but it is very likely that without the device tree (which is firmware) not only would the driver not be able to know to look there, but the pin function itself might be entirely wrong (e.g., it could be a GPIO pin until you tell the firmware it is i2c).
i2cdetect itself does what you think of it as doing, at least for the most part. i2cdetect does depend on a subset of i2c known as the SMBus. This is slightly more specific than just a full i2c spec, but you might find devices which i2cdetect does not work with if it doesn’t follow that subset.
Yes, that’s right. For the sensor need device tree could be some power_down/standby/reset pins need initialize in correct state to enable sensor to ack the i2c broadcast command. If you camera HW design don’t need any pins initialize shouldn’t need load device tree for it.
