Wolfgang Grandegger <w...@denx.de> wrote on 21/09/2009 13:59:04: > > Joakim Tjernlund wrote: > > Wolfgang Grandegger <w...@denx.de> wrote on 21/09/2009 12:53:36: > >> Hi Joakim, > >> > >> Joakim Tjernlund wrote: > >>> The latest AN2919 has changed the way FDR/DFSR should be calculated. > >>> Update the driver according to spec. However, Condition 2 > >>> is not accounted for as it is not clear how to do so. > >> I compared rev. 5 of AN2919 with rev. 3 and, as you pointed out, it puts > >> additional constraints on how to select dfsr and fdr. Especially dfsr > >> should not exceed a certain, frequency dependent value: dfsr <= 50 / > >> period-in-ns. Therefore, I expected problems with divider values from > >> the table which high dfsr values. I did your "=> date;date;date;date" > >> test on a MPC8548 board using dfsr=43 and fdr=7 but it did not fail. > >> According to the rev. 5, dfsr is not allowed to be greater than 8. > >> Your patch works fine on this board as well. I have no time for a more > >> thorough testing with different CPUs and frequencies. Anyhow... > > > > Yes, I too notice that higher dfsr values than the spec says works, in > > fact my board needs at least dfsr 8 to be 100% stable but the spec says > > no more that 6 for my board. I suspect that we should enforce a minimum > > value of 8 to be on the safe side, especially as the HW default is 0x10. > > You say that the new constraints introduced by rev. 5 are not even > correct!? Well, these modifications are obscure anyhow.
My board has a higher rise time than the I2C spec(1 us) so it may be the reason for me. It *looks* like a higher dfsr makes the controller tolerate more "noise". Where does the dfsr=1 come from in the first place? It seems random and is very far from HW default. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
