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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox