> Can you enumerate the devices that actually issue a DAC when loaded with
> 64bit address with 0's in the most significant 32bits?
There had better not be any. It is a violation of the PCI specification
to generate a DAC if the address fits in 32 bits.
DAC is a LOT faster and more efficient than a copy (except perhaps for the
very smallest of transfers, which are already very inefficient).
The problem is that (for most hardware) the 64-bit descriptors take up more
room (and hence more PCI cycles to transfer) than the 32-bit descriptors,
especially with a 32-bit bus. [Apparently not the case for the 39-bit
AIC7xxx driver, but it is the case for the 64-bit Adaptec.] So unless
there is the possibility of using 64-bit DMA, you want to use the smaller
descriptors. So on systems with <= 32bits of memory/dma_addr_t, the driver
should be able to "know" that it should use the smaller descriptors for
efficiency.
I also believe that a dma_addr_t should be determined by the system, not the
driver: the driver should indicate constraints and the OS should ensure that
the dma_addr_t it provides meets the constraints. Separate 32-bit and
64-bit
DMA routines adds unnecessary complication. As far as I can tell, the only
reason to have separate APIs is so that 32bit machines with 64 bit DMA
addresses (PAE on ia32) can avoid copying around an "extra" 32bits of
address for the drivers that don't support 64-bit DMA. I think it makes
more sense to just make the dma_addr_t 64 bits on ia32 if using PAE and
deal with the insignificant "waste" -- you have > 4GB RAM :-)
Kevin Van Maren
-
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:52 EST