Re: can device drivers return non-ram via vm_ops->nopage?

[Linus Torvalds]

On Sun, 21 Mar 2004, Jeff Garzik wrote:
> 
> That would be nice, though the reason I avoided remap_page_range() in 
> via82cxxx_audio is that it discourages S/G.  Because remap_page_range() 
> is easier and more portable, several drivers allocate one-big-area and 
> then create an S/G list describing individual portions of that area.

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, and it actually
_does_ have a "struct page" associated with it, and as such you can
happily return it from "nopage()". It's just that you had better be sure
that you find the page properly. Just doing a "virt_to_page()" doesn't do
it - you have to make sure to undo the mapping that was done for DMA
reasons.

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.

That might be the minimal fix, since it would basically involve:
 - change whatever offensive "virt_to_page()" calls into 
   "dma_map_to_page()".
 - implement "dma_map_to_page()" for all architectures.

Would that make people happy?

(Architectures that have cache coherency issues will obviously also have 
to set cache disable bits in the vma information, that's they broken 
architecture problem)

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/