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.
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?
Best regards
Regards,
Subash
SISO-SLG
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
