lkml.org 
[lkml]   [2012]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] i2c-at91: fix data-loss issue
Date
Hello,

we performed some measurements with the new version of the patch (v10),
in order to verify that the twi clock was performing better with the new
ternary operator introduced for the calculation of CLDIV & CHDIV.

However, we noticed we were using the wrongs resistors in our setup,
changing them to the correct ones, the driver gives us a frequency rate
of ~396kHz when we tweak the TWI_CLK_HZ to 400000. Using the previous
version the driver (without the specific offset for the AT91RM9200) it
gives a frequency rate of ~392kHz. Therefore, both rates are inside of
the error margin that the oscilloscope can give, so we suggest to keep
the latest code introduced for it, mostly because it behaves as the
datasheet claims.

On the other hand we found that the Underrun Error (UNRE) is not handled
in the driver. When we send data up > 2-4 bytes (quite random to say
when it really fails) and we add some dev_dbg() to print
dev->transfer_status we get 141 (==UNRE). According with the datasheet,
after the first UNRE received "this action automatically generated a
STOP bit in Master Mode. Reset by read in TWI_SR when TXCOMP is set."

We thought that one possibility for this was that the board was too slow
to process the requests or that other interrupts were interfering.
Disabling the interrupts inside of the twi interrupt handler did not
help either.

The datasheet does not mention any method to implement some mechanism to
avoid the UNRE telling the hardware to wait a bit longer for the next
byte. Thus, one way will be to restart the transfer with the remaining
bytes (maybe only applicable to at91rm9200) or just to return some
error/message to userland informing that could not send all the data.

Adrian



\
 
 \ /
  Last update: 2012-04-21 21:37    [W:0.062 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site