All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Cox <adrian@humboldt.co.uk>
To: Tom Rini <trini@kernel.crashing.org>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Caching in the MPC107, linux 2.6
Date: Mon, 15 Mar 2004 22:42:13 +0000	[thread overview]
Message-ID: <1079390532.1677.12.camel@newt> (raw)
In-Reply-To: <20040315203849.GA13167@smtp.west.cox.net>


On Mon, 2004-03-15 at 20:38, Tom Rini wrote:

> Actually, I was thinking that having an extra nop there on the !SMP &&
> !(745x && MPC107) case wouldn't hurt much / at all, and having this
> feature bit be done unconditionally.  But in cpu_setup_6xx.S we would
> compare the host bridge vendor / device ID to that of an mpc107.  Or am
> I not thinking right, and doing that comparison at that time would be a
> bad idea?  If so, I can live with it being an unconditional option, iff
> it's only required when MPC10X_STORE_GATHERING is enabled.

The only problem I see is that in cpu_setup_6xx.S we can't yet do the
config cycles to tell that it is an MPC107. Luckily, all MPC10x boards
that I know of require an explicit platform selection option.

I made my patch depend on CONFIG_MPC10X_BRIDGE, instead of
CONFIG_MPC10X_STORE_GATHERING, because I'm in the middle of porting
other MPC107 drivers from kernel 2.4 to 2.6.

An extra nop won't hurt, but there is a performance cost to
_PAGE_COHERENT which we should avoid unless necessary.

- Adrian Cox
http://www.humboldt.co.uk/


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2004-03-15 22:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-12 10:46 Caching in the MPC107, linux 2.6 Adrian Cox
2004-03-12 22:32 ` Tom Rini
2004-03-13 11:32   ` Adrian Cox
2004-03-13 17:07 ` Tom Rini
2004-03-15 20:03   ` Adrian Cox
2004-03-15 20:38     ` Tom Rini
2004-03-15 22:42       ` Adrian Cox [this message]
2004-03-15 22:48         ` Tom Rini
2004-03-16 18:06           ` Adrian Cox

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=1079390532.1677.12.camel@newt \
    --to=adrian@humboldt.co.uk \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=trini@kernel.crashing.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.