From: Vincent ABRIOU <vincent.abriou@st.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
Hugues FRUCHET <hugues.fruchet@st.com>,
Jean Christophe TROTIN <jean-christophe.trotin@st.com>
Subject: Re: [media] uvcvideo: support for contiguous DMA buffers
Date: Wed, 11 Jan 2017 12:36:24 +0000 [thread overview]
Message-ID: <45eec54c-059e-86c1-bedb-78a6400328a4@st.com> (raw)
In-Reply-To: <20170111110350.GE10831@valkosipuli.retiisi.org.uk>
Hi Sakari,
On 01/11/2017 12:03 PM, Sakari Ailus wrote:
> Hi Vincent,
>
> On Mon, Jan 09, 2017 at 03:49:00PM +0000, Vincent ABRIOU wrote:
>>
>>
>> On 01/09/2017 04:37 PM, Laurent Pinchart wrote:
>>> Hi Vincent,
>>>
>>> Thank you for the patch.
>>>
>>> On Monday 03 Oct 2016 13:27:16 Vincent Abriou wrote:
>>>> Allow uvcvideo compatible devices to allocate their output buffers using
>>>> contiguous DMA buffers.
>>>
>>> Why do you need this ? If it's for buffer sharing with a device that requires
>>> dma-contig, can't you allocate the buffers on the other device and import them
>>> on the UVC side ?
>>>
>>
>> Hi Laurent,
>>
>> I need this using Gstreamer simple pipeline to connect an usb webcam
>> (v4l2src) with a display (waylandsink) activating the zero copy path.
>>
>> The waylandsink plugin does not have any contiguous memory pool to
>> allocate contiguous buffer. So it is up to the upstream element, here
>> v4l2src, to provide such contiguous buffers.
>
> Do you need (physically) contiguous memory?
>
Yes, drm driver that does not have mmu needs to have contiguous buffers.
> The DMA-BUF API does help sharing the buffers but it, at least currently,
> does not help allocating memory or specifying a common format so that all
> the devices the buffer needs to be accessible can actually make use of it.
>
> Instead of hacking drivers to make use of different memory allocation
> strategies required by unrelated devices, we should instead fix these
> problems in a proper, scalable way.
>
Scalable way? Like central allocator?
Vincent
next prev parent reply other threads:[~2017-01-11 12:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-03 11:27 [media] uvcvideo: support for contiguous DMA buffers Vincent Abriou
2016-11-03 12:58 ` Vincent ABRIOU
2017-01-09 15:37 ` Laurent Pinchart
2017-01-09 15:49 ` Vincent ABRIOU
2017-01-09 16:59 ` Laurent Pinchart
2017-01-10 8:55 ` Vincent ABRIOU
2017-01-10 14:41 ` Laurent Pinchart
2017-01-10 14:53 ` Vincent ABRIOU
2017-01-11 11:03 ` Sakari Ailus
2017-01-11 12:36 ` Vincent ABRIOU [this message]
2017-01-25 11:46 ` Sakari Ailus
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=45eec54c-059e-86c1-bedb-78a6400328a4@st.com \
--to=vincent.abriou@st.com \
--cc=benjamin.gaignard@linaro.org \
--cc=hugues.fruchet@st.com \
--cc=jean-christophe.trotin@st.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
/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.