From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Grandegger Date: Tue, 15 Sep 2009 13:53:13 +0200 Subject: [U-Boot] fsl_i2c: increase I2C timeout values and make them configurable In-Reply-To: References: <4AA8FA18.20103@freescale.com> <4AA8FF3F.4010105@freescale.com> <4AA91AA5.3090707@freescale.com> <4AA9258F.8070402@freescale.com> <4AAA6ACD.9040905@free <4AAE55FA.4070702@freescale.com> Message-ID: <4AAF8029.4000504@grandegger.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Joakim Tjernlund wrote: >> Wolfgang Grandegger wrote: >> >>> I did not follow the thread yet, sorry. I implemented AN2819 for Linux >>> (see http://lxr.linux.no/#linux+v2.6.31/drivers/i2c/busses/i2c-mpc.c) >>> some time ago using Timur's table approach. But there is no difference >>> between the table and the algorithm to calculate the value. The table is >>> actually derived from the same algorithm. >> The problem with the table is that it does not allow for flexibility in >> choosing dfsr. When I implemented the table code, I did not think that this >> was a problem, but apparently it is. > > Yes, it is a problem for us as our board is out of spec. The rise time is way off > spec. By trial and error with the DFSR/FDR I managed to get a stable connection. > What is less funny though is that I need to program FDR/DFSR differently > in u-boot resp. kernel. to make it work. > I suspect it is due to kernel being IRQ driven and has longer pause > between chars, but it is a guess. > > In any case, the revised AN2819 dictates a different algorithm but I feel > it is a bit incomplete w.r.t Condition 2: > > ? Condition 2: B ? T ? tI2CRM + 3 ? C ? T. > Given a suitable value of DFSR, chosen to satisfy Condition 1, this inequality must also be met to guarantee > that the SCL frequency matches the SCL frequency calculated by the divider equation. It is important to > note that tI2CRM is the measured rise time of the SCL signal, which is defined as the time for the signal to > rise from 10% to 70% of VCC. > > NOTE > Note that the rise time must not exceed 300 nanoseconds and that the above > two conditions must both be satisfied to ensure that the actual SCL > frequency values align with the calculated values. By meeting these > conditions, the measured SCL frequency will match the calculated > frequency to within 5 kHz. Ignoring either of these conditions may result in > larger discrepancies between these frequency values. > > How important is Condition 2 and what to do with rise times > 300 ns? The MAX rise time > for 100 KHz is 1000 ns so there is a gap here. > > My testing suggests that this is not important. Bigger DFSR, in my case 0x6 or 0x10, is key > to get a stable I2C bus. > > Jocke > PS. > Wolfgang, I sent a test program to calculate the new DFSR/FDR values in the thread, you > might find it useful if you are going to try out the new AN2819 Where do I find this test program. I just dig out my program to calculate the table entries for the Linux i2c-mpc.c. It actually reproduced Timur's (old) U-Boot values. Unfortunately, finding *good* dfsr/fdr settings is no trivial and takes time. Till recently, the i2c-mpc driver of Linux did use *fixed* save values as shown here: http://lxr.linux.no/#linux+v2.6.29/drivers/i2c/busses/i2c-mpc.c And also with newer kernels, the table is only used if one of the following I2C DTS properties is defined: - fsl,preserve-clocking; - clock-frequency = <400000>; See http://lxr.linux.no/#linux+v2.6.31/Documentation/powerpc/dts-bindings/fsl/i2c.txt Wolfgang.