summaryrefslogtreecommitdiffstats
path: root/drivers/i2c/busses/i2c-at91.c
diff options
context:
space:
mode:
authorShinya Kuribayashi <shinya.kuribayashi@necel.com>2009-11-06 21:48:55 +0900
committerBen Dooks <ben-linux@fluff.org>2009-12-09 00:19:11 +0000
commit81e798b73aec2d7ce06d18bd191b088c233e554f (patch)
tree4f3121a1708f0632cfec4d750dc064171e987dcf /drivers/i2c/busses/i2c-at91.c
parent21a89d4101ce338c2872401c82b66a7c155e24ab (diff)
i2c-designware: Divide i2c_dw_xfer_msg into two functions
We have some steps at the top of i2c_dw_xfer_msg() to set up a slave address and enable DW I2C core. And it's executed only when we don't have STATUS_WRITE_IN_PROGRESS. But we need to make sure that STATUS_WRITE_IN_PROGRESS only indicates that we have a pending i2c_msg to process. In other words, even if STATUS_WRITE_IN_PROGRESS is not set, that doesn't mean we're at initial state in the I2C transaction. Since i2c_dw_xfer_msg() will be invoked again and again during a transaction, those init steps have a possibility to be re-processed needlessly. For example, this issue easily takes place when processing a combined transaction with a certain condition (the number of tx bytes in the first i2c_msg, equals to the Tx FIFO depth). Consequently we should not use STATUS_WRITE_IN_PROGRESS to determine where we're at in an I2C transaction. It would be better to separate those initialization steps from i2c_dw_xfer_msg(). 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/busses/i2c-at91.c')
0 files changed, 0 insertions, 0 deletions