From: Mauro Carvalho Chehab <mchehab@infradead.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Randy Dunlap <rdunlap@xenotime.net>, linux-media@vger.kernel.org
Subject: Re: [PATCH] Updated videobuf documentation
Date: Fri, 19 Feb 2010 04:09:19 -0200 [thread overview]
Message-ID: <4B7E2B0F.6000706@infradead.org> (raw)
In-Reply-To: <4B7DC652.9080601@xenotime.net>
Randy Dunlap wrote:
> On 02/18/10 09:12, Jonathan Corbet wrote:
>> Here (finally) is a new version of the videobuf documentation patch. As
>> requested by Mauro, I have cleaned up the (now) redundant information in
>> v4l2-framework.txt. A couple of errors from the first version have
>> also been remedied.
Very good job! I only noticed the same points that Randy already commented, plus
one a few small details:
>> +Drivers using the vmalloc() method need not (and cannot) concern themselves
>> +with buffer allocation at all; videobuf will handle those details.
OK
>> The +same is true of contiguous-DMA drivers;
Not anymore: there's a patch that added USERPTR support for videobuf-dma-contig:
commit 720b17e759a50635c429ccaa2ec3d01edb4f92d6
Author: Magnus Damm <damm@igel.co.jp>
Date: Tue Jun 16 15:32:36 2009 -0700
videobuf-dma-contig: zero copy USERPTR support
---
In terms of memory types, there's a possibility that weren't mentioned: the OVERLAY mode.
On overlay mode, the video memory is directly mmapped by the driver. So, the DMA will
do a PCI2PCI transfer, from the video capture device into the video display adapter.
This is currently only supported by videobuf-dma-sg, and only a few drivers actually
implement it (I think it is supported only by bttv and saa7134).
I'm not sure if it is valuable enough to mention it, since, at least for desktops,
this mode is deprecated, as passing the stream to userspace allows some post-processing,
like de-interlacing. Yet, there are some new SoC video devices, mostly used
on embedded devices, where I think the Overlay mode is interesting. Those devices may
have in-hardware post-processing, so it may make sense to avoid double buffering.
Maybe a small paragraph may be added just for the completeness of the doc.
--
Cheers,
Mauro
next prev parent reply other threads:[~2010-02-19 6:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 17:12 [PATCH] Updated videobuf documentation Jonathan Corbet
2010-02-18 22:59 ` Randy Dunlap
2010-02-19 6:09 ` Mauro Carvalho Chehab [this message]
2010-02-22 20:47 ` Jonathan Corbet
2010-02-22 21:21 ` Randy Dunlap
2010-02-22 21:52 ` Mauro Carvalho Chehab
2010-02-22 20:38 ` Jonathan Corbet
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=4B7E2B0F.6000706@infradead.org \
--to=mchehab@infradead.org \
--cc=corbet@lwn.net \
--cc=linux-media@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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