[i2c] Is review of AT91 patch pending?

[David Brownell]

> > * Ronny Nilsson <rln-i2c at arbetsmyra.dyndns.org> [2007-09-10 17:00:50 +0200]:
> > > I posted a patch för AT91 several months ago, to make the current bus 
> > > driver interrupt driven instead of using polling.
> > > 	http://lists.lm-sensors.org/pipermail/i2c/2007-June/001425.html
> > > Unfortunately no one has rewieved it yet.  :-(   I'm wondering if it's 
> > > still pending? It would be nice to have it merged in the next merge 
> > > window...

ISTR that scripts/checkpatch.pl has many comments ... and that I
gave this a whirl and my board didn't boot.

My notes also say the CONFIG_I2C_CLOCKRATE seems odd ... if that's
actual bits-per-second, then why is the default 10K not 100K, and
why is the "highest recommended speed" 50K not 400K?  (And if those
recommendations are serious, why isn't there "hard" enforcement, or
even soft enforcement in Kconfig?)

If the issue is protocol breakage due to overflow and underflow errors
(which I've seen and which make me think there are hardware design bugs,
since those are "no reason to happen" flow control problems) that should
be explicitly stated.  Among other things it'd be a function of system
load and how fast the CPU is being clocked, so that loaded systems
could easily start to display I2C problems.  The AT91rm9200 errata for
TWI are worrisome...

This driver still claims to support SMBus "Quick" transfers, which
from what I can see are not allowed by the hardware.   All the docs
describe how to transfer at least one byte, and the hardware setup
on both RX and TX paths presumes transferring at least on byte.
Which means "quick" transfers of zero bytes can't happen...


> > I wanted to continue to help with this, but I couldn't find the time.  Just
> > in case there was anyone still waiting on me... please don't.  I hope you
> > will find someone who actually has the hardware to continue the review from
> > here.  I'm sorry.
>
> 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.

There's also "i2c-atmeltwi" from the avr32 folk, also IRQ-driven,
which I looked at recently and observed to have similar problems.

Meanwhile, i2c-gpio hasn't had *any* problems.  ("i2cdetect -F 0"
says it doesn't support PEC, but that's a bug in i2cdetect:  its
source says it means not PEC, but _hardware_ PEC.)

- Dave


> Either way, I am not skilled to review this i2c-at91 patch, so in order
> to get it upstream (if we still want to do that) someone else will have
> to do the review.
>
> -- 
> Jean Delvare
>