Hi Enrik, On Tue, Apr 07, 2009 at 12:38:56PM +0200, Enrik Berkhan wrote: > Currently, the i2c-algo-pca driver does nothing if the chip enters state > 0x30 (Data byte in I2CDAT has been transmitted; NOT ACK has been > received). Thus, the i2c bus connected to the controller gets stuck > afterwards. > > I have seen this kind of error on a custom board in certain load > situations most probably caused by interference or noise. > > A possible reaction is to let the controller generate a STOP condition. > This is documented in the controller data sheet and the same is done for > other NACK states as well. > > Signed-off-by: Enrik Berkhan <[email protected]> > --- > drivers/i2c/algos/i2c-algo-pca.c | 2 ++ > 1 file changed, 2 insertions(+) > > Index: drivers/i2c/algos/i2c-algo-pca.c > =================================================================== > --- drivers/i2c/algos/i2c-algo-pca.c.orig 2009-04-07 11:23:08.000000000 > +0200 > +++ drivers/i2c/algos/i2c-algo-pca.c 2009-04-07 11:24:56.000000000 +0200 > @@ -270,10 +270,12 @@ static int pca_xfer(struct i2c_adapter * > > case 0x30: /* Data byte in I2CDAT has been transmitted; NOT ACK > has been received */ > DEB2("NOT ACK received after data byte\n"); > + pca_stop(adap);
This looks okay.
> goto out;
>
> case 0x38: /* Arbitration lost during SLA+W, SLA+R or data
> bytes */
> DEB2("Arbitration lost\n");
> + // XXX pca_start()? pca_reset()?
(No // comments, see CodingStyle)
I think we should do something here, too. The manual says something about doing
another start. What about doing this and adding a comment that possibly a reset
is another thing to try in case of problems?
> goto out;
>
> case 0x58: /* Data byte has been received; NOT ACK has been
> returned */
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
