linuxppc-dev.lists.ozlabs.org archive mirror
 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 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).