FireWire + Apple PB G3: some success

FireWire + Apple PB G3: some success

[Albrecht Dre_]

[I am new to the FireWire list, so please excuse me if this is not new for you.
Sorry, this is a quite long message]

I had some success with Newer Tech's FireWire2Go CardBus device on an Apple
PowerBook G3/333 (aka "Lombard") with LinuxPPC 2.2.14pre9.  This is what I did:

* added Ryuichi Oikawa patch to the kernel which enables the pci scan to "see"
CardBus devices without the PCMCIA package (there is a japanese description at
http://www.rr.iij4u.or.jp/~roikawa/others.html [which I can't read], but the
patch seems to work really fine)

* used the FireWire package for 2.2.14.  As always with LinuxPPC, I had to patch
the pcilynx driver, as OpenFirmware (Apple's "BIOS") does not activate all
devices automatically:

--- snip here -----------------------------------------------------------------
--- pcilynx.c.orig      Wed Feb 23 10:47:21 2000
+++ pcilynx.c   Wed Feb 23 10:52:33 2000
@@ -1212,6 +1212,7 @@
         struct ti_lynx *lynx; /* shortcut to currently handled device */
         unsigned long page;
         unsigned int i;
+       unsigned short w;

         if (num_of_cards == MAX_PCILYNX_CARDS) {
                 PRINT_G(KERN_WARNING, "cannot handle more than %d cards.  "
@@ -1225,7 +1226,8 @@
         lynx->id = num_of_cards-1;
         lynx->dev = dev;

-        pci_set_master(dev);
+       pci_read_config_word (dev, PCI_COMMAND, &w);
+       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER |
PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

         if (!request_irq(dev->irq, lynx_irq_handler, SA_SHIRQ,
                          PCILYNX_DRIVER_NAME, lynx)) {
--- patch ends here -----------------------------------------------------------

* `modprobe pcilynx' gives the following kernel messages:

kernel: ieee1394: registered pcilynx driver, initializing now
kernel: pcilynx: looking for PCILynx cards
kernel: pcilynx0: allocated interrupt 0
kernel: pcilynx0: allocated PCL memory 65536 Bytes @ 0xc12f0000
kernel: pcilynx0: remapped memory spaces reg 0xd8887000, rom 0xd88ab001, ram
0xd8889000, aux 0xd889a000
kernel: pcilynx0: found 1394a conform PHY (using extended register set)
kernel: pcilynx0: PHY vendor id 0x00c02d
kernel: pcilynx0: PHY product id 0x303562
kernel: pcilynx0: resetting bus on request
kernel: ieee1394: detected 1 pcilynx adapter

* remaining questions:

I have a FW disk attached to the bus, but when I run testlibraw, it is not seen:

[root@tirilap133 src]# ./testlibraw
successfully got handle
current generation number: 0
1 card(s) found
  nodes on bus:  0, card name: pcilynx
using first card found: 0 nodes on bus, local ID is 0

doing transactions with custom tag handler

using standard tag handler and synchronous calls
[root@tirilap133 src]#

Is this normal, or where ist the problem?

Thanks, Albrecht.


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Wed, Feb 23, 2000 at 11:24:36AM +0100, Albrecht Dreß wrote:
> I had some success with Newer Tech's FireWire2Go CardBus device on an Apple
> PowerBook G3/333 (aka "Lombard") with LinuxPPC 2.2.14pre9.  This is what I did:
>
> * added Ryuichi Oikawa patch to the kernel which enables the pci scan to "see"
> CardBus devices without the PCMCIA package (there is a japanese description at
> http://www.rr.iij4u.or.jp/~roikawa/others.html [which I can't read], but the
> patch seems to work really fine)

Nice.  So CardBus devices do act like normal PCI devices (except for
scanning, apparantly).

>          lynx->id = num_of_cards-1;
>          lynx->dev = dev;
>
> -        pci_set_master(dev);
> +       pci_read_config_word (dev, PCI_COMMAND, &w);
> +       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER |
> PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
>
>          if (!request_irq(dev->irq, lynx_irq_handler, SA_SHIRQ,
>                           PCILYNX_DRIVER_NAME, lynx)) {

I see.  That's the missing pci_enable_device() biting us.  But at least
in 2.2 there is no such function anyway, so it has to be done by hand.

> * `modprobe pcilynx' gives the following kernel messages:
>
[...]
> kernel: pcilynx0: resetting bus on request
> kernel: ieee1394: detected 1 pcilynx adapter

The messages for bus reset completion are missing, so it only works
partly.

> * remaining questions:
>
> I have a FW disk attached to the bus, but when I run testlibraw, it is not seen:

It's not seen because the driver is stuck in bus reset.  The most
probable reason is that DMA is not working.  I can't think of a reason
right now (since it does work on another PPC).

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

Re: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Maxim S. Shatskih]

> It's not seen because the driver is stuck in bus reset.  The most
> probable reason is that DMA is not working.  I can't think of a reason
> right now (since it does work on another PPC).

I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
config space is set?

    Max


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Thu, Feb 24, 2000 at 05:44:53AM +0300, Maxim S. Shatskih wrote:
> > It's not seen because the driver is stuck in bus reset.  The most
> > probable reason is that DMA is not working.  I can't think of a reason
> > right now (since it does work on another PPC).
>
> I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
> config space is set?

To quote Albert's patch:

 +       pci_read_config_word (dev, PCI_COMMAND, &w);
 +       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

He sets the PCI master flag (which should be the only thing disabling /
enabling DMA in general).  In the standard sources pci_set_master() is
used, which does the same.

Setting PCI_COMMAND_IO on the other hand is unneccessary since the
PCILynx only uses memory mapped I/O (if I understand PCI config
correctly).  I don't know if this flag is harmful if there are no I/O
ports.

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

RE: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Mark Knecht]

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.

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. 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...)

This may not be visible to something like 'top' because the cache flush it
is a hardware process in the processor and it is possible that the front
side bus gets bogged down with cache flush traffic.

-----Original Message-----
From: Andreas Bombe [mailto:andreas.bombe@munich.netsurf.de]
Sent: Thursday, February 24, 2000 8:17 AM
To: Maxim S. Shatskih
Cc: Albrecht Dreß; FireWire devel; LinuxPPC-Dev Liste
Subject: [Linux1394-devel] Re: FireWire + Apple PB G3: some success


On Thu, Feb 24, 2000 at 05:44:53AM +0300, Maxim S. Shatskih wrote:
> > It's not seen because the driver is stuck in bus reset.  The most
> > probable reason is that DMA is not working.  I can't think of a reason
> > right now (since it does work on another PPC).
>
> I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
> config space is set?

To quote Albert's patch:

 +       pci_read_config_word (dev, PCI_COMMAND, &w);
 +       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER |
PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

He sets the PCI master flag (which should be the only thing disabling /
enabling DMA in general).  In the standard sources pci_set_master() is
used, which does the same.

Setting PCI_COMMAND_IO on the other hand is unneccessary since the
PCILynx only uses memory mapped I/O (if I understand PCI config
correctly).  I don't know if this flag is harmful if there are no I/O
ports.

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44


_______________________________________________
Linux1394-devel maillist  -  Linux1394-devel@eclipt.uni-klu.ac.at
http://eclipt.uni-klu.ac.at/mailman/listinfo/linux1394-devel

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

Re: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Benjamin Herrenschmidt]

On Thu, Feb 24, 2000, Mark Knecht <mknecht@controlnet.com> wrote:

>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.
>
>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. 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...)

Hum... I didn't check the driver, but correct handling of cache coherency
issues is not very familiar to most Linux drivers. So I would suggest
sticking with invalidate. Note that I think the bridge will handle
coherency in all cases anyway.

>This may not be visible to something like 'top' because the cache flush it
>is a hardware process in the processor and it is possible that the front
>side bus gets bogged down with cache flush traffic.

Hum, the RAM/cache bus is way much faster than the PCI and in the case of
writes with invalidate, the destination datas is just killed from the CPU
cache, not actually flushed, so this should not cause a significant
performance impact.


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

RE: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Mark Knecht]

<snip..>

>This may not be visible to something like 'top' because the cache flush it
>is a hardware process in the processor and it is possible that the front
>side bus gets bogged down with cache flush traffic.

Hum, the RAM/cache bus is way much faster than the PCI and in the case of
writes with invalidate, the destination datas is just killed from the CPU
cache, not actually flushed, so this should not cause a significant
performance impact.

<end snip..>

Actually this is exactly the purpose of the MWI invalidate command in PCI.
With this feature turned off, which is the TI default, anytime the PCI bus
presents the chipset with a cacheable address the cache lines are written
back into memory before the chipset lets the OHCI DMA controller write data
to memory, so it can impact performance, sometimes quite a lot.

However, if the feature is turned on, then the chipset tells the processor
to simply invalidate the cache line internally because the PCI controller is
going to take responsibility for writing the complete cache line in memory.
There would be no purpose to flushing the cache line and then writing over
it in memory, and bus bandwidth is saved.

The bus in question here isn't necessarily the cache bus, but is the
front-side bus on the processor hooking to the chipset. On systems with
shallow posting PCI FIFOs this can be a pretty big impact if you are talking
about transfers of 100's of bytes. On newer chipsets with deeper
write-posting FIFOs it may not be a big deal.

None of this makes any difference if the buffers in memory are not
cacheable. How are buffers allocated in Linux? Are they cacheable? (I'm a
hardware guy and wouldn't know that part of the C-code if it walked up and
said hi!)


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

Re: FireWire + Apple PB G3: some success

[Albrecht Dre_]

[sorry for the late answer, was out for a few days...]

Andreas Bombe wrote:
> Setting PCI_COMMAND_IO on the other hand is unneccessary since the
> PCILynx only uses memory mapped I/O (if I understand PCI config
> correctly).  I don't know if this flag is harmful if there are no I/O
> ports.

I don't think that writing a read-only bit will cause any problem.

You told me earlier that the PCILynx was stuck in bus reset, because DMA seems
not to work.  Does DMA signal success/completition by interrupt?  Then this
might be a problem with the CardBus Bridge and/or interrupts.  "lspci -vv" tells
me for the PCILynx

01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
Layer Controller (rev 04) (prog-if 00 [Generic])
        Subsystem: Texas Instruments: Unknown device 8000
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 1 min, 2 max, 32 set, cache line size 20
        Interrupt: pin A routed to IRQ 0
        Region 0: Memory at 90030000 (32-bit, non-prefetchable)
        Region 1: Memory at 90000000 (32-bit, non-prefetchable)
        Region 2: Memory at 90010000 (32-bit, non-prefetchable)
        Expansion ROM at 90020000

I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
not count ANY irq's on this line.  The same information for the Cardbus bridge
is-

00:13.0 CardBus bridge: Texas Instruments: Unknown device ac1e
        Subsystem: Texas Instruments: Unknown device ac1e
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 set, cache line size 08
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at 80880000 (32-bit, non-prefetchable)
        Bus: primary=00, secondary=01, subordinate=04, sec-latency=64
Memory window 0: 90000000-90031000
        I/O window 0: 00000000-00000003
        I/O window 1: 00000000-00000003
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0007

Any cardbus/pci gurus out there?

Thanks, Albrecht.


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Mon, Feb 28, 2000 at 01:59:14PM +0100, Albrecht Dreß wrote:
> [sorry for the late answer, was out for a few days...]
>
> Andreas Bombe wrote:
> > Setting PCI_COMMAND_IO on the other hand is unneccessary since the
> > PCILynx only uses memory mapped I/O (if I understand PCI config
> > correctly).  I don't know if this flag is harmful if there are no I/O
> > ports.
>
> I don't think that writing a read-only bit will cause any problem.
>
> You told me earlier that the PCILynx was stuck in bus reset, because DMA seems
> not to work.  Does DMA signal success/completition by interrupt?

Yes, I forgot that possibility.

> Then this
> might be a problem with the CardBus Bridge and/or interrupts.  "lspci -vv" tells
> me for the PCILynx
>
> 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
> Layer Controller (rev 04) (prog-if 00 [Generic])
>         Subsystem: Texas Instruments: Unknown device 8000
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 1 min, 2 max, 32 set, cache line size 20
>         Interrupt: pin A routed to IRQ 0
>         Region 0: Memory at 90030000 (32-bit, non-prefetchable)
>         Region 1: Memory at 90000000 (32-bit, non-prefetchable)
>         Region 2: Memory at 90010000 (32-bit, non-prefetchable)
>         Expansion ROM at 90020000
>
> I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
> not count ANY irq's on this line.

I think we found the guilty party (if IRQ 0 isn't a valid IRQ on PPCs).
You could try to use setpci to configure another IRQ, probably 22
because the CardBus bridge (also using pin A) uses this too, but I
don't know PCI internals well enough to know if this is required.

The question remains why it didn't get an IRQ assigned (either BIOS
(probably not on Mac) or Linux should do this).

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

Re: FireWire + Apple PB G3: some success

[Ryuichi Oikawa]

From: Albrecht Dreß <ad@mpifr-bonn.mpg.de>
Subject: Re: FireWire + Apple PB G3: some success
Date: Mon, 28 Feb 2000 13:59:14 +0100
Message-ID: <38BA7122.44C833A9@mpifr-bonn.mpg.de>

> 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
> Layer Controller (rev 04) (prog-if 00 [Generic])
>         Subsystem: Texas Instruments: Unknown device 8000
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 1 min, 2 max, 32 set, cache line size 20
>         Interrupt: pin A routed to IRQ 0
                                     ^^^^^^
>         Region 0: Memory at 90030000 (32-bit, non-prefetchable)
>         Region 1: Memory at 90000000 (32-bit, non-prefetchable)
>         Region 2: Memory at 90010000 (32-bit, non-prefetchable)
>         Expansion ROM at 90020000
>
> I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
> not count ANY irq's on this line.  The same information for the Cardbus bridge
> is-
>
> 00:13.0 CardBus bridge: Texas Instruments: Unknown device ac1e
                                                            ^^^^

>         Subsystem: Texas Instruments: Unknown device ac1e
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32 set, cache line size 08
>         Interrupt: pin A routed to IRQ 22
>         Region 0: Memory at 80880000 (32-bit, non-prefetchable)
>         Bus: primary=00, secondary=01, subordinate=04, sec-latency=64
> Memory window 0: 90000000-90031000
>         I/O window 0: 00000000-00000003
>         I/O window 1: 00000000-00000003
>         BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
>         16-bit legacy interface ports at 0007

Have you checked if the patch you used is really working correctly?
It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
You will have to add support for your CardBus bridge(ID 0xac1e)
referring the document from TI.

Regards,


Ryuichi Oikawa
roikawa@rr.iij4u.or.jp

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

Re: FireWire + Apple PB G3: some success

[Benjamin Herrenschmidt]

On Wed, Mar 1, 2000, Ryuichi Oikawa <roikawa@rr.iij4u.or.jp> wrote:

>Have you checked if the patch you used is really working correctly?
>It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
>and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
>You will have to add support for your CardBus bridge(ID 0xac1e)
>referring the document from TI.

ac1e is the TI-1211. This is the same CardBus chip used in the new Pismo
powerbook. It's datasheet can be found on TI web site with the complete
register set.

BTW. I didn't find register infos in the datasheet for the TI-1131. Do
you have those ? I'd be interested. I found only the pinout and
electrical specs.


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

Re: FireWire + Apple PB G3: some success

[Albrecht Dre_]

Ryuichi Oikawa wrote:
> Have you checked if the patch you used is really working correctly?
> It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
> and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
> You will have to add support for your CardBus bridge(ID 0xac1e)
> referring the document from TI.

I also found that problem as I could not see the pcibios_fixup kernel message in
the logs...

As Ben already said, it it TI's PCI1211.  Although the data sheet states that
the two registers you alter with your patch (0x91 and 0x91) are "...provided for
PCI1130 campatibility", just adding the signature to activate the setup does not
work.

Unfortunately I do not have a card for which I know for sure that it will work
with LinuxPPC.  In the meantime I tested so many different combinations of
with/without your patch, with/without the PCMCIA package ver. 3.0.something/
3.1.something enables/diabled and an Adaptec SCSI CardBus Card/FireWire2Go
CardBus card (and got all sorts of nasty reactions like freezes and panics) that
I am a litte confused now.  I am afraid I have to try a more systematic
approach, and to read TI's docs first.

Anyway, thanks a lot for your help!

Yours, Albrecht.


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

Re: FireWire + Apple PB G3: some success

[Ryuichi Oikawa]

From: Benjamin Herrenschmidt <bh40@calva.net>
Subject: Re: FireWire + Apple PB G3: some success
> BTW. I didn't find register infos in the datasheet for the TI-1131. Do
> you have those ? I'd be interested. I found only the pinout and
No, I didn't find any register information except application report
on interrupts(I'll send it to you if necessary, which is just a 115K PDF)
probably because it is obsolete. But you can find it in the pcmcia-cs
package, whose auther may have a document(though I'm not quite sure).

BBTW, I'm new in the MOL source and I need some information/explanation.
Today I tried to add RageLTPro OF properties to MOL oftree.nw,
insert it into the pci device tree and mmu map full 16MB aperture
in thw video driver(on PB G3). I could run the drawing engine within
MacOS manually, but ATI's extension didn't seem to recognize the chip
at all. I even tried to load & insert into the driver properties field
the driver extracted from ATI Driver update file, but no success.
I don't understand MOL interface mechanism yet(and unfortunately
my macos complier, symantec c++ doesn't work on recent system).

What is the correct way to accelerate MOL video?

Thanks,

Ryuichi Oikawa
roikawa@rr.iij4u.or.jp

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

RE: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Michel Lanners]

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/