summaryrefslogtreecommitdiff
path: root/drivers/i2c/i2c-dev.c
diff options
context:
space:
mode:
authorShinya Kuribayashi <shinya.kuribayashi@necel.com>2009-11-06 15:47:51 +0300
committerBen Dooks <ben-linux@fluff.org>2009-12-09 03:19:11 +0300
commit0774539948b23984f1c866135ba307fa2c441d0e (patch)
tree5e6ef7e974326a25814134148ceef34be8d0c947 /drivers/i2c/i2c-dev.c
parentc70c5cd37413c3fa3503212d26ffdf6df535c9de (diff)
downloadlinux-0774539948b23984f1c866135ba307fa2c441d0e.tar.xz
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>
Diffstat (limited to 'drivers/i2c/i2c-dev.c')
0 files changed, 0 insertions, 0 deletions