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

[David Woodhouse]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/