[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.
>
> Hi
> 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.

It might be nice to hear from Atmel on this.  Not to disparage the
notion of improving code that's unreliable ... but from what I've
seen, the basic silicon problems are repeated in multiple products.

And the "i2c-atmeltwi" driver (used on AVR32) should be considered
too ... same controller would logically imply the same driver.  (That
code is also IRQ driven.  I'll send you a copy off-list.)


> For the AT91SAM9 successor family line the driver is "probably" 100% 
> reliable because they have a redesigned I2C controller. I have no HW to 
> actually try those myself though.

Near as I can tell, it's still the same design.  They've updated
docs, and some versions document slave support ... unclear if that's
just a documenttion issue (like removal of the overflow and underflow
flags) or is really a silicon update fixing more than minor problems.

The AVR32 Silicon -- released *after* the SAM9 family -- still has the
same design glitches though:  underruns and overruns happen easily
(since the host doesn't seem to stretch clock cycles), and it still
can't issue repeated starts or SMBus "quick" transactions.

- Dave