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

[Russell King <rmk@arm.linux.org.uk>]

On Tue, Mar 23, 2004 at 12:40:27PM +0000, Russell King wrote:
> On Tue, Mar 23, 2004 at 01:34:39PM +0100, Andrea Arcangeli wrote:
> > anyways Linus vetoed the lazy approch so we probably should give it up
> > (the one thing I like most is to avoid the branch in the fast path).
> 
> I don't think he did - he vetoed adding another special condition to
> the fast path, or returning non-RAM pages via ->nopage.
> 
> However, I do not believe he has vetoed an architecture implementing
> dma_coherent_mmap() in such a way that it uses the ->nopage method,
> _provided_ ->nopage returns valid struct pages.

Ok, since this thread seems to have died without much action happening,
its time to re-start it (but note - I probably won't be around tomorrow.)
I'd like to get the dma_coherent_mmap() API sorted out such that everyone
is happy, and we can progress it.

From what I've gathered, we seem to be happy with the dma_coherent_mmap()
approach.  Is everyone happy with these prototypes?

int dma_coherent_mmap(struct device *dev, struct vm_area_struct *vma,
                      void *cpu_addr, dma_addr_t dma_addr, size_t size);

and, for the PA-RISC architecture (c/o James Bottomley):

void dma_coherent_munmap(struct device *dev, struct vm_area_struct *vma,
			 void *cpu_addr, dma_addr_t dma_addr, size_t size);

where:

- dev: the device for which this coherent region was created for
- vma: VM area struct describing the requested user mapping
- cpu_addr: the address returned from dma_alloc_coherent
- dma_addr: the DMA cookie returned from dma_alloc_coherent
- size: the size of the DMA allocation

As far as ARM goes, we (currently) only need cpu_addr to look up the
data associated with the kernels coherent DMA mapping.  Whether the
other arguments are useful depends on what other architectures require.

Is everyone happy with the name, or would people prefer it to be more
consistent with the other dma_xxx_coherent() functions (iow,
dma_mmap_coherent?)


PS, one of my pet annoyances with the DMA API is that dma_alloc_coherent()
doesn't return/take some architecturally defined structure, and that
there aren't accessor macros like dma_cpu_addr() dma_device_addr().
This means that we end up carrying around several bits of data, which
may be the same on some architectures.  People objected to this in 2.4,
and we ended up adding that yucky "DECLARE_PCI_UNMAP_ADDR" stuff - which
may happen during 2.6 to the DMA API.  Adding these further APIs is just
making this mistake worse IMO.  It's really a 2.7 problem though.  And
yes, I've just talked people out of the prototypes I've proposed above.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core