From: Gérard Roudier <groudier@free.fr>
Date: Wed, 22 Aug 2001 20:21:50 +0200 (CEST)
First, let me thank you a LLLOOOOOOTTTTT, David, for you PCI 64 bit
addressing DMA-mapping. I didn't have looked yet into your patch and
documentation update, but I will do so ASAP.
You're very welcome. :-)
OTOH, it is a great pleasure for me to hear that you didn't forget what I
told you about the current limitation of the SYM53C8XX driver. For now,
the driver would be only able to use 40 bit addresses with all upper bits
set to zero. This doesn't fit PCI 64 bit implementation of the Alpha
Monster window for example, and probably doesn't fit most other non-Intel
PCI 64 bit implementations.
It is fully known, in fact, I converted the sym53c8xx.c driver as
one of the examples in the patch.
Alpha can use it, in cases where memory in the system is less than
the addressing limitation of device.
Such logic would reside for Alpha port in pci_dac_cycles_ok()
definition. IA64 and x86 could act similarly. This was in fact
how I intended ports to implement pci_dac_cycles_ok().
But there is an alternate solution for the SYM53C8XX driver by using up to
16 x 32 bit segment registers. This would (will) allow to address for DMA
16 x 4GB segments with all upper bits being settable for each 4GB segment.
Note, it relies on no 4GB crossing every occuring. Jens and I have
decided that we will make this guarentee for devices always. I know
of 2 devices already which have problems with this (Qlogic,FC and some
buggy variants of Tigon3 chips).
I have this in my todo-list since months, but haven't had strong reasons
for implementing it. The strongest reasons would be that I had access to
64 bit machines with 64 bit PCI, but this isn't possible.
Look for someone to borrow a sparc64 system from. Or, alternatively
send the patch to me for testing.
On sparc64, you will always be "testing all the bits" since each
DAC address to physical memory has:
0xfffc000000000000
on the top bits.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:50 EST