aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/video4linux/v4l2-framework.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/video4linux/v4l2-framework.txt')
-rw-r--r--Documentation/video4linux/v4l2-framework.txt106
1 files changed, 10 insertions, 96 deletions
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 74d677c8b036..5155700c206b 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -599,99 +599,13 @@ video_device::minor fields.
599video buffer helper functions 599video buffer helper functions
600----------------------------- 600-----------------------------
601 601
602The v4l2 core API provides a standard method for dealing with video 602The v4l2 core API provides a set of standard methods (called "videobuf")
603buffers. Those methods allow a driver to implement read(), mmap() and 603for dealing with video buffers. Those methods allow a driver to implement
604overlay() on a consistent way. 604read(), mmap() and overlay() in a consistent way. There are currently
605 605methods for using video buffers on devices that supports DMA with
606There are currently methods for using video buffers on devices that 606scatter/gather method (videobuf-dma-sg), DMA with linear access
607supports DMA with scatter/gather method (videobuf-dma-sg), DMA with 607(videobuf-dma-contig), and vmalloced buffers, mostly used on USB drivers
608linear access (videobuf-dma-contig), and vmalloced buffers, mostly 608(videobuf-vmalloc).
609used on USB drivers (videobuf-vmalloc). 609
610 610Please see Documentation/video4linux/videobuf for more information on how
611Any driver using videobuf should provide operations (callbacks) for 611to use the videobuf layer.
612four handlers:
613
614ops->buf_setup - calculates the size of the video buffers and avoid they
615 to waste more than some maximum limit of RAM;
616ops->buf_prepare - fills the video buffer structs and calls
617 videobuf_iolock() to alloc and prepare mmaped memory;
618ops->buf_queue - advices the driver that another buffer were
619 requested (by read() or by QBUF);
620ops->buf_release - frees any buffer that were allocated.
621
622In order to use it, the driver need to have a code (generally called at
623interrupt context) that will properly handle the buffer request lists,
624announcing that a new buffer were filled.
625
626The irq handling code should handle the videobuf task lists, in order
627to advice videobuf that a new frame were filled, in order to honor to a
628request. The code is generally like this one:
629 if (list_empty(&dma_q->active))
630 return;
631
632 buf = list_entry(dma_q->active.next, struct vbuffer, vb.queue);
633
634 if (!waitqueue_active(&buf->vb.done))
635 return;
636
637 /* Some logic to handle the buf may be needed here */
638
639 list_del(&buf->vb.queue);
640 do_gettimeofday(&buf->vb.ts);
641 wake_up(&buf->vb.done);
642
643Those are the videobuffer functions used on drivers, implemented on
644videobuf-core:
645
646- Videobuf init functions
647 videobuf_queue_sg_init()
648 Initializes the videobuf infrastructure. This function should be
649 called before any other videobuf function on drivers that uses DMA
650 Scatter/Gather buffers.
651
652 videobuf_queue_dma_contig_init
653 Initializes the videobuf infrastructure. This function should be
654 called before any other videobuf function on drivers that need DMA
655 contiguous buffers.
656
657 videobuf_queue_vmalloc_init()
658 Initializes the videobuf infrastructure. This function should be
659 called before any other videobuf function on USB (and other drivers)
660 that need a vmalloced type of videobuf.
661
662- videobuf_iolock()
663 Prepares the videobuf memory for the proper method (read, mmap, overlay).
664
665- videobuf_queue_is_busy()
666 Checks if a videobuf is streaming.
667
668- videobuf_queue_cancel()
669 Stops video handling.
670
671- videobuf_mmap_free()
672 frees mmap buffers.
673
674- videobuf_stop()
675 Stops video handling, ends mmap and frees mmap and other buffers.
676
677- V4L2 api functions. Those functions correspond to VIDIOC_foo ioctls:
678 videobuf_reqbufs(), videobuf_querybuf(), videobuf_qbuf(),
679 videobuf_dqbuf(), videobuf_streamon(), videobuf_streamoff().
680
681- V4L1 api function (corresponds to VIDIOCMBUF ioctl):
682 videobuf_cgmbuf()
683 This function is used to provide backward compatibility with V4L1
684 API.
685
686- Some help functions for read()/poll() operations:
687 videobuf_read_stream()
688 For continuous stream read()
689 videobuf_read_one()
690 For snapshot read()
691 videobuf_poll_stream()
692 polling help function
693
694The better way to understand it is to take a look at vivi driver. One
695of the main reasons for vivi is to be a videobuf usage example. the
696vivi_thread_tick() does the task that the IRQ callback would do on PCI
697drivers (or the irq callback on USB).