[i2c] Is review of AT91 patch pending?

[Ronny Nilsson]

> > > > 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.htm
> > > >l 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.

Hi
I know, there are still some things to be done. That's why I'm asking 
for a review. My main concern currently is the design and basic flow, 
cleanups will follow when the driver otherwise is finished.


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

It's a suggestion from Mark Hoffman earlier this year:
	http://lists.lm-sensors.org/pipermail/i2c/2007-February/000820.html
I made some serious benchmarks of the patch before posting it (huge 
amounts of data was transferred):
	400 kHz  Never works
	100 kHz  Works when cpu is idle
	50 kHz   Works, even when cpu is very heavily loaded
	30 kHz   My safety margin
	10 kHz   Marks safety margin



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

It's a design issue. The user can try his particular system for the 
maximum speed it'll cope - given that it depends on system load and cpu 
clockspeed. And don't forget that there are other members of the AT91 
family than AT91rm9200. Newer members can handle higher speeds.


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

Sure no problem. That's what reviews are for -  getting comments and 
making changes.


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

hmmm, you're right. Thanks.


> 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

I believe you, however I haven't had any problems either after lowering 
the bitclock to 50 kHz and applying my patch. Ideally I think it should 
be up to the user. i2c-gpio is somewhat more reliable but increases 
overhead and cpu load. i2c-at91 works well but might lose a couple of 
bytes in *extreme* situations.

Regards
/Ronny Nilsson