Messages in this thread | | | From | "Van Maren, Kevin" <> | Subject | Re: With Daniel Phillips Patch | Date | Wed, 22 Aug 2001 20:06:21 -0500 |
| |
> 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/
| |