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 <Enrik.Berkhan@xxxxxx>
> ---
> 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/ |
Attachment:
signature.asc
Description: Digital signature
