Re: [patch] zero-bounce highmem I/O

[David S. Miller]

   From: Jens Axboe <[e-mail]>
   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
[e-mail]