From: Michel Lanners <mlan@cpu.lu>
To: mknecht@controlnet.com
Cc: andreas.bombe@munich.netsurf.de, maxim@storagecraft.com,
ad@mpifr-bonn.mpg.de, linux1394-devel@eclipt.uni-klu.ac.at,
linuxppc-dev@lists.linuxppc.org
Subject: RE: [Linux1394-devel] Re: FireWire + Apple PB G3: some success
Date: Sat, 4 Mar 2000 11:30:30 +0100 (CET) [thread overview]
Message-ID: <200003041030.LAA00512@piglet.grunz.lu> (raw)
In-Reply-To: <F14842317963D111817100805F0DFE4D4FFF9A@server1.controlnet.com>
Hi all,
On 24 Feb, this message from Mark Knecht echoed through cyberspace:
> According to the LV23 spec the IO_ENB bit is read only, so one would presume
> that writing the a 1 to the IO_ENB ( I presume that this is what is actually
> happening with PCI_COMMAND_IO) would not cause any problems.
No idea here.... PCI_COMMAND_IO in general enables a PCI device to
listen (and maybe react) to IO cycles on the PCI bus.
> As for some of the performance issues, is the Memory Write and Invalidate
> bit in the same PCI register turned off or is it getting turned on? The
> default state is OFF.
On PowerMacs in general, OpenFirmware (the BIOS, if you prefer) should
set the Memory Write and Invalidate bit, as the Mac's PCI bus
implementation is optimised for these cycles. However....
> If not, then DMA writes from the OHCI controller could
> potentially be causing cache flushes and slowing the system down. I am
> presuming here that all or some of the memory addressed by OHCI is marked as
> cacheable which may or may not be the case...)
By default, all memory that is not real RAM is marked as
cache-inhibited. So, to get the maximum performance here, one has to
change cache settings on PCI space. However, I think that this means
you need to bother about cache coherency yourself, i.e. doing cache
flushes by hand. And that's beyond me...
Michel, sometimes working on PowerMac PCI issues
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2000-03-04 10:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-24 16:58 [Linux1394-devel] Re: FireWire + Apple PB G3: some success Mark Knecht
2000-02-24 19:21 ` Benjamin Herrenschmidt
2000-03-04 10:30 ` Michel Lanners [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-02-24 21:37 Mark Knecht
2000-02-23 10:24 Albrecht Dre_
2000-02-23 23:58 ` Andreas Bombe
2000-02-24 2:44 ` [Linux1394-devel] " Maxim S. Shatskih
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=200003041030.LAA00512@piglet.grunz.lu \
--to=mlan@cpu.lu \
--cc=ad@mpifr-bonn.mpg.de \
--cc=andreas.bombe@munich.netsurf.de \
--cc=linux1394-devel@eclipt.uni-klu.ac.at \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=maxim@storagecraft.com \
--cc=mknecht@controlnet.com \
/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).