Re: DMA API issues

[Takashi Iwai <tiwai@suse.de>]

At Wed, 23 Jun 2004 13:34:23 +0100,
Russell King wrote:
> 
> On Tue, Jun 22, 2004 at 12:40:45PM +0200, Takashi Iwai wrote:
> > At Mon, 21 Jun 2004 20:26:39 -0700 (PDT),
> > Linus Torvalds wrote:
> > > 
> > > On Mon, 21 Jun 2004, Linus Torvalds wrote:
> > > > 
> > > > The argument at some point was that some architectures may not even _have_
> > > > a "struct page" for DMA memory, since it's not "normal" memory (ie "slow
> > > > memory" on m68k). However, I thought we all agreed that such a "struct
> > > > page" could be furnished if that architecture wants so support mmap'ing.
> > > 
> > > .. which is not to say that we shouldn't have a "pci_mmap_pages()" thing
> > > _too_. Pretty clearly the easiest interface often is to just map the pages
> > > at mmap() time, and then we should just have a helper function to do that. 
> > > 
> > > I thought we did one already, but hey, maybe not.
> > 
> > I don't think we have such.
> > 
> > Russell has once proposed a similar one (but not pci-specific), and I
> > believe it makes sense for many drivers.  We can hide the
> > architecture-specific cache handling inside the helper function, too.
> 
> Ok.  So does anyone have any objections if I push the ARM DMA mmap
> interface upstream, which consists of:
> 
> /**
>  * dma_mmap_coherent - map a coherent DMA allocation into user space
>  * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices
>  * @vma: vm_area_struct describing requested user mapping
>  * @cpu_addr: kernel CPU-view address returned from dma_alloc_coherent
>  * @handle: device-view address returned from dma_alloc_coherent
>  * @size: size of memory originally requested in dma_alloc_coherent
>  *
>  * Map a coherent DMA buffer previously allocated by dma_alloc_coherent
>  * into user space.  The coherent DMA buffer must not be freed by the
>  * driver until the user space mapping has been released.
>  */
> int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma,
>                       void *cpu_addr, dma_addr_t handle, size_t size);

This looks easy to use for me.


> and a similar one for the ARM-specific "write combining" case (for
> framebuffers utilising the DMA API)?

pgprot_noncached() is used on many other architectures in fbmem.c
(well, not really, but the result is identical).
Should it be provided as another one, or is it used as default in
dma_mmap_coherent()?

Also, it would be nice to have a version for sg-buffer, too.


Takashi