summaryrefslogtreecommitdiffstats
path: root/ipc
diff options
context:
space:
mode:
authorShinya Kuribayashi2009-11-06 13:48:55 +0100
committerBen Dooks2009-12-09 01:19:11 +0100
commit81e798b73aec2d7ce06d18bd191b088c233e554f (patch)
tree4f3121a1708f0632cfec4d750dc064171e987dcf /ipc
parenti2c-designware: Enable RX_FULL interrupt (diff)
downloadkernel-qcow2-linux-81e798b73aec2d7ce06d18bd191b088c233e554f.tar.gz
kernel-qcow2-linux-81e798b73aec2d7ce06d18bd191b088c233e554f.tar.xz
kernel-qcow2-linux-81e798b73aec2d7ce06d18bd191b088c233e554f.zip
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 'ipc')
0 files changed, 0 insertions, 0 deletions