Messages in this thread | | | Subject | Re: can device drivers return non-ram via vm_ops->nopage? | From | David Woodhouse <> | Date | Mon, 22 Mar 2004 00:02:55 +0000 |
| |
On Sun, 2004-03-21 at 15:51 -0800, Linus Torvalds wrote: > Note that there is really two different kinds of IO memory: > - real IO-mapped memory on the other side of a bus > - real RAM which is on the CPU side of the bus, but that has additionally > been "mapped" some way as to be visible from devices. > > The second kind is what you seem to be talking about,
<...>
> So the minimal fix for any misuses would be to just have a > "dma_map_to_page()" reverse mapping for "dma_alloc_coherent()". For x86, > that's just the same thing as "virt_to_page()". For others, you have to > look more carefully at undoing whatever mapping the iommu has been set up > for.
You are assuming that dma_alloc_coherent() will always return memory of that second kind -- host-side RAM, not PCI-side. That hasn't previously been a requirement, and there are machines out there on which it makes a lot more sense for dma_alloc_coherent() to use some SRAM which happens to be hanging off the I/O bus than it does to use host RAM.
Doing dma_map_to_pfn() instead of dma_map_to_page() would work. That means you can't use nopage() for mappings of dma_coherent memory. That's fine though.
> Would that make people happy?
No. It'd be OK if you make it dma_map_to_pfn() instead of dma_map_to_page() though. As discussed, that means you can't use nopage() for mappings of dma_coherent memory. That's fine though.
I think it would be better to provide arch-specific functions for mapping dma_coherent allocations and SG lists. On most architectures we can just do it with virt_to_page() and nopage() and it'll be OK. On others we can do the right thing as appropriate.
-- dwmw2
- 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/
| |