Lines Matching refs:of
3 Current as of 2.6.33
5 The videobuf layer functions as a sort of glue layer between a V4L2 driver
6 and user space. It handles the allocation and management of buffers for
7 the storage of video frames. There is a set of functions which can be used
8 to implement many of the standard POSIX I/O system calls, including read(),
9 poll(), and, happily, mmap(). Another set of functions can be used to
10 implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
13 author, but the payback comes in the form of reduced code in the driver and
14 a consistent implementation of the V4L2 user-space API.
18 Not all video devices use the same kind of buffers. In fact, there are (at
25 this kind of buffer normally requires hardware which can do
34 - Buffers which are physically contiguous. Allocation of this kind of
38 Videobuf can work with all three types of buffers, but the driver author
41 [It's worth noting that there's a fourth kind of buffer: "overlay" buffers
45 benefits merit the use of this technique. Overlay buffers can be handled
46 as a form of scattered buffer, but there are very few implementations in
47 the kernel and a description of this technique is currently beyond the
48 scope of this document.]
52 Depending on which type of buffers are being used, the driver should
53 include one of the following files:
60 struct videobuf_queue instance for the management of the buffer queue,
61 along with a list_head for the queue of available buffers. There will also
66 the management of buffers:
82 parameter will be a suggested number of buffers to use; the driver should
84 minimum of two buffers are needed for proper streaming, and there is
87 for each frame of data.
89 Each buffer (in the form of a struct videobuf_buffer pointer) will be
102 put it onto the driver's list of available buffers and set its state to
105 halt. Yes, this is the voice of experience. Note also that videobuf may
106 wait on the first buffer in the queue; placing other buffers in front of it
135 At this point, much of the work is done; much of the rest is slipping
136 videobuf calls into the implementation of the other driver callbacks. The
138 videobuf queue. The function to use depends on the type of buffer used:
168 device, ops is the set of callbacks as described above, dev is the device
173 progressive devices), msize is the size of any containing structure used
175 shows up in the priv_data field of struct videobuf_queue. Note that these
178 V4L2 capture drivers can be written to support either of two APIs: the
181 applications have a chance of working with the device. Videobuf makes it
183 only make a call to one of:
193 Either one of these functions will read frame data into data, returning the
198 one of the above functions, then stop the engine before returning (though a
200 anticipation of another read() call happening in the near future).
231 purpose is clearly to cause the closing of the file descriptor to fail if
237 The V4L2 API includes a very long list of driver callbacks to respond to
238 the many ioctl() commands made available to user space. A number of these
254 These support functions can replace a great deal of buffer management
255 boilerplate in a lot of V4L2 drivers.
258 complex, of course, since they will also need to deal with starting and
269 take care of calling get_user_pages() and filling in the scatterlist array.
278 <media/videobuf-dma-sg.h>) includes a couple of relevant fields:
284 populate it with pointers to the pieces of the allocated buffer; sglen
285 should be set to the length of the array.
289 same is normally true of contiguous-DMA drivers as well; videobuf will
296 As of 2.6.31, contiguous-DMA drivers can work with a user-supplied buffer,
304 The final part of a videobuf implementation has no direct callback - it's
305 the portion of the code which actually puts frame data into the buffers,
306 usually in response to interrupts from the device. For all types of
340 The contiguous DMA API goes out of its way to hide the kernel-space address
341 of the DMA buffer from drivers.
343 The final step is to set the size field of the relevant videobuf_buffer
344 structure to the actual size of the captured image, set state to
352 (drivers/media/platform/vivi.c), which is maintained as an example of how V4L2
354 enough to get started with. Note also that all of these calls are exported