Hi Joakim:

[snip]
> >   static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> >   {
> > -   writeccr(i2c, 0);
> > -   udelay(30);
> > -   writeccr(i2c, CCR_MEN);
> > -   udelay(30);
> > -   writeccr(i2c, CCR_MSTA | CCR_MTX);
> > -   udelay(30);
> > -   writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > -   udelay(30);
> > -   writeccr(i2c, CCR_MEN);
> > -   udelay(30);
> > +   int k;
> > +   u32 delay_val = 1000000 / i2c->real_clk + 1;
> > +
> > +   if (delay_val < 2)
> > +      delay_val = 2;
> > +
> > +   for (k = 9; k; k--) {
> > +      writeccr(i2c, 0);
> > +      writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > +      udelay(delay_val);
> > +      writeccr(i2c, CCR_MEN);
> > +      udelay(delay_val << 1);
> > +   }
> >   }
> 
> I am curious, didn't old method work with by just wrapping
> a for(k=9; k; k--) around it? How did the wave form look?

Sure does that work!  The waveform was somewhat "streched", mainly due to the 
delays between some of the writeccr() calls which don't change the sda/scl 
lines.  Unfortunately I didn't take shots from the scope.

However, for *one* cycle, the old code needed (only counting the udelay's) 150 
us.  For 9 cycles, it's 1.35 ms, which isn't really nice ;-).  At 375 kHz real 
clock rate, delay_val is 3, i.e. each cycle consumes 9 us, or 81 us for the 
whole fixup procedure.  If the clock is slower, the gain is of course a lot 
smaller, and at 20.5 kHz each cycle again needs 150 us...

My feeling is that the delays used in the old code are just "some" values which 
work for sure, to if you like, my change is basically optimisation...

BTW, related to your earlier question, I checked the timings recorded with the 
scope at 100 and at 20 kHz against the nxp's "I2C bus specification and user 
manual", rev. 03 - everything seems to be fine.

Thanks, Albrecht.

Immer auf dem Laufenden! Sport, Auto, Reise, Politik und Promis. Von uns für 
Sie: der neue Arcor.de-Newsletter!
Jetzt anmelden und einfach alles wissen: 
http://www.arcor.de/rd/footer.newsletter
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to