[lkml]   [2001]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] zero-bounce highmem I/O
   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

 \ /
  Last update: 2005-03-22 12:57    [W:0.066 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site