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

Jean Delvare khali at linux-fr.org
Sat Oct 20 23:14:27 CEST 2007

Hi David, hi Aras,

On Sat, 20 Oct 2007 08:37:02 +1000 (EST), arasv at magtech.com.au wrote:
> > 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.

I see. Of course there's some time spent in the code itself. I didn't
expect it to be noticeable, but for small values of udelay it starts to
matter, that makes full sense. Maybe the documentation for i2c-gpio
should be updated to mention that?

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

Who said it had anything to do with latency? I guess it's mainly the
code itself that uses the extra time.

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

I'm not sure what you are trying to demonstrate here.

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

I don't think this can work. The extra delay depends on the speed of
the CPU and the runtime load, you don't know that in advance at
compilation time. The max speed is 500/udelay, and I don't think you
can guarantee anything else.

Jean Delvare

More information about the i2c mailing list