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@xxxxxxxxxx>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
