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

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

[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/

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/

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/