[i2c] AT91 bus driver loses data
rln-i2c at arbetsmyra.dyndns.org
Thu Feb 8 14:38:14 CET 2007
> Check the archives for the linux-arm-kernel mailing list. There was
> a long discussion regarding TWI on the AT91 family of SoC a week or
> so ago. Look for keywords I2C, TWI and AT91.
Thanks, I think I found them.
> I re-wrote the i2c_at91 driver to be interrupt driven and to support
> slave mode on the AT91SAM9260. There is another simpler interrupt
> based version available as well. I can send you them if you want.
> It would be nice to see one these included in the AT91 patch or even
> better inserted into the linux kernel.
Yes please, if you can share your drivers I'd be much grateful.
> > -------------------------------------------------------------------
> > From: Ronny Nilsson <rln-i2c at arbetsmyra.dyndns.org>
> > Hi
> > I've found problems with the AT91 I2C driver I'd like to discuss.
> > I'm a user of the the Atmel AT91RM9200 cpu and just recently begun
> > using I2C. For small transfers it works quite OK, however, for
> > somewhat large transfers I've found the current driver to be
> > unreliable...
> > Explanation:
> > * The driver ain't using the full capacity of the hardware to
> > detect errors. Things like overruns and NACKs are silently ignored.
> > * The driver uses polling for receive and transmit. While this
> > works fine on an idle system it seems to create data loss on busy
> > ones. A board experiencing modest network load will spend a fair
> > amount of time servicing interrupts etc., which in turn make the
> > I2C driver to miss characters. (There is only a one byte buffer in
> > the HW). The cpu in those cases issue an error flag for
> > overrun/underrun, but since the driver ignore them the transferred
> > data is simply lost or become garbage.
> > * The cpu errata recommends using interrupts in favour of polling
> > for detecting the error flags mentioned above. Simply adding a
> > oneliner check unfortunately isn't enough.
> > Because of the small buffer (one byte) events should be serviced
> > quickly. I made a test shot of disabling cpu interrupts at some
> > critical sections in the driver which confirmed the explanations
> > above. Large I2C transfers work perfect with interrupts disabled.
> > Unfortunately the critical section is quite lengthy... I need about
> > 1.5 ms just for reading the time out of my RTC. Running that long
> > with interrupts disabled ain't a good solution.
> > I propose a redesign of the AT91 I2C driver. Using interrupts
> > instead of polling should enhance the reliability and lessen risk
> > of data loss. - Or, at least something should be done to detect
> > errors if/when they occur. I've searched the list archive for any
> > reason to why that approach wasn't adopted right from the start,
> > but failed to find one. Perhaps have I missed something? Are there
> > any
> > technical/political/other reason for *not* using an interrupt based
> > driver?
> > If you'd like I gladly help with the work.
> > Best Regards
> > /Ronny Nilsson
More information about the i2c