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

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