From mboxrd@z Thu Jan 1 00:00:00 1970 From: Subash Patel Subject: Re: [Linaro-mm-sig] [PATCH/RFC 0/8] ARM: DMA-mapping framework redesign Date: Wed, 22 Jun 2011 14:23:15 +0530 Message-ID: <4E01AD7B.3070806@gmail.com> References: <1308556213-24970-1-git-send-email-m.szyprowski@samsung.com> <4E017539.30505@gmail.com> <001d01cc30a9$ebe5e460$c3b1ad20$%szyprowski@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pw0-f46.google.com ([209.85.160.46]:54697 "EHLO mail-pw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753364Ab1FVIxX (ORCPT ); Wed, 22 Jun 2011 04:53:23 -0400 Received: by pwj7 with SMTP id 7so464451pwj.19 for ; Wed, 22 Jun 2011 01:53:22 -0700 (PDT) In-Reply-To: <001d01cc30a9$ebe5e460$c3b1ad20$%szyprowski@samsung.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Marek Szyprowski Cc: linux-arm-kernel@lists.infradead.org, linaro-mm-sig@lists.linaro.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, 'Kyungmin Park' , 'Russell King - ARM Linux' , 'Joerg Roedel' , 'Arnd Bergmann' 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