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 <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
