fe724bf9f0
Usually, the i2c controller has finished emitting the i2c STOP before the driver reaches the bus idle polling loop. Optimize for this most common case by reading IICSTAT first and potentially skipping the loop. If the cpu is faster than the hardware, we wait for bus idle in a polling loop. However, since the duration of one iteration of the loop is dependent on cpu freq, and this i2c IP is used on many different systems, use a time based loop timeout (5 ms). We would like very low latencies to detect bus idle for the normal 'fast' case. However, if a device is slow to release the bus for some reason, it could hold off the STOP generation for up to several milliseconds. Rapidly polling for bus idle would seriously load the CPU while waiting for it to release the bus. So, use a partial exponential backoff as a compromise between idle detection latency and cpu load. Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de> |
||
---|---|---|
.. | ||
algos | ||
busses | ||
muxes | ||
i2c-boardinfo.c | ||
i2c-core.c | ||
i2c-core.h | ||
i2c-dev.c | ||
i2c-mux.c | ||
i2c-smbus.c | ||
i2c-stub.c | ||
Kconfig | ||
Makefile |