linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Adrian Cox <adrian@humboldt.co.uk>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
Date: Thu, 03 May 2007 20:53:52 +1000	[thread overview]
Message-ID: <1178189632.6353.35.camel@localhost.localdomain> (raw)
In-Reply-To: <1178187440.20944.12.camel@localhost.localdomain>

On Thu, 2007-05-03 at 10:17 +0000, Adrian Cox wrote:
> On Wed, 2007-05-02 at 16:34 -0500, Jon Loeliger wrote: 
> > From: James.Yang <James.Yang@freescale.com>
> > 
> > Remove CPU_FTR_NEED_COHERENT for MPC7448 (and single-core MPC86xx).
> > This prevents needlessly setting M=1 when not SMP.
> 
> There may be side effects to removing this. Most of the 74xx processors
> had this flag added because of the L2 prefetch bug (erratum #16 on the
> 7447A). I see that bug is missing from the 7448 errata.
> 
> The problem is that many 32-bit PowerPC machines needed
> CPU_FTR_NEED_COHERENT set for a second reason: compatibility with the
> cache in the MPC107. This was handled by CPU_FTR_COMMON in cputable.h
> before the L2 prefetch bug was known.  There may be other host bridges
> that cache, but nobody will have noticed because all the CPUs had
> CPU_FTR_NEED_COHERENT set already.

There are a few options there...

The feature fixup and the hash table init are done after machine probe,
so the machine probe routine can do some last minute fixups of the
features, like detecting an MPC107 or whatever..

Another option would be to add a bit of generic code in
early_init_devtree() to detect the MPC107 and set that feature bit when
it's present, but that would involve having a consistent way to
recognize it via the device-tree which might not be the case currently
(though that only matters for 7448 based-boards so it's still doable).

Cheers,
Ben.

  reply	other threads:[~2007-05-03 10:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-02 21:34 [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448 Jon Loeliger
2007-05-03 10:17 ` Adrian Cox
2007-05-03 10:53   ` Benjamin Herrenschmidt [this message]
2007-05-03 16:13   ` Jon Loeliger
2007-05-03 17:07     ` Adrian Cox
2007-05-03 17:38       ` Jon Loeliger
2007-05-03 21:36     ` Benjamin Herrenschmidt
2007-05-04 15:16       ` Jon Loeliger
2007-05-04 22:25         ` Benjamin Herrenschmidt
2007-05-05 13:25           ` Adrian Cox
2007-05-07 17:31           ` Loeliger Jon-LOELIGER
2007-05-04 20:19   ` Kumar Gala
2007-05-03 11:02 ` Paul Mackerras
2007-05-03 16:04   ` Jon Loeliger
2007-05-03 23:34     ` Paul Mackerras
2007-05-04 15:13       ` Jon Loeliger
2007-05-10 16:17 ` Kumar Gala
2007-05-10 16:44   ` Jon Loeliger

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=1178189632.6353.35.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=adrian@humboldt.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).