All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: "'Rémi Denis-Courmont'" <remi@remlab.net>,
	"Tomasz Stanislawski" <t.stanislaws@samsung.com>,
	"'Laurent Pinchart'" <laurent.pinchart@ideasonboard.com>,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	airlied@redhat.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
Subject: Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2
Date: Mon, 23 Apr 2012 14:00:17 +0000	[thread overview]
Message-ID: <4F956071.1040702@redhat.com> (raw)
In-Reply-To: <056501cd2125$b286d5e0$179481a0$%szyprowski@samsung.com>

Em 23-04-2012 07:50, Marek Szyprowski escreveu:
> Hi Mauro,
> 
> On Friday, April 20, 2012 3:37 PM Mauro Carvalho Chehab wrote:
> 
> (snipped)
> 
>>>> So my rough-idea was to remove USERPTR support from kernel
>>>> drivers (if possible of course) and to provide an emulation
>>>> layer in the userspace code like libv4l2.
>>>>
>>>> Please note that it is only a rough idea. Just brainstorming :)
>>
>>> It is *too early* to start any discussion on this topic.
>>> Especially until DMABUF is mature enough to become a good
>>> alternative for userptr.
>>
>> Looking at the hole picture, dropping USERPTR would only make
>> sense if it is broken on dev2user (or user2dev) transfers.
>>
>> Dropping its usage on dev2dev transfers makes sense, after having
>> DMABUF implemented.
>>
>> Yet, if some userspace application wants to abuse of USERPTR in order
>> to use it for dev2dev transfer, there's not much that can be done at
>> Kernel level.
>>
>> It makes sense to put a big warn at the V4L2 Docs telling that this
>> is not officially supported and can cause all sorts of issues at
>> the machine/system.
> 
> Please note that all current drivers which use videobuf/videobuf2-dma-contig
> are able to use userptr memory access method only with physically contiguous
> memory. 

Yes.

> This means that in fact they work only buffers, which come from other
> devices and dev2dev transfers are the only possibility. malloc()ed memory
> buffers are rejected.

Fragmented buffers can be detected, at Kernel level, and VB/VB2 can refuse
a fragmented memory when the hardware doesn't support it. However, checking
if the buffer is fragmented is not a safe way to detect that the buffer will
be used by a dev2dev transfer.

If the buffers are allocated very soon just after boot time which malloc(),
or if they use some different way of allocating the buffers (like reducing the max
ram area addressed by the kernel or using CMU or a simila approach), it could be 
possible to use videobuf(1/2)-dma-contig for userptr with user2dev/dev2user
transfers. This is actually used on some cases where this is used (like where 
the capture device only supports contiguous buffers).

If, for some reason, the hardware doesn't support dev2dev transfers on a
reliable way, some other strategy should be used.

Regards,
Mauro

  reply	other threads:[~2012-04-23 14:00 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 15:47 [PATCH v4 00/14] Integration of videobuf2 with dmabuf Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 01/14] v4l: Add DMABUF as a memory type Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2 Tomasz Stanislawski
2012-04-16 23:25   ` Laurent Pinchart
2012-04-19 14:32     ` Tomasz Stanislawski
2012-04-19 20:36       ` Mauro Carvalho Chehab
2012-04-19 20:37       ` Mauro Carvalho Chehab
2012-04-20  8:41         ` Tomasz Stanislawski
2012-04-20 10:56           ` Rémi Denis-Courmont
2012-04-20 10:56             ` Rémi Denis-Courmont
2012-04-20 12:25             ` Tomasz Stanislawski
2012-04-20 13:03               ` Rémi Denis-Courmont
2012-04-20 13:03                 ` Rémi Denis-Courmont
2012-04-21 17:10                 ` Laurent Pinchart
2012-04-20 14:48               ` Mauro Carvalho Chehab
2012-04-20 13:36             ` Mauro Carvalho Chehab
2012-04-23  7:50               ` Marek Szyprowski
2012-04-23 14:00                 ` Mauro Carvalho Chehab [this message]
2012-04-13 15:47 ` [PATCH v4 03/14] v4l: vb2: add support for shared buffer (dma_buf) Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 04/14] v4l: vb: remove warnings about MEMORY_DMABUF Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 05/14] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 06/14] v4l: vb2-dma-contig: Remove unneeded allocation context structure Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 07/14] v4l: vb2-dma-contig: Reorder functions Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode Tomasz Stanislawski
2012-04-17  0:43   ` Laurent Pinchart
2012-04-17  0:43     ` Laurent Pinchart
2012-04-20  8:52     ` Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 09/14] v4l: vb2: add prepare/finish callbacks to allocators Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 10/14] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-17  0:57     ` Laurent Pinchart
2012-04-19 11:38     ` Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 12/14] v4l: vb2-dma-contig: change map/unmap behaviour for importers Tomasz Stanislawski
2012-04-17  1:03   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 13/14] v4l: s5p-tv: mixer: support for dmabuf importing Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 14/14] v4l: fimc: " Tomasz Stanislawski
2012-04-20 12:56   ` Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F956071.1040702@redhat.com \
    --to=mchehab@redhat.com \
    --cc=airlied@redhat.com \
    --cc=daeinki@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=pawel@osciak.com \
    --cc=remi@remlab.net \
    --cc=robdclark@gmail.com \
    --cc=subashrp@gmail.com \
    --cc=sumit.semwal@ti.com \
    --cc=t.stanislaws@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.