i2c-designware: Process i2c_msg messages in the interrupt handler
authorShinya Kuribayashi <shinya.kuribayashi@necel.com>
Fri, 6 Nov 2009 12:47:51 +0000 (21:47 +0900)
committerBen Dooks <ben-linux@fluff.org>
Wed, 9 Dec 2009 00:19:11 +0000 (00:19 +0000)
commit0774539948b23984f1c866135ba307fa2c441d0e
tree5e6ef7e974326a25814134148ceef34be8d0c947
parentc70c5cd37413c3fa3503212d26ffdf6df535c9de
i2c-designware: Process i2c_msg messages in the interrupt handler

Symptom:
--------
When we're going to send/receive the longer size of data than the Tx
FIFO length, the I2C transaction will be divided into several separated
transactions, limited by the Tx FIFO length.

Details:
--------
As a hardware feature, DW I2C core generates a STOP condition whenever
the Tx FIFO becomes empty (strictly speaking, whenever the last byte in
the Tx FIFO is sent out), even if we have more bytes to be written.
Then, once a new transmit data is written to the Tx FIFO, DW I2C core
will initiate a new transaction, which leads to another START condition.

This explains how the transaction in question goes, and implies that
current tasklet-based dw_i2c_pump_msg() strategy couldn't meet the
timing constraint required for avoiding Tx FIFO underrun.

To avoid this scenario, we must keep providing new transmit data within
a given time period.  In case of Fast-mode + 32-byte Tx FIFO, for
instance, it takes about 22.5[us] to process single byte, and 720[us] in
total.

This patch removes the existing tasklet-based "pump" system, and move
its jobs into the interrupt handler.

Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi@necel.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
drivers/i2c/busses/i2c-designware.c