i.MX535 I2C Time between clearing an interrupt and reading from the data register

[kallekankare]

Hi,

We are using the mainline kernel for i.MX535 and the driver for it (i2c-imx.c). We are using the i2c to read 2 bytes from a device (a simple sensor).

The driver works in such a way that each time data is written or read to/from the I2C_I2DR register it waits for the interrupt handler to receive and clear the IIF bit in the I2C_I2SR register. The interrupt handler notifies the driver to continue (reading/writing another byte). The DMA is not used.

The problem is that if there is too much time spent on CPU being busy between clearing of the IIF bit and reading the next byte from the I2DR register, the register's contents are 0xFF (I.e. wrong). In cases where the register is read quicker, the contents are proper.

Is there some limitation in hardware on how long the value stays in the I2DR register after the IIF has been cleared ?

[igorpadykov]

Hi Kalle

just for reference one can check latencies (like context switching)

https://community.freescale.com/docs/DOC-94571

~igor

[fabio_estevam]

Which sensor is this? Is its driver also available in mainline?

I would suggest you to post to linux-i2c@vger.kernel.org

Regards,

Fabio Estevam

[kallekankare]

The sensor is TMP112.

I implemented a configurable forced delay between the receiving of the interrupt and proceeding to read the contents of the I2DR. It seems that only this sensor presents this behaviour. Other I2C devices seem to work correctly regardless of how long a delay I put there.

Now that I look into the TMP112 datasheet it seems to have a timeout function which triggers if the line has been silent between start and stop conditions at least 30ms. That would explain the behaviour. I.e. the sensor is no longer in a state to respond if after writing the slave address it has to wait over 30ms for the next byte.

I will have to check if enabling DMA for the i2c-imx driver would eliminate any unwanted delays within the i2c message.

Thank you all for the responses.

[kallekankare · Accepted solution]

Now I'm feeling dumb.

I was checking the raw communication to the tmp112 device through i2c and it has this kind of behaviour. The lm75 driver seems to account for this and return a proper value to userspace regardless of how many delays there are in the communication.