[i2c] AT91 bus driver loses data

Mark M. Hoffman mhoffman at lightlink.com
Sat Feb 17 17:19:09 CET 2007

Hi Ronny, Jean:

* Ronny Nilsson <rln-i2c at arbetsmyra.dyndns.org> [2007-02-16 01:04:18 +0100]:
> > > > OK, I see it's hard-coded to 100kHz in the driver.  Try dropping
> > > > that to ~10kHz and see what happens.  If things still don't
> > > > improve, then you can either try to find and kill the big
> > > > interrupt blocker or slow down the bus even more.
> > >
> > > I totally agree, busy waiting is awfully awkward! I spent about two
> > > days just for trying to get wait_event() working before giving that
> > > up... It *is* possible to reduce the wire speed though as a
> > Most SMBus masters drive the bus at 16 kHz. Bit-banging interfaces
> > can do anything between 5 and 55 kHz depending on the value of
> > .udelay.
> Hi
> That's good to know, thanks.
> > Given that you rarely transfer large amounts of data over I2C anyway,
> > the speed doesn't matter that much. Of course faster is better, but
> > slower and reliable is better than faster and unreliable.

Faster is not always better, even where reliability is not in question.  This
particular driver is for a relatively resource constrained board for embedded
systems.  The system as a whole must be taken into account.  If you run the
I2C bus as fast as it will work reliably, the interrupt load can still hurt the
response of other (perhaps more important) parts of the system.  I.e. if you
don't *need* the I2C bus to be fast, it's usually *better* to run it slow.

> Actually my system _is_ one of those which will use I2C for large data 
> transfers, but that's another story... I'll change the patch to a more 
> system friendly behaviour. Mark, any other comments?

Large transfers still do not necessarily imply that you need maximum bandwidth.
I don't know the specific requirements of your application, nor do we know the
requirements of any other users.

With all of the above in mind, I suggest:

1) The I2C bus speed should be tunable, by a sysfs file *and* a module param.

2) The default speed should be fairly slow, e.g. 10KHz.  This should allow
for reliable operation even when there is a moderate to heavy interrupt load
from other devices (Ronny - I would like you to confirm that).  Anyone who
*requires* faster I2C bus speed than that can go ahead and turn it up... and
beware the consequences given that the AT91/TWI is apparently not a very good
choice for those speeds.  My point is: we should allow the user to make those
engineering tradeoffs as necessary.


Mark M. Hoffman
mhoffman at lightlink.com

More information about the i2c mailing list