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

[David Brownell]

On Friday 19 October 2007, 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.
> 
> 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.

I measured using a TotalPhase "Beagle", though having a 'scope
would be more useful in many other cases.  Maybe one of those
nice new ones from Tek, which can be programmed as analyzers
for I2C, SPI, USB, and numerous other protocols.  :)

Unfortunately I think I may have measured using a slow version
of that more-general GPIO code I posted ... I'll want to measure
it again when I have a moment.


> Is there really that much latency? I would guess that different RT versions
> of Linux would give different results for this driver.

Yes ... 

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

Not necessarily.  Some in-spec devices won't be able to handle
clocks over 10 KHz ... that's all SMBus requires, anyway, but
I2C allows even slower clock requirements.

One board I worked with had a very slow microcontroller which
was bitbanging I2C, and it choked if you drove it over 20 KHz.
Badly, as in bus-lockup forcing a board reset (since you could
not access the other devices on that bus).


> Users that know what they are doing can adjust this 
> value themselves, or should it be in Kconfig?

One suggestion to Haavard (maintainer of i2c-gpio) is to
switch the platform data so it can use ndelay() ... that
way it can support higher clock rates (e.g. 1Mbit Fm+).

I tend to think Kconfig here would be confusing overkill.

- Dave