From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Stanislawski Subject: Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring Date: Thu, 22 Mar 2012 17:18:53 +0100 Message-ID: <4F6B50ED.9020107@samsung.com> References: <5187420.ORugDzE4Gp@avalon> <4371520.a6RpvbKTp1@avalon> <4F6B2AE1.2030403@samsung.com> <13882403.dU5tE0PfxY@avalon> <4F6B3CA5.60404@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by gabe.freedesktop.org (Postfix) with ESMTP id E00A09EB24 for ; Thu, 22 Mar 2012 09:18:57 -0700 (PDT) Received: from euspt2 (mailout1.w1.samsung.com [210.118.77.11]) by mailout1.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0M1A0084TNYWZ4@mailout1.w1.samsung.com> for dri-devel@lists.freedesktop.org; Thu, 22 Mar 2012 16:18:33 +0000 (GMT) Received: from [106.116.48.223] by spt2.w1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0M1A00KRRNZG78@spt2.w1.samsung.com> for dri-devel@lists.freedesktop.org; Thu, 22 Mar 2012 16:18:52 +0000 (GMT) In-reply-to: <4F6B3CA5.60404@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Subash Patel Cc: kyungmin.park@samsung.com, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, sakari.ailus@iki.fi, Andrzej Pietrasiewicz , airlied@redhat.com List-Id: dri-devel@lists.freedesktop.org On 03/22/2012 03:52 PM, Subash Patel wrote: > Hi Laurent, > > On 03/22/2012 08:12 PM, Laurent Pinchart wrote: >> Hi Tomasz, >> >> On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote: >>> Hi Laurent, >>> Thank you very much for your comments and question. >>> They were very useful. >> >> You're welcome. >> >>> Please refer to the comments below. >>> >>> On 03/22/2012 11:50 AM, Laurent Pinchart wrote: >>>> On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote: >>>>> From: Tomasz Stanislawski >>>>> [snip] >>> The physical address is already present in buf->dma_addr, but it is only >>> valid if the device has no MMU. Notice that vb2-dma-contig possess no >>> knowledge if MMU is present for a given device. >> >> That's why buf->dma_addr can't be considered as a physical address. It's only >> useful in the device context. >> >>> The sg list is not going to be single-entry if the device is provided with >>> its own MMU. >> >> There's something I don't get then. vb2-dma-contig deals with physically >> contiguous buffers. The buffer is backed by physically contiguous pages, so >> the sg list should have a single entry. >> > I think at present, vb2-dma-contig is abused for any kind of memory allocation (continuous or not). Wouldnt it be good to have a > proper working setup for videobuf2-dma-sg instead? Driver which chooses to use continuous, shall assign vb2_queue->mem_ops = > vb2_dma_contig_memops. The devices which know they have a MMU backing can assign the same to vb2_dma_sg_memops. But as of now, > we try to use vb2_dma_contig_memops for all kind of operation. I have also done this mistake, and wish I repaired it and posted > it before :( > Hi Subash, At first, I do not think that vb2-dma-contig is abused for any kind of allocation. It is used only for DMA coherent contiguous mapping what is very close to vb2-dma-contig's original purpose. One thing has to be said loudly: "The driver does not need to and should not know if IOMMU is present or not." The DMA framework must know if device uses IOMMU or not. Reason: the memory is allocated, free, flushed, mapped only by DMA framework. Usage of vb2-dma-contig or vb2-dma-sg depends only on the way how the memory is configured into the device. Most of embedded devices use only buffer's start address and buffer size (often indirectly specified by width/height and format). It mean that device needs a buffer that is contiguous for its DMA engine. In such a case, the driver should ALWAYS use vb2-dma-contig. The DMA framework hidden deep in dma_alloc_coherent internals will deal with IOMMU configuration. I hope you find this information useful. Regards, Tomasz Stanislawski