[U-Boot] fsl_i2c: increase I2C timeout values and make them configurable

[Joakim Tjernlund]

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