From: Benjamin Herrenschmidt <bh40@calva.net>
To: Tony Mantler <eek@escape.ca>, linuxppc-dev@lists.linuxppc.org
Subject: Re: Performa 5200
Date: Thu, 26 Aug 1999 10:44:50 +0200 [thread overview]
Message-ID: <19990826104450.024993@mailhost.mipsys.com> (raw)
In-Reply-To: <v04003a00b3e9f623e46f@[216.81.27.143]>
On Wed, Aug 25, 1999, Tony Mantler <eek@escape.ca> wrote:
>I know the '040 maintains consistiency during the operation of alternate
>bus masters by snooping and spiking the bus according to what's in the
>cache. I haven't read up on how the PPC does it, but I would have expected
>it to be made code-level compatible with what the 040 does, atleast in
>these early PMacs.
I didn't check but someone (I think Paul) told me that snooping was not
done accross the PPC<->68k bus bridge used by those machines.
Note that I'm working on another cache-incoherent platform, and I'm
struggling with similar issues, I beleive we should manage to
"officialise" some vmalloc_uncached functions in the kernel for
cache-incoherent platforms (and define a standard way to tell a driver
it's running on a non-coherent machines). The current macros in io.h are
definitely not enough.
>
>Or something like that.
>
>Penguin collects a pile of LM globals and passes them in the bi struct, but
>most of those can be implied from the gestalt machine ID. Considering the
>number of NuBus PMacs, I don't think it would be terribly difficult to
>guess anything that's not passed in explicitly.
I think that's what MkLinux does.
>But, I shan't pay any note of it 'till *after* I get a kernel to boot. :)
Yep, of course ;-)
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
next prev parent reply other threads:[~1999-08-26 8:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-08-24 5:59 Performa 5200 Tony Mantler
1999-08-24 9:06 ` Benjamin Herrenschmidt
1999-08-24 13:29 ` Dave Weis
1999-08-24 18:05 ` David A. Gatwood
1999-08-24 21:21 ` Tony Mantler
1999-08-25 10:23 ` Benjamin Herrenschmidt
1999-08-25 19:59 ` Tony Mantler
1999-08-26 3:43 ` David A. Gatwood
1999-08-26 4:15 ` Tony Mantler
1999-08-26 4:38 ` David A. Gatwood
1999-08-26 6:41 ` Tony Mantler
1999-08-26 8:57 ` Benjamin Herrenschmidt
1999-08-26 18:11 ` David A. Gatwood
1999-08-26 8:44 ` Benjamin Herrenschmidt [this message]
1999-08-26 3:45 ` David A. Gatwood
1999-08-26 8:53 ` Benjamin Herrenschmidt
1999-08-26 8:01 ` Geert Uytterhoeven
1999-08-25 10:36 ` Hubert Figuiere
1999-08-26 8:03 ` Geert Uytterhoeven
1999-08-26 8:59 ` Benjamin Herrenschmidt
1999-08-24 17:38 ` David A. Gatwood
-- strict thread matches above, loose matches on Subject: below --
1999-08-26 8:52 Benjamin Herrenschmidt
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=19990826104450.024993@mailhost.mipsys.com \
--to=bh40@calva.net \
--cc=eek@escape.ca \
--cc=linuxppc-dev@lists.linuxppc.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.