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

[Andrea Arcangeli]

On Sat, Mar 20, 2004 at 04:15:38PM +0000, Russell King wrote:
> On Sat, Mar 20, 2004 at 04:57:39PM +0100, Andrea Arcangeli wrote:
> > > One of my current projects is fixing this crap in ALSA.
> > 
> > Do you agree it should be fixed by returning a PFN from ->nopage?
> 
> No.  How would you return the PFN from a remapped page?  It's far
> easier to provide an interface which returns the struct page* for
> the underlying pages, thusly:
> 
> static struct page *
> dma_coherent_to_page(struct device *dev, void *cpu_addr,
> 		     dma_addr_t handle, unsigned int offset)
> 
> And this is precisely what I would be working on if I weren't writing
> this mail. 8)
> 
> Take a moment to think about the problem.  We've allocated some memory
> for coherent DMA via the dma_alloc_coherent() interface.  At some point,

they're using MMIO pci space or it wouldn't catch my BUG_ON on x86.

The whole point is that it is non ram, if it would be ram, x86 couldn't
notice the virt_to_page, since the page_t would be in the range of the
mem_map_t and pfn_valid would be happy with it.

If it was dma_alloc_coherent it would return ram I think, not non-ram.

> we've had to get a struct page* in this allocator.  However, the
> allocator has had to do some architecture defined operations to provide
> coherent memory.
> 
> Only the architecture can translate the results from dma_alloc_coherent()
> back to a struct page* - which it needs to be able to do if
> dma_free_coherent() is going to work.
> 
> Therefore, what we need to do to solve the ALSA problem is require all
> architectures to provide dma_coherent_to_page() and make ALSA use that.

will this dma_coherent_to_page be allowed to run on a non-ram page?
It's pretty ugly to use page_t for non-ram. one can always convert with
a mul or div with sizeof(page_t) though. My point is that if you want to
allow stuff to deal with non-ram you must never have this stuff work
with page_t but it should work with pfn instead.
-
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/