Big latency in i2c writes

[Eximius]

Hello,

I'm doing some latency tests with the i2c communication on the Imx8m Plus, measuring by software the wall time of the i2cwrite function (i2c_smbus_write_byte_data).

When setting the clock speed to 100KHz, single writes take about 500µs. With clock @400KHz, about 300µs.

I was expecting a single write to take something like 280µs (@100KHz) or 70µs (@400KHz). So I always get an overhead of about 220µs, independent of the clock frequency.

I also tried other I2C Buses and other I2C slaves, I always get a similar latency.

Can you advise how we can get closer of the 320kbps (Imx8m specification)?

[Eximius]

@Yuri 

Hi,

thank you for your answer. I measured the i2c timings. For a whole i2c reg write it needs 115µs, this seems to be okay. And then there is pause of 176µs for the next SCL burst.

Can we optimize this?

[Yuri · Accepted solution]

@Eximius 
Hello,

   generally it would be possible to use DMA with I2C, but NXP Linux does not support it.

  Nevertheless, according to i.MX Linux Reference Manual:

"It is strongly recommended not to use I2C SDMA mode when sending small amounts of data.
If there is a special case that needs to send a large amount of I2C data, contact NXP Pro-support
to get the patchset."

Regards,
Yuri

[ceggers]

SDMA support for I2C requires SDMA firmware 3.6/4.6. It is included in firmware-imx-8.12.bin. Additionally you need some small changes in the Linux drivers.

For larger transfers (I2C eeprom), I could increase performance by about 20%. For small transfers, I don't expect much benefit.

regards,
Christian

[Yuri]

@Eximius 
Hello,

   Is it possible to verify (using oscilloscope) if the latency takes place
because of incorrect I2C frequency setting or because of delays between
I2C bursts (with correct frequency)? The recent is quite expectable -
taking into account internal i.MX8 complexity.

Regards,
Yuri.