From: "Albrecht Dreß" <albrecht.dress@arcor.de>
To: iws@ovro.caltech.edu
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@lists.ozlabs.org,
ben-linux@fluff.org
Subject: Re: [PATCH/RFC 1/2] 5200: improve i2c bus error recovery
Date: Tue, 16 Feb 2010 21:14:00 +0100 (CET) [thread overview]
Message-ID: <1427337.1266351240290.JavaMail.ngmail@webmail08.arcor-online.net> (raw)
In-Reply-To: <20100216194922.GA27811@ovro.caltech.edu>
Hi Ira:
[snip]
> I see this exact hang on a MPC8349EA board. I poll my i2c sensors every
> 500ms, and it takes around 12 hours to produce a hang. The usual hang
> has (CF | BB) set, however I have seen a hang with just BB (only once so
> far in about 2 weeks).
>=20
> I think the fixup should be run on 8349 as well, if not all processors.
> I'm happy to test patches. I have a way to reliably trigger a lockup,
> using another master on the i2c bus.
See my other post - hopefully a new patch is ready tomorrow/Thursday...
[snip]
> > static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> > {
> > -=09writeccr(i2c, 0);
> > -=09udelay(30);
> > -=09writeccr(i2c, CCR_MEN);
> > -=09udelay(30);
> > -=09writeccr(i2c, CCR_MSTA | CCR_MTX);
> > -=09udelay(30);
> > -=09writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > -=09udelay(30);
> > -=09writeccr(i2c, CCR_MEN);
> > -=09udelay(30);
> > +=09if (i2c->real_clk =3D=3D 0) {
> > +=09=09writeccr(i2c, 0);
> > +=09=09udelay(30);
> > +=09=09writeccr(i2c, CCR_MEN);
> > +=09=09udelay(30);
> > +=09=09writeccr(i2c, CCR_MSTA | CCR_MTX);
> > +=09=09udelay(30);
> > +=09=09writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > +=09=09udelay(30);
> > +=09=09writeccr(i2c, CCR_MEN);
> > +=09=09udelay(30);
> > +=09} else {
> > +=09=09int k;
> > +=09=09u32 delay_val =3D 1000000 / i2c->real_clk + 1;
> > +
> > +=09=09if (delay_val < 2)
> > +=09=09=09delay_val =3D 2;
> > +
> > +=09=09for (k =3D 9; k; k--) {
> > +=09=09=09writeccr(i2c, 0);
> > +=09=09=09writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> > +=09=09=09udelay(delay_val);
> > +=09=09=09writeccr(i2c, CCR_MEN);
> > +=09=09=09udelay(delay_val << 1);
> > +=09=09}
> > +=09}
> > }
> > =20
>=20
> The old sequence has always un-hung the bus for me. Yours might be
> better. I'll try it next time the bus wedges up on me.
The easiest way to verify the /waveforms/ is to simply call the function so=
mewhere else (e.g. in a i2c write call), and then record SCK and SDA with a=
scope. I saw *huge* unnecessary delays in the original code, and by some =
creative interpretation of the (not very clear) 5200 data sheet I came to t=
he write's and delays above. If you have a scope, you might want to repeat=
the test with your '8349.
Best, 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: iws-lulEs6mt1IksTUYHLfqkUA@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
Subject: Re: [PATCH/RFC 1/2] 5200: improve i2c bus error recovery
Date: Tue, 16 Feb 2010 21:14:00 +0100 (CET) [thread overview]
Message-ID: <1427337.1266351240290.JavaMail.ngmail@webmail08.arcor-online.net> (raw)
In-Reply-To: <20100216194922.GA27811-lulEs6mt1IksTUYHLfqkUA@public.gmane.org>
Hi Ira:
[snip]
> I see this exact hang on a MPC8349EA board. I poll my i2c sensors every
> 500ms, and it takes around 12 hours to produce a hang. The usual hang
> has (CF | BB) set, however I have seen a hang with just BB (only once so
> far in about 2 weeks).
>
> I think the fixup should be run on 8349 as well, if not all processors.
> I'm happy to test patches. I have a way to reliably trigger a lockup,
> using another master on the i2c bus.
See my other post - hopefully a new patch is ready tomorrow/Thursday...
[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);
> > + if (i2c->real_clk == 0) {
> > + 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);
> > + } else {
> > + 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);
> > + }
> > + }
> > }
> >
>
> The old sequence has always un-hung the bus for me. Yours might be
> better. I'll try it next time the bus wedges up on me.
The easiest way to verify the /waveforms/ is to simply call the function somewhere else (e.g. in a i2c write call), and then record SCK and SDA with a scope. I saw *huge* unnecessary delays in the original code, and by some creative interpretation of the (not very clear) 5200 data sheet I came to the write's and delays above. If you have a scope, you might want to repeat the test with your '8349.
Best, 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
next prev parent reply other threads:[~2010-02-16 20:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-22 20:17 [PATCH/RFC 1/2] 5200: improve i2c bus error recovery Albrecht Dreß
2010-01-22 20:17 ` Albrecht Dreß
2010-01-25 4:06 ` Ben Dooks
2010-01-25 4:06 ` Ben Dooks
2010-01-25 20:21 ` Albrecht Dreß
2010-01-25 20:21 ` Albrecht Dreß
2010-02-16 19:31 ` Grant Likely
2010-02-16 19:31 ` Grant Likely
2010-02-16 20:02 ` Albrecht Dreß
2010-02-16 20:02 ` Albrecht Dreß
2010-02-16 19:49 ` Ira W. Snyder
2010-02-16 19:49 ` Ira W. Snyder
2010-02-16 20:14 ` Albrecht Dreß [this message]
2010-02-16 20:14 ` Albrecht Dreß
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=1427337.1266351240290.JavaMail.ngmail@webmail08.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=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.