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

David S. Miller (
Thu, 16 Aug 2001 06:08:42 -0700 (PDT)

From: Jens Axboe <>
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:

/* 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?

David S. Miller
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at