diff options
author | Shinya Kuribayashi <shinya.kuribayashi@necel.com> | 2009-11-06 21:48:55 +0900 |
---|---|---|
committer | Ben Dooks <ben-linux@fluff.org> | 2009-12-09 00:19:11 +0000 |
commit | 81e798b73aec2d7ce06d18bd191b088c233e554f (patch) | |
tree | 4f3121a1708f0632cfec4d750dc064171e987dcf /drivers/i2c/busses/i2c-iop3xx.c | |
parent | 21a89d4101ce338c2872401c82b66a7c155e24ab (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-iop3xx.c')
0 files changed, 0 insertions, 0 deletions