[i2c] AT91 bus driver loses data

[Ronny Nilsson]

Hi
I've found problems with the AT91 I2C driver I'd like to discuss. I'm a 
user of the the Atmel AT91RM9200 cpu and just recently begun using I2C. 
For small transfers it works quite OK, however, for somewhat large 
transfers I've found the current driver to be unreliable...

Explanation:
* The driver ain't using the full capacity of the hardware to detect 
errors. Things like overruns and NACKs are silently ignored.

* The driver uses polling for receive and transmit. While this works 
fine on an idle system it seems to create data loss on busy ones. A 
board experiencing modest network load will spend a fair amount of time 
servicing interrupts etc., which in turn make the I2C driver to miss 
characters. (There is only a one byte buffer in the HW). The cpu in 
those cases issue an error flag for overrun/underrun, but since the 
driver ignore them the transferred data is simply lost or become 
garbage.

* The cpu errata recommends using interrupts in favour of polling for 
detecting the error flags mentioned above. Simply adding a oneliner 
check unfortunately isn't enough.


Because of the small buffer (one byte) events should be serviced 
quickly. I made a test shot of disabling cpu interrupts at some 
critical sections in the driver which confirmed the explanations above. 
Large I2C transfers work perfect with interrupts disabled. 
Unfortunately the critical section is quite lengthy... I need about 1.5 
ms just for reading the time out of my RTC. Running that long with 
interrupts disabled ain't a good solution.

I propose a redesign of the AT91 I2C driver. Using interrupts instead 
of polling should enhance the reliability and lessen risk of data loss. 
- Or, at least something should be done to detect errors if/when they 
occur. I've searched the list archive for any reason to why that 
approach wasn't adopted right from the start, but failed to find one. 
Perhaps have I missed something? Are there any 
technical/political/other reason for *not* using an interrupt based 
driver?

If you'd like I gladly help with the work.

Best Regards
/Ronny Nilsson