[PATCH] Let PCA9564 recover from unacked data byte (state 0x30)

[PATCH] Let PCA9564 recover from unacked data byte (state 0x30)

[Enrik Berkhan]

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-JJi787mZWgc@public.gmane.org>
---
 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);
 			goto out;
 
 		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
 			DEB2("Arbitration lost\n");
+			// XXX pca_start()? pca_reset()?
 			goto out;
 
 		case 0x58: /* Data byte has been received; NOT ACK has been returned */

Re: [PATCH] Let PCA9564 recover from unacked data byte (state 0x30)

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2009 bytes --]

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-JJi787mZWgc@public.gmane.org>
> ---
>  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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] Let PCA9564 recover from unacked data byte (state 0x30)

[Enrik Berkhan]

Hi Wolfram,

On Tue, Apr 07, 2009 at 11:04:09PM +0200, Wolfram Sang wrote:
> 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-JJi787mZWgc@public.gmane.org>
> > ---
> >  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)

Yes, of course. Read that as "RFC" :)

> 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?

That sounds good. Updated version will follow.

Enrik
-- 
Enrik Berkhan
Electronics Design Engineer
GE Oil & Gas
PII Pipeline Solutions

T +49 7244 732 476
F +49 7244 732 304
E enrik.berkhan-JJi787mZWgc@public.gmane.org

PII Pipetronix GmbH, Lorenzstraße 10, 76297 Stutensee, Deutschland
Geschäftsführer: David Allen, Werner van Wickeren
Sitz der Gesellschaft: Stutensee
Amtsgericht Mannheim HRB 702297
USt-ID: DE 244323981, Steuer-Nr.: 5930/0173
Deutsche Bank Karlsruhe, BLZ 660 700 04, Kto: 1 435 700 00

[PATCH, v2] Let PCA9564 recover from unacked data byte (state 0x30)

[Enrik Berkhan]

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.

Further, state 0x38 isn't handled completely, either. Try to do another
START in this case like the manual says. As this couldn't be tested,
I've added a comment to try to reset the chip if the START doesn't help
as suggested by Wolfram Sang.

Signed-off-by: Enrik Berkhan <Enrik.Berkhan-JJi787mZWgc@public.gmane.org>
---
 drivers/i2c/algos/i2c-algo-pca.c |    7 +++++++
 1 file changed, 7 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-09 11:10:11.000000000 +0200
@@ -270,10 +270,17 @@ 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);
 			goto out;
 
 		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
 			DEB2("Arbitration lost\n");
+			/*
+			 * The manual says to send another start
+			 * condition in this case. If this won't be
+			 * sufficient, try pca_reset() instead.
+			 */
+			pca_start(adap);
 			goto out;
 
 		case 0x58: /* Data byte has been received; NOT ACK has been returned */

Re: [PATCH, v2] Let PCA9564 recover from unacked data byte (state 0x30)

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]

Hi Enrik,

one minor nit. If that is sorted out, you can add

Reviewed-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Thanks for the patch,

   Wolfram

On Thu, Apr 09, 2009 at 11:38:55AM +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.
> 
> Further, state 0x38 isn't handled completely, either. Try to do another
> START in this case like the manual says. As this couldn't be tested,
> I've added a comment to try to reset the chip if the START doesn't help
> as suggested by Wolfram Sang.
> 
> Signed-off-by: Enrik Berkhan <Enrik.Berkhan-JJi787mZWgc@public.gmane.org>
> ---
>  drivers/i2c/algos/i2c-algo-pca.c |    7 +++++++
>  1 file changed, 7 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-09 11:10:11.000000000 +0200
> @@ -270,10 +270,17 @@ 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);
>  			goto out;
>  
>  		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
>  			DEB2("Arbitration lost\n");
> +			/*
> +			 * The manual says to send another start
> +			 * condition in this case. If this won't be

A pointer, where the manual says it, is always helpful (revision, chapter, page
number or such).

> +			 * sufficient, try pca_reset() instead.
> +			 */
> +			pca_start(adap);
>  			goto out;
>  
>  		case 0x58: /* Data byte has been received; NOT ACK has been returned */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[PATCH, v3] Let PCA9564 recover from unacked data byte (state 0x30)

[Enrik Berkhan]

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 PCA9564 data sheet (2006-09-01) and the same
is done for other NACK states as well.

Further, state 0x38 isn't handled completely, either. Try to do another
START in this case like the data sheet says. As this couldn't be tested,
I've added a comment to try to reset the chip if the START doesn't help
as suggested by Wolfram Sang.

Signed-off-by: Enrik Berkhan <Enrik.Berkhan-JJi787mZWgc@public.gmane.org>
Reviewed-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
 drivers/i2c/algos/i2c-algo-pca.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

Index: drivers/i2c/algos/i2c-algo-pca.c
===================================================================
--- drivers/i2c/algos/i2c-algo-pca.c.orig	2008-12-25 00:26:37.000000000 +0100
+++ drivers/i2c/algos/i2c-algo-pca.c	2009-04-15 09:37:22.000000000 +0200
@@ -270,10 +270,21 @@ 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);
 			goto out;
 
 		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
 			DEB2("Arbitration lost\n");
+			/*
+			 * The PCA9564 data sheet (2006-09-01) says "A
+			 * START condition will be transmitted when the
+			 * bus becomes free (STOP or SCL and SDA high)"
+			 * when the STA bit is set (p. 11).
+			 *
+			 * In case this won't work, try pca_reset()
+			 * instead.
+			 */
+			pca_start(adap);
 			goto out;
 
 		case 0x58: /* Data byte has been received; NOT ACK has been returned */

Re: [PATCH, v3] Let PCA9564 recover from unacked data byte (state 0x30)

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]

Hi Jean,

can you pick this one up? I think it qualifies as a bugfix.

Regards,

   Wolfram

On Wed, Apr 15, 2009 at 09:45:00AM +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 PCA9564 data sheet (2006-09-01) and the same
> is done for other NACK states as well.
> 
> Further, state 0x38 isn't handled completely, either. Try to do another
> START in this case like the data sheet says. As this couldn't be tested,
> I've added a comment to try to reset the chip if the START doesn't help
> as suggested by Wolfram Sang.
> 
> Signed-off-by: Enrik Berkhan <Enrik.Berkhan-JJi787mZWgc@public.gmane.org>
> Reviewed-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
>  drivers/i2c/algos/i2c-algo-pca.c |   11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> Index: drivers/i2c/algos/i2c-algo-pca.c
> ===================================================================
> --- drivers/i2c/algos/i2c-algo-pca.c.orig	2008-12-25 00:26:37.000000000 +0100
> +++ drivers/i2c/algos/i2c-algo-pca.c	2009-04-15 09:37:22.000000000 +0200
> @@ -270,10 +270,21 @@ 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);
>  			goto out;
>  
>  		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
>  			DEB2("Arbitration lost\n");
> +			/*
> +			 * The PCA9564 data sheet (2006-09-01) says "A
> +			 * START condition will be transmitted when the
> +			 * bus becomes free (STOP or SCL and SDA high)"
> +			 * when the STA bit is set (p. 11).
> +			 *
> +			 * In case this won't work, try pca_reset()
> +			 * instead.
> +			 */
> +			pca_start(adap);
>  			goto out;
>  
>  		case 0x58: /* Data byte has been received; NOT ACK has been returned */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH, v3] Let PCA9564 recover from unacked data byte (state 0x30)

[Jean Delvare]

Hi Wolfram,

On Fri, 24 Apr 2009 12:32:18 +0200, Wolfram Sang wrote:
> Hi Jean,
> 
> can you pick this one up? I think it qualifies as a bugfix.

Sure! Sorry I had missed your review. It's queued up for 2.6.30 now.

> 
> Regards,
> 
>    Wolfram
> 
> On Wed, Apr 15, 2009 at 09:45:00AM +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 PCA9564 data sheet (2006-09-01) and the same
> > is done for other NACK states as well.
> > 
> > Further, state 0x38 isn't handled completely, either. Try to do another
> > START in this case like the data sheet says. As this couldn't be tested,
> > I've added a comment to try to reset the chip if the START doesn't help
> > as suggested by Wolfram Sang.
> > 
> > Signed-off-by: Enrik Berkhan <Enrik.Berkhan-JJi787mZWgc@public.gmane.org>
> > Reviewed-by: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > ---
> >  drivers/i2c/algos/i2c-algo-pca.c |   11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > Index: drivers/i2c/algos/i2c-algo-pca.c
> > ===================================================================
> > --- drivers/i2c/algos/i2c-algo-pca.c.orig	2008-12-25 00:26:37.000000000 +0100
> > +++ drivers/i2c/algos/i2c-algo-pca.c	2009-04-15 09:37:22.000000000 +0200
> > @@ -270,10 +270,21 @@ 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);
> >  			goto out;
> >  
> >  		case 0x38: /* Arbitration lost during SLA+W, SLA+R or data bytes */
> >  			DEB2("Arbitration lost\n");
> > +			/*
> > +			 * The PCA9564 data sheet (2006-09-01) says "A
> > +			 * START condition will be transmitted when the
> > +			 * bus becomes free (STOP or SCL and SDA high)"
> > +			 * when the STA bit is set (p. 11).
> > +			 *
> > +			 * In case this won't work, try pca_reset()
> > +			 * instead.
> > +			 */
> > +			pca_start(adap);
> >  			goto out;
> >  
> >  		case 0x58: /* Data byte has been received; NOT ACK has been returned */
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Jean Delvare