[i2c] [PATCH] Is review of AT91 patch pending?

Aras Vaichas arasv at magtech.com.au
Fri Oct 19 02:13:30 CEST 2007

Ronny Nilsson wrote:
> Hi
> Here's an update of my AT91 bus driver with IRQ support. Previously 
> the best speed it could handle was in the range of 30-50 kHz, any 
> higher and transfer errors began occurring. This has however changed. 
> The attached patch can handle 400 kHz, even on a loaded system!
> The patch size ha grown considerably, modifying ten files because 
> achieving this kind of speed with the Atmel TWI controller require 
> some dirty SW tricks... One effect of this is that the I2C throughput 
> will decrease when the cpu has much to do. For example, a basic 
> clockrate of 400 kHz might drop towards 100 kHz when the cpu is very 
> heavily loaded. The general speed of your cpu, ram and flash will 
> also have impact. Default speed is 100 kHz but it can be changed in 
> runtime with /sys/devices/platform/at91_i2c/clockrate. If you change 
> it, ensure to monitor the syslog for error messages from the TWI 
> driver!
> Disclaimer:
> This patch is a hack! I mean it! It's highly experimental, ugly and 
> only tested for Atmel AT91RM9200. Suggestions are most welcome for 
> how to make it nicer looking. Testers are wanted too.

Hi Ronny,

I got this working on the 2.6.23-rc9 kernel (so many changes from rc3!).

First results don't look good, sorry.

I use one of our own i2c EEPROM filing system utility tools for the testing. It 
reads about 4K bytes from an EEPROM, and checks the CRC-32 of the data. This is 
my standard test as it quickly reveals any problems.

In the first tests the CPU was barely loaded. In all cases the physical 
waveform was checked that it met the i2c specifications for risetime. 256 tests 
= 1MByte of data transferred and I ran each batch of tests for as long as I 
think is necessary.

Results for your i2c-at91 driver:

(*) At 10KHz, 256 pass, 0 fail
(*) At 50KHz, 256 pass, 0 fail
(*) At 75KHz, 255 pass, 1 fail
(*) At 100KHz, 252 pass, 4 fail
(*) At 150KHz, 1024 pass, 4 fail
(*) At 200KHz,  1024 pass, 6 fail

Same tests again, but with CPU heavily loaded using the "stress" application:

(*) At 10KHz, 256 pass, 0 fail
(*) At 50KHz, 256 pass, 0 fail
(*) At 75KHz, 255 pass, 0 fail
(*) At 100KHz, 8800 pass, 34 fail (overnight test)
(*) At 150KHz, 380 pass, 70 fail
(*) At 200KHz, 54 pass, 20 fail

As a comparison, I ran the current i2c-gpio driver at about 100KHz and repeated 
the same tests.

(*) At 100KHz, 1371 pass = 1371, 0 fail

I re-ran the i2c-gpio test with stress and all passed as well.

I'm suspecting that there might be something that I run as a daemon that causes 
the i2c to underrun. I will run some further tests with nothing running in the 
background and provide an update when I can.

One thing I don't understand is how an i2c underrun can occur. If I am the 
master transmitter, then I control the clock and I only send bytes when I want 
to. Surely an underrun can only occur when the i2c peripheral is in control of 
the clock, which is never the case for me.


This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 

More information about the i2c mailing list