linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <bh40@calva.net>
To: <mlan@cpu.lu>
Cc: <paulus@linuxcare.com.au>, <linuxppc-dev@lists.linuxppc.org>
Subject: Re: PATCH: improved processor config for G3s
Date: Sun, 3 Sep 2000 15:43:03 +0200	[thread overview]
Message-ID: <20000903134303.2744@192.168.1.10> (raw)
In-Reply-To: <200009031303.PAA00901@piglet.grunz.lu>


>
> * Branch History Table (BHTE), Branch Target ICache (BTIC), Dynamic
>   Power Management (DPM) and Store Gathering (SGE) all on,
> * Instruction Cache Throttling Control (ICTC) off.
>
>These were not touched before, but might be worth a discussion:
>
> * Speculative Cache Access Disable (SPD) cleared, Address Brodcast
>   (ABE) enabled
>
>Clearing SPD makes sense since some processor upgrade cards come with an
>OF patch that sets this bit (due to ROM problems... we don't care once
>Linux is up).

There's a bit of history about ABE:

Originally, it was not set. At that time, I tried to turn ON the "Store
Gathering" option of the MPC 106 (grackle) host brigde. I left it a few
weeks in my kernel and began getting reports of problems, mostly with
Adaptec cards.

At that time, some apple person told me enabling Store Gathering on the
bridge was wrong, they had problems with it (various compatibility
issues), probably due to grackle bugs, but without telling me exactly
what was going on.

Later on, a Moto person told me there was no known grackle bug about
store gathering, but that the CPU ABE was needed for proper operations. I
also suspect that store gathering increase the effect of PCI write
posting, and older versions of the Adaptec drivers were not correctly
taking this into account on sime timing critical accesses.

I finally ended up setting ABE in head.S (along with a few others), but
never uncommented the call to grackle_set_stg() in pmac_pci.c. If someone
want to test if it behaves properly now (the problems reported at that
time were mostly with Adaptec cards in B&W G3s not initializing
properly), I don't have a Grackle-based machine here any more.

Ben.

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

  reply	other threads:[~2000-09-03 13:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-03 13:03 PATCH: improved processor config for G3s Michel Lanners
2000-09-03 13:43 ` Benjamin Herrenschmidt [this message]
2000-09-04  9:48   ` Gabriel Paubert
2000-09-04 10:34     ` Adrian Cox
2000-09-04 10:54       ` Benjamin Herrenschmidt
2000-09-05  9:49         ` Gabriel Paubert
2000-09-05 10:50           ` Benjamin Herrenschmidt
2000-09-05 11:06             ` Gabriel Paubert
2000-09-05 11:32           ` Adrian Cox
2000-09-04 17:51     ` Michel Lanners

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=20000903134303.2744@192.168.1.10 \
    --to=bh40@calva.net \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=mlan@cpu.lu \
    --cc=paulus@linuxcare.com.au \
    /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).