I'm having a problem with I2C and I'm not sure what to try next.
If I connect my Sensor (Aptina MT9T001) directly to the OMAP3 I2C (through a level shifter of course) then I can communicate to it just fine. I'm using i2cget and i2cset to test it.
If I connect my Sensor to the OMAP through a National Semiconductors Channel Link III device (it serializes the video and the I2C) then I run into problems with the sensor not sending back ack's. During a read command it will send back an ACK in response to the initial I2C address (0x5D followed by a R/W=0), and it will send back an ACK after the register address. It just doesn't send back an ACK after the next command which is READ (0x5D followed by a R/W=1).
I don't know what could be confusing the Sensor.
Now the Channel Link III Deserializer does use clock stretching. It will stretch the clock from the OMAP to give enough time for the Data to come back from the Serializer/Sensor.
Initially I suspected the OMAP was getting confused by the clock stretching, but it seems to be working fine on that end. I can't find anything in OMAP3530 TRM I2C chapter or the Linux drivers that mentions supporting clock stretching though.
Now this might or might not having anything to do with the I2C interface on the OMAP. I'm writing this mainly to see if anyone has had any issues clock stretching the I2C clock on the OMAP using the linux driver.