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

arasv at magtech.com.au arasv at magtech.com.au
Sat Oct 20 00:37:02 CEST 2007

> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4631/1
>> > +static struct i2c_gpio_platform_data pdata = {
>> > +	.sda_pin		= AT91_PIN_PA25,
>> > +	.sda_is_open_drain	= 1,
>> > +	.scl_pin		= AT91_PIN_PA26,
>> > +	.scl_is_open_drain	= 1,
>> > +	.udelay			= 2,		/* ~100 KHz */
>> The i2c-gpio documentation says: SCL frequency is (500 / udelay) kHz.
>> So that should be 250 kHz. Not sure if it's a good idea as not all I2C
>> slaves may support it. Maybe you should set udelay to 5.
> Except that when I measured it, that formula didn't work.
> There's overhead other than the udelay.

Yes, I've noticed the same thing. The delay seems to require a certain amount
of calibration via oscilloscope to get closer to the desired target clock

When I set .udelay for "100 kHz" I actually get 78kHz. This did concern me.
Is there really that much latency? I would guess that different RT versions
of Linux would give different results for this driver.

Since this is a bit-bang method, only a fraction of the clock cycles will be
at 100kHz. The rest of the time, the clock cycles are always going to be
slower. On Monday I will set up an oscilloscope to trigger on 100kHz and see
if *any* of the clock cycles are running at the desired clock rate.

The (500/udelay) calculated clock will always be a safe value and within the
spec of the peripheral. Users that know what they are doing can adjust this
value themselves, or should it be in Kconfig?


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