On Wed, Jul 14, 2010 at 09:34:03PM +0200, Joerg Roedel wrote: > On Mon, Jul 12, 2010 at 10:21:05PM -0700, Zach Pfeffer wrote: > > Joerg Roedel wrote: > > > > The DMA-API already does this with the help of IOMMUs if they are > > > present. What is the benefit of your approach over that? > > > > The grist to the DMA-API mill is the opaque scatterlist. Each > > scatterlist element brings together a physical address and a bus > > address that may be different. The set of scatterlist elements > > constitute both the set of physical buffers and the mappings to those > > buffers. My approach separates these two things into a struct physmem > > which contains the set of physical buffers and a struct reservation > > which contains the set of bus addresses (or device addresses). Each > > element in the struct physmem may be of various lengths (without > > resorting to chaining). A map call maps the one set to the other. > > Okay, thats a different concept, where is the benefit? The benefit is that virtual address space and physical address space are managed independently. This may be useful if you want to reuse the same set of physical buffers, a user simply maps them when they're needed. It also means that different physical memories could be targeted and a virtual allocation could map those memories without worrying about where they were. This whole concept is just a logical extension of the already existing separation between pages and page frames... in fact the separation between physical memory and what is mapped to that memory is fundamental to the Linux kernel. This approach just says that arbitrary long buffers should work the same way. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
