From: Jens Axboe <axboe@suse.de>
Date: Thu, 16 Aug 2001 14:56:36 +0200
On Thu, Aug 16 2001, David S. Miller wrote:
> Enough babbling on my part, I'll have a look at your bounce patch
> later today. :-)
Wait for the next version, I'll clean up the PCI DMA bounce value
stuff first and post a new version.
Ok. I was thinking about the 4GB issue and we could describe it
simply using one platform macro define that could be boolean tested in
both your new block stuff and a fixed up version of the networking's
current ugly HIGHMEM tests.
/* PCI address are equivalent to memory physical addresses.
* As a consequence, the lower 4GB of main memory may be
* addressable using PCI single-address cycles. The rest of
* memory requires the use of dual-address cycles.
*
* If this is false, the kernel assumes that some hardware
* translation mechanism exists to allow all of physical
* memory to be accessed using single-address cycles.
*/
#define PCI_DMA_PHYS_IS_BUS (1)
So you'd get things like:
if (PCI_DMA_PHYS_IS_BUS) {
/* We might need to bounce this. */
if (! dev_dma_in_range(dev, address + len))
address = make_bounce_buffer(dev, address, len);
} else {
/* All physical memory is legal for DMA so there
* is nothing to check.
*/
}
or whatever. You get the idea.
This is really interesting because it means things like the following.
A device which is only capable of 32-bit PCI addressing can still just
use the pci_map_{single,sg}() interfaces yet DMA to all of system
memory. The block and networking layers will never try to bounce stuff.
Basically, this is what happens today with non-CONFIG_HIGHMEM
64-bit platforms, with a particular cost for the cases where
translation is done via bounce buffers (notably ia64).
What do you think?
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:15 EST