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

[arasv at magtech.com.au]

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

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?


Aras






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