[Linaro-mm-sig] [PATCH/RFC 0/8] ARM: DMA-mapping framework redesign

[Marek Szyprowski]

Hello,

On Wednesday, June 22, 2011 10:53 AM Subash Patel wrote:

> On 06/22/2011 12:29 PM, Marek Szyprowski wrote:
> > Hello,
> >
> > On Wednesday, June 22, 2011 6:53 AM Subash Patel wrote:
> >
> >> On 06/20/2011 01:20 PM, Marek Szyprowski wrote:
> >>> Hello,
> >>>
> >>> This patch series is a continuation of my works on implementing generic
> >>> IOMMU support in DMA mapping framework for ARM architecture. Now I
> >>> focused on the DMA mapping framework itself. It turned out that adding
> >>> support for common dma_map_ops structure was not that hard as I
> initally
> >>> thought. After some modification most of the code fits really well to
> >>> the generic dma_map_ops methods.
> >>>
> >>> The only change required to dma_map_ops is a new alloc function. During
> >>> the discussion on Linaro Memory Management meeting in Budapest we got
> >>> the idea that we can have only one alloc/free/mmap function with
> >>> additional attributes argument. This way all different kinds of
> >>> architecture specific buffer mappings can be hidden behind the
> >>> attributes without the need of creating several versions of dma_alloc_
> >>> function. I also noticed that the dma_alloc_noncoherent() function can
> >>> be also implemented this way with DMA_ATTRIB_NON_COHERENT attribute.
> >>> Systems that just defines dma_alloc_noncoherent as dma_alloc_coherent
> >>> will just ignore such attribute.
> >>>
> >>> Another good use case for alloc methods with attributes is the
> >>> possibility to allocate buffer without a valid kernel mapping. There
> are
> >>> a number of drivers (mainly V4L2 and ALSA) that only exports the DMA
> >>> buffers to user space. Such drivers don't touch the buffer data at all.
> >>> For such buffers we can avoid the creation of a mapping in kernel
> >>> virtual address space, saving precious vmalloc area. Such buffers might
> >>> be allocated once a new attribute DMA_ATTRIB_NO_KERNEL_MAPPING.
> >>
> >> Are you trying to say here, that the buffer would be allocated in the
> >> user space, and we just use it to map it to the device in DMA+IOMMU
> >> framework?
> >
> > Nope. I proposed an extension which would allow you to allocate a buffer
> > without creating the kernel mapping for it. Right now
> dma_alloc_coherent()
> > performs 3 operations:
> > 1. allocates memory for the buffer
> > 2. creates coherent kernel mapping for the buffer
> > 3. translates physical buffer address to DMA address that can be used by
> > the hardware.
> >
> > dma_mmap_coherent makes additional mapping for the buffer in user process
> > virtual address space.
> >
> > I want make the step 2 in dma_alloc_coherent() optional to save virtual
> > address space: it is really limited resource. I really want to avoid
> > wasting it for mapping 128MiB buffers just to create full-HD processing
> > hardware pipeline, where no drivers will use kernel mapping at all.
> >
> 
> I think by (2) above, you are referring to
> __dma_alloc_remap()->arm_vmregion_alloc() to allocate the kernel virtual
> address for the drivers use. That makes sense now.

Well, this is particular implementation which is used on ARM. Other 
architectures might implement it differently, that's why I used generic 
description and didn't point to any particular function.

> I have a query in similar lines, but related to user virtual address
> space. Is it feasible to extend these DMA interfaces(and IOMMU), to map
> a user allocated buffer into the hardware?

This can be done with the current API, although it may not look so 
straightforward. You just need to create a scatter list of user pages
(these can be gathered with get_user_pages function) and use dma_map_sg()
function. If the dma-mapping support iommu, it can map all these pages
into a single contiguous buffer on device (DMA) address space.

Some additional 'magic' might be required to get access to pages that are
mapped with pure PFN (VM_PFNMAP flag), but imho it still can be done.

I will try to implement this feature in videobuf2-dma-config allocator
together with the next version of my patches for dma-mapping&iommu.

Best regards
-- 
Marek Szyprowski
Samsung Poland R&D Center