Lines Matching full:will

80 along with a list_head for the queue of available buffers.  There will also
103 parameter will be a suggested number of buffers to use; the driver should
110 Each buffer (in the form of a struct videobuf_buffer pointer) will be
120 Among other things, this call will usually allocate memory for the buffer.
127 held; if it tries to acquire it as well things will come to a screeching
201 device (cameras will use V4L2_BUF_TYPE_VIDEO_CAPTURE, for example), field
225 Either one of these functions will read frame data into data, returning the
226 amount actually read; the difference is that videobuf_read_one() will only
227 read a single frame, while videobuf_read_stream() will read multiple frames
229 typical driver read() implementation will start the capture engine, call
242 Note that the actual wait queue eventually used will be the one associated
266 videobuf_mmap_free() will ensure that all buffers have been unmapped; if
267 so, they will all be passed to the buf_release() callback.  If buffers
298 The vidioc_streamon() and vidioc_streamoff() functions will be a bit more
299 complex, of course, since they will also need to deal with starting and
308 videobuf layer; in this case, buffers will be allocated as anonymous
309 user-space pages and will be very scattered indeed.  If the application is
310 using user-space buffers, no allocation is needed; the videobuf layer will
334 with buffer allocation at all; videobuf will handle those details.  The
335 same is normally true of contiguous-DMA drivers as well; videobuf will
344 allocations will not meet that criterion, but buffers obtained from other
345 kernel drivers, or those contained within huge pages, will work with these
374 DMA; that ensures that the videobuf layer will not try to do anything with
377 For scatter/gather drivers, the needed memory pointers will be found in the
403 GPL-only, so they will not be available to non-GPL kernel modules.