Lines Matching refs:it

22    address spaces.  (Almost) all user-space buffers are like this, but it
24    it is possible.  Unfortunately, it is not always possible; working with
43 functionality is considered to be deprecated for most use, but it still
83 check it for rationality and adjust it if need be.  As a practical rule, a
92 VIDEOBUF_NEEDS_INIT, the driver should pass it to:
101 When a buffer is queued for I/O, it is passed to buf_queue(), which should
102 put it onto the driver's list of available buffers and set its state to
104 held; if it tries to acquire it as well things will come to a screeching
106 wait on the first buffer in the queue; placing other buffers in front of it
111 then pass it to the appropriate free routine(s):
125 One way to ensure that a buffer is no longer under I/O is to pass it to:
130 should be used (it should be zero in the buf_release() case), and intr
180 a general rule, it is necessary to support both to ensure that all
181 applications have a chance of working with the device.  Videobuf makes it
226 The call to videobuf_stop() terminates any I/O in progress - though it is
253 proper struct videobuf_queue pointer and pass it to videobuf_reqbufs().
271 If the driver needs to do its own memory allocation, it should be done in
284 populate it with pointers to the pieces of the allocated buffer; sglen
290 allocate the buffers (with dma_alloc_coherent()) when it sees fit.  That
304 The final part of a videobuf implementation has no direct callback - it's
310    waiting for it.
314  - Mark the buffer as done and wake up the process waiting for it.
318 the engine and enqueueing buffers are done in separate steps, it's possible
322 buffer; the driver should not remove it from the list or fill it until a
323 process is waiting on it.  That test can be done by examining the buffer's
328 it while the device is transferring data.
346 buffer is owned by the videobuf layer and the driver should not touch it
353 drivers should be written.  Vivi only uses the vmalloc() API, but it's good