From: Matt Sealey <matt@genesi-usa.com>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: linuxppc-dev@ozlabs.org, "René Bürgel" <r.buergel@unicontrol.de>
Subject: Re: [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state)
Date: Tue, 04 Nov 2008 12:18:36 -0600 [thread overview]
Message-ID: <491091FC.4010707@genesi-usa.com> (raw)
In-Reply-To: <20081103221546.GA16244@pengutronix.de>
Wolfram Sang wrote:
> On Mon, Nov 03, 2008 at 03:57:09PM -0600, Matt Sealey wrote:
>
>>> Optionally you can further
>>> reduce impact by checking if CONFIG_PPC_MPC5200_BUGFIX is defined.
>> I would much prefer this.
>
> I submitted a patch to enable pipelining on a MPC5200B recently. It was
> disabled because of a bug in the MPC5200. The first version of this
> patch used MPC5200_BUGFIX and it was mentioned, that some people might
> want to run the same kernel on both kind of processors. So, the patch
> that went mainline checks for the PVR. Maybe we should stick to this
> here, too?
I would wrap a real chipset errata inside CONFIG_PPC_MPC5200_BUGFIX so
that you have the option to remove all code that fixes these errata, but
also check the PVR and only do the bugfix if you're on that processor,
so.. both :D
The pipelining thing seems to be fixed in the MPC5200B but it actually
makes the bus lock up under certain circumstances with the ATA DMA
task and certain priority selections. I am not sure what we're going
to do about that pipelining support (Tim Yamin's patch removed it! Maybe
we should have a little addition to the BestComm driver which can set
these things from the driver side using a little global API, so that
if an ATA driver loads and wants this configuration, it can get to it)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
next prev parent reply other threads:[~2008-11-04 18:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-03 19:32 [PATCH] workaround for mpc52xx erratum #364 (serial may not be reset in break state) René Bürgel
2008-11-03 20:55 ` Grant Likely
2008-11-03 21:57 ` Matt Sealey
2008-11-03 22:15 ` Wolfram Sang
2008-11-03 22:55 ` Grant Likely
2008-11-04 18:18 ` Matt Sealey [this message]
2008-11-04 10:43 ` [PATCH V2] " René Bürgel
2008-11-04 11:15 ` Wolfram Sang
2008-11-04 14:13 ` René Bürgel
2008-11-04 19:40 ` [PATCH V3] " René Bürgel
2008-11-04 21:21 ` Wolfram Sang
2008-11-06 8:11 ` [PATCH V4] " René Bürgel
2008-11-06 8:11 ` René Bürgel
2008-11-14 19:09 ` Grant Likely
2008-11-14 19:09 ` Grant Likely
2008-11-04 18:23 ` [PATCH V2] " Matt Sealey
2008-11-06 17:01 ` René Bürgel
2008-11-06 22:41 ` Matt Sealey
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=491091FC.4010707@genesi-usa.com \
--to=matt@genesi-usa.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=r.buergel@unicontrol.de \
--cc=w.sang@pengutronix.de \
/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.