All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: joakim.tjernlund@transmode.se
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
	ben-linux@fluff.org, iws@ovro.caltech.edu
Subject: Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
Date: Thu, 18 Feb 2010 16:04:16 +0100 (CET)	[thread overview]
Message-ID: <2921453.1266505456809.JavaMail.ngmail@webmail09.arcor-online.net> (raw)

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 =3D 1000000 / i2c->real_clk + 1;
> > +
> > +   if (delay_val < 2)
> > +      delay_val =3D 2;
> > +
> > +   for (k =3D 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);
> > +   }
> >   }
>=20
> I am curious, didn't old method work with by just wrapping
> a for(k=3D9; k; k--) around it? How did the wave form look?

Sure does that work!  The waveform was somewhat "streched", mainly due to t=
he delays between some of the writeccr() calls which don't change the sda/s=
cl 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 k=
Hz 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 cou=
rse 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 w=
hich 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=
=FCr Sie: der neue Arcor.de-Newsletter!
Jetzt anmelden und einfach alles wissen: http://www.arcor.de/rd/footer.news=
letter

WARNING: multiple messages have this Message-ID (diff)
From: "Albrecht Dreß" <albrecht.dress-KvP5wT2u2U0@public.gmane.org>
To: joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org,
	iws-lulEs6mt1IksTUYHLfqkUA@public.gmane.org
Subject: Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery
Date: Thu, 18 Feb 2010 16:04:16 +0100 (CET)	[thread overview]
Message-ID: <2921453.1266505456809.JavaMail.ngmail@webmail09.arcor-online.net> (raw)

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

             reply	other threads:[~2010-02-18 15:04 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18 15:04 Albrecht Dreß [this message]
2010-02-18 15:04 ` [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery Albrecht Dreß
2010-02-18 17:14 ` Joakim Tjernlund
2010-02-18 17:14   ` Joakim Tjernlund
2010-02-18 17:41   ` Grant Likely
2010-02-18 17:41     ` Grant Likely
2010-02-18 18:07     ` Joakim Tjernlund
2010-02-18 18:07       ` Joakim Tjernlund
2010-02-18 18:45   ` Albrecht Dreß
2010-02-18 18:45     ` Albrecht Dreß
  -- strict thread matches above, loose matches on Subject: below --
2010-02-17 18:59 Albrecht Dreß
2010-02-17 18:59 ` Albrecht Dreß
2010-02-17 20:10 ` Grant Likely
2010-02-17 20:10   ` Grant Likely
2010-02-18  8:09 ` Joakim Tjernlund
2010-02-18  8:09   ` Joakim Tjernlund
2010-02-18  9:09   ` Albrecht Dreß
2010-02-18  9:09     ` Albrecht Dreß
2010-02-18 12:33     ` Joakim Tjernlund
2010-02-18 12:33       ` Joakim Tjernlund
2010-02-18 13:23 ` Joakim Tjernlund
2010-02-18 13:23   ` Joakim Tjernlund
2010-05-05 22:09 ` Ira W. Snyder
2010-05-05 22:09   ` Ira W. Snyder
2010-05-06 17:54   ` Albrecht Dreß
2010-05-06 17:54     ` Albrecht Dreß
2010-05-06 18:06     ` Grant Likely
2010-05-06 18:06       ` Grant Likely
2010-05-16 17:47       ` Albrecht Dreß
2010-05-16 17:47         ` Albrecht Dreß
2010-05-19 16:02         ` Grant Likely
2010-05-19 16:02           ` Grant Likely
2010-06-16 19:30           ` Albrecht Dreß
2010-06-16 19:30             ` Albrecht Dreß
2013-03-13  5:30 ` panpan2523

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2921453.1266505456809.JavaMail.ngmail@webmail09.arcor-online.net \
    --to=albrecht.dress@arcor.de \
    --cc=ben-linux@fluff.org \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=iws@ovro.caltech.edu \
    --cc=joakim.tjernlund@transmode.se \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.