[i2c] Is review of AT91 patch pending?

[David Brownell]

> > > Do we really want to try fixing the i2c-at91 driver at all? David
> > > Brownell and Aras Vaichas seem to believe that there is no way that
> > > it can be made completely reliable due to hardware issues, and that
> > > using the generic i2c-gpio driver is the way to go on these systems.
> > 
> > Well, it's correct that the AT91 driver never will be 100% reliable (on 
> > AT91RM9200 that is). However, with my patch, support it's *WAY* more 
> > reliable than with the one already in mainline. If i2c-gpio is the way 
> > to go then the AT91 driver already present in the kernel should be 
> > removed too.
>
> That's what I meant, yes. Can someone please send me a patch either
> marking i2c-at91 as BROKEN with some explanations in Kconfig (if it's
> still worth improving), or plain removing it (if it's hopeless)?

I did the former.  I suspect that using the "internal address"
mechanism might be the path to having repeated start conditions
work, and know that on some systems the cpu costs for i2c-gpio
will argue for trying harder to make this driver work.

Atmel's "i2c-atmeltwi" driver is also IRQ-driven, and may be a
slightly better base to move forward with (for AT32 and AT91).
Same controller, meaning the same underlying problems, though...

- Dave

=======	CUT HERE
Mark the i2c-at91 driver BROKEN in Kconfig, and explain just
why it's broken.  (Summary:  hardware design issues.)

Signed-off-by: David Brownell <dbrownell at users.sourceforge.net>
---
 drivers/i2c/busses/Kconfig |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/i2c/busses/Kconfig	2007-09-24 14:11:49.000000000 -0700
+++ b/drivers/i2c/busses/Kconfig	2007-10-03 13:15:09.000000000 -0700
@@ -75,11 +75,19 @@ config I2C_AMD8111
 
 config I2C_AT91
 	tristate "Atmel AT91 I2C Two-Wire interface (TWI)"
-	depends on ARCH_AT91 && EXPERIMENTAL
+	depends on ARCH_AT91 && EXPERIMENTAL && BROKEN
 	help
 	  This supports the use of the I2C interface on Atmel AT91
 	  processors.
 
+	  This driver is BROKEN because the controller which it uses
+	  will easily trigger RX overrun and TX underrun errors.  Using
+	  low I2C clock rates may partially work around those issues
+	  on some systems.  Another serious problem is that there is no
+	  documented way to issue repeated START conditions, as needed
+	  to support combined I2C messages.  Use the i2c-gpio driver
+	  unless your system can cope with those limitations.
+
 config I2C_AU1550
 	tristate "Au1550/Au1200 SMBus interface"
 	depends on SOC_AU1550 || SOC_AU1200