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

[James Bottomley <James.Bottomley@SteelEye.com>]

On Mon, 2004-03-22 at 18:35, Jeff Garzik wrote:
> Agreed, but due to OSS dain bramage you can read/write as much as you 
> like, up until the mmap point, AFAICS.  It's much easier for the driver 
> to allocate one set of buffers, than to allocate a set at open(2), throw 
> away those allocs at mmap(2) and make new ones.

I didn't say throw the buffers away, merely the mapping.

I think you're looking at this the wrong way.  We only get into this
whole mess of being coherent with respect to a single address space if
we don't obey the virtual address congruence modulus rules

As Russell already pointed out, as long as we can force the virtual
addresses of the mappings (that's all mappings, in both the kernel and
in user space) to obey the congruence modulus rules then were home free.

On PA, we already force any mmapping that will be shared (MAP_SHARED) to
obey the congruence rules (we allocate them all at 0 mod 4MB, which is
our congruence modulus) by hijacking arch_get_unmapped_area.

Thus, as long as the sound card application designates its mappings as
MAP_SHARED, we're half way there.  The other wrinkle is that we'll have
to allocate the coherent memory *also* on a virtual address of 0 mod
4MB.  i.e. if we can be told *before* we hand out the coherent area that
it will be mmapped, we can make it work.  This is going to have to be an
extra flag to dma_alloc_coherent() or something.

The wrong thinking is that this is something we can fix at mapping time,
it's not, it's something we have to set up at buffer allocation time.

James