Jetson TX2 Camera I2C Clock Stretching

I have a TX2 with JetPack 4.2.1 and the L4T32.2.0 package installed. I am using the MIPI camera port with a 2 MP camera module attached to a TI Serializer. The camera data is sent through the serializer to a TI deserializer which pipes the camera data to board that connects to the aforementioned MIPI camera port on the TX2. I need to be able to send i2C commands to the camera module using V4L2 drivers to initialize the camera. In order for this to happen, the TX2 needs to be able to send an i2c command from the camera MIPI port to the deserializer, then the deserializer forwards it to the serializer where the camera module gets the command. To work properly with the serializer/deserializer pair, the TX2’s MIPI camera i2c driver needs to support i2c clock stretching. It is currently not working because clock stretching is not supported on the camera’s i2c port and I am unable to send commands to the camera. Is there a way to modify the lower level drivers for that i2c port to enable the clock stretching feature ? Can the speed be slowed down as well? it is operating at 1 MHz currently

hello mbahnsen93,

I don’t think you’ll need to configure clock stretching for sending I2C commands to the camera module.
usually, I2C commands works after you assign correct regulator settings.
here’s document provides the details on the Gigabit Multimedia Serial Link (GMSL) protocol, the hardware connectivity for the serializer/deserializer used in reference module (LI/MAX9296/MAX9295/IMX390), please also check developer guide, Jetson Virtual Channel with GMSL Camera Framework for reference,
thanks

Thank you for your response. I am using an FPD Link Deserializer from Texas Instruments. Are there any helpful integration guides for integrating that with TX2? That is the device that needs to forward my i2c traffic from the TX2 over to the camera on the remote side

hello mbahnsen93,

they’re similar, you’ll need to configure Serializer/Deserializer for carrying the sensor frames to CSI brick.
it also helps if you’re able to enable test-pattern-generator on the bridge driver. thanks

Thank you again. I am able to stream frames to my TX2 just fine and open a video player to view them (the CSI portion of the Serializer/Deserializer works great), my issue was the CAM_I2C controller. Is there a hardware or software timeout parameter that causes this particular i2c port to not work for clock stretching? When I send an i2c command using the associated V4L driver for my camera, the i2c driver within the TX2 needs to be able to handle my slave device (the TI deserializer in this case) “stretching” the i2c clock (holding the SCL line low for a few clock periods). I noticed that another i2c bus on the TX2 does support this feature, but I have to use the CAM_I2C line because that is what the camera driver code uses.

hello mbahnsen93,

please access Tegra X2 Series SoC Technical Reference Manual.
please also check chapter-37, is it clock stretching by the slave you’re talking with? TX2’s I2C buses support I2C clock stretch.
you may also refer to [37.11 Programming Guidelines for Slave in Byte Mode] for some examples regarding to clock stretch,
thanks

hello mbahnsen93,

please also refer to below example, it is for DMA transfer from master to slave but the same API has the other wait_for_completion() calls for DMA receive from slave to master and PIO mode.
the TEGRA_I2C_TIMEOUT is a compile-time macro. This can be tuned to get the desired response. The default value supported is 10s or 10000ms.
In the case of a timeout scenario, the i2c controller is reinitialized to bring the i2c lanes and the controller to a same state.
for example,
$L4T_Sources/r32.5/Linux_for_Tegra/source/public/kernel/kernel-4.9/drivers/i2c/busses/i2c-tegra.c

        if ((tx_len > I2C_PIO_MODE_MAX_LEN || rx_len > I2C_PIO_MODE_MAX_LEN) &&
                        i2c_dev->tx_dma_chan && i2c_dev->rx_dma_chan) {
                if (i2c_dev->curr_direction & DATA_DMA_DIR_TX) {
                        time_left = wait_for_completion_timeout(
                                        &i2c_dev->tx_dma_complete,
                                        TEGRA_I2C_TIMEOUT);