From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tomasz Stanislawski Subject: Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2 Date: Fri, 20 Apr 2012 14:25:01 +0200 Message-ID: <4F91559D.6060900@samsung.com> References: <1334332076-28489-1-git-send-email-t.stanislaws@samsung.com> <1334332076-28489-3-git-send-email-t.stanislaws@samsung.com> <13761406.oTf8ZzmZpQ@avalon> <4F9021FE.2070903@samsung.com> <4F907798.3000304@redhat.com> <4F912141.8060200@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-reply-to: Sender: linux-media-owner@vger.kernel.org To: =?UTF-8?B?UsOpbWkgRGVuaXMtQ291cm1vbnQ=?= Cc: Mauro Carvalho Chehab , Laurent Pinchart , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, airlied@redhat.com, m.szyprowski@samsung.com, kyungmin.park@samsung.com, sumit.semwal@ti.com, daeinki@gmail.com, daniel.vetter@ffwll.ch, robdclark@gmail.com, pawel@osciak.com, linaro-mm-sig@lists.linaro.org, hverkuil@xs4all.nl, subashrp@gmail.com List-Id: dri-devel@lists.freedesktop.org Hi Remi, On 04/20/2012 12:56 PM, R=C3=A9mi Denis-Courmont wrote: > On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski > wrote: >>> Am I understanding wrong or are you saying that you want to drop > userptr >>> from V4L2 API in long-term? If so, why? >> >> Dropping userptr is just some brainstorming idea. >> It was found out that userptr is not a good mean >> for buffer exchange between to two devices. >=20 > I can believe that. But I am also inclined to believe that DMABUF is > targetted at device-to-device transfer, while USERPTR is targetted at > device-to-user (or user-to-device) transfers. Are you saying applicat= ions > should use DMABUF and memory map the buffers? No. As I sad before: it is *too early* to drop userptr and expect appli= cation to use DMABUF and MMAPs only. This was just some hypothetical idea. DMABUF is dedicated for dev-dev transfers. However, looking at the cur= rent speed of appearances of DMABUF extensions it may be expected that one = day it starts supporting making DMA buffer from a user pointer. Currently there are already extensions for MMAP and cache synchronizati= on. Who know what will happen future versions. However these are only hypothetical issues. Or would you care to explain > how DMABUF addresses the problem space of USERPTR? Allowing to attach a DMABUF to some userptr using some new magic IOCTL. I think that sooner or later someone will find this feature useful. >=20 >> The USERPTR simplifies userspace code but introduce >> a lot of complexity problems for the kernel drivers >> and frameworks. >=20 > It is not only a simplification. In some cases, USERPTR is the only I= /O > method that supports zero copy in pretty much any circumstance. Only for devices that have its own IOMMU that can access system memory. Moreover the userptr must come from malloc or be a mmaped file. The other case are drivers that touch memory using CPU in the kernel space like VIVI or USB drivers. > When the user cannot reliably predict the maximum number of required = buffers, > predicts a value larger than the device will negotiate, or needs buff= ers to > outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not= =2E What does outlive STREAMOFF means in this context? Anyway, IMO allocation of the buffers at VIDIOC_REQBUFS was not the bes= t idea because it introduces an allocation overhead for negotiations of the nu= mber of the buffers. An allocation at mmap was to late. There is a need for = some intermediate state between REQBUFS and mmap. The ioctl BUF_PREPARE may = help here. Can you give me an example of a sane application is forced to negotiate= a larger number of buffers than it is actually going to use? >=20 > Now, I do realize that some devices cannot support USERPTR efficientl= y, > then they should not support USERPTR.=20 The problem is not there is *NO* device that can handle USERPTR reliabl= y. The can handle USERPTR generated by malloc or page cache (not sure). Memory mmaped from other devices, frameworks etc may or may not work. Even if the device has its IOMMU the DMA layer provides no generic way = to transform from one device to the mapping in some other device. It is done using platform-defendant hacks like extracting PFNs from map= pings, hack-forming them into struct pages or scatterlists, mapping it and hop= ing that the memory is not going to release it in some other thread. The only sure way is to copy data from userptr to MMAP buffer. But for those devices that can, it > seems quite a nice performance enhancement. The userptr has its niches were it works pretty well like Web cams or V= IVI. I am saying that if ever DMABUF becomes a good alternative for USERPTR than maybe we should consider encouraging dropping USERPTR in the new drivers as 'obsolete' feature and providing some emulation layer in lib= v4l2 for legacy applications. Regards, Tomasz Stanislawski