mpc_i2c_stop() only initiates STOP but does not wait for it to
hit the I2C bus. This is a problem when using I2C devices which
uses fairly long clock stretching just before STOP if you also
have an i2c-mux which may switch to another bus before STOP has
been processed.
Signed-off-by: Joakim Tjernlund <redacted>
---
drivers/i2c/busses/i2c-mpc.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
@@ -574,7 +574,23 @@ static int mpc_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)mpc_write(i2c,pmsg->addr,pmsg->buf,pmsg->len,i);}}-mpc_i2c_stop(i2c);+mpc_i2c_stop(i2c);/* Initiate STOP */+orig_jiffies=jiffies;+/* Wait until STOP is seen, allow up to 1 s */+while(readb(i2c->base+MPC_I2C_SR)&CSR_MBB){+if(time_after(jiffies,orig_jiffies+HZ)){+u8status=readb(i2c->base+MPC_I2C_SR);++dev_dbg(i2c->dev,"timeout\n");+if((status&(CSR_MCF|CSR_MBB|CSR_RXAK))!=0){+writeb(status&~CSR_MAL,+i2c->base+MPC_I2C_SR);+mpc_i2c_fixup(i2c);+}+return-EIO;+}+cond_resched();+}return(ret<0)?ret:num;}
Tabi Timur-B04825 [off-list ref] wrote on 2012/09/02 04:48:01:
On Thu, Aug 30, 2012 at 5:40 AM, Joakim Tjernlund
[off-list ref] wrote:
quoted
- mpc_i2c_stop(i2c);
+ mpc_i2c_stop(i2c); /* Initiate STOP */
+ orig_jiffies = jiffies;
+ /* Wait until STOP is seen, allow up to 1 s */
+ while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
+ if (time_after(jiffies, orig_jiffies + HZ)) {
+ u8 status = readb(i2c->base + MPC_I2C_SR);
+
+ dev_dbg(i2c->dev, "timeout\n");
+ if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
+ writeb(status & ~CSR_MAL,
+ i2c->base + MPC_I2C_SR);
+ mpc_i2c_fixup(i2c);
+ }
+ return -EIO;
+ }
+ cond_resched();
+ }
Shouldn't the while-loop be inside mpc_i2c_stop() itself?
Possibly but I choosed to do it this way as there is a similar loop in the beginning of mpc_xfer().
I figured it has better visibility if it is in the same function.
Jocke
From: Wolfram Sang <hidden> Date: 2012-09-14 14:22:34
On Thu, Aug 30, 2012 at 12:40:04PM +0200, Joakim Tjernlund wrote:
mpc_i2c_stop() only initiates STOP but does not wait for it to
hit the I2C bus. This is a problem when using I2C devices which
uses fairly long clock stretching just before STOP if you also
have an i2c-mux which may switch to another bus before STOP has
been processed.
Signed-off-by: Joakim Tjernlund <redacted>
Patch didn't apply, because it was a p0-patch. Checkpatch would have
warned you.
Fixed that and applied to -next, thanks!
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Wolfram Sang [off-list ref] wrote on 2012/09/14 16:02:34:
On Thu, Aug 30, 2012 at 12:40:04PM +0200, Joakim Tjernlund wrote:
quoted
mpc_i2c_stop() only initiates STOP but does not wait for it to
hit the I2C bus. This is a problem when using I2C devices which
uses fairly long clock stretching just before STOP if you also
have an i2c-mux which may switch to another bus before STOP has
been processed.
Signed-off-by: Joakim Tjernlund <redacted>
Patch didn't apply, because it was a p0-patch. Checkpatch would have
warned you.
Bugger, it is my git config setting:
[diff]
noprefix = true
I always forget to remove that one before generating patches, I will have to remove it.