Justin Schoeman wrote: > > Hi everybody, I have been taking a look at adding DMA to userspace to > the V4L2 API. My ideas are discussed below. Any comments/criticisms are > welcome. note that i looked at v4l2 and decided it wasn't anything useful a few months/years back. Hence these are just general comments/questions about the design -- i don't know v4l2 enough to be able to comment on the details. > 1) Exisiting mechanism: > The existing streaming capture mechanism can be summarised as follows: > 1 - Set capture format (S_FMT) > 2 - Request buffers (REQBUFS) > 3 - Map buffers into userspace (QUERYBUF and mmap) > 4 - do streaming capture here. > 5 - unmap buffers (implicity unrequests buffers). > > This should be changed to include an explicit "unrequest buffers" first, _why_? ie what advantages does "DMA to userspace" the way you're proposing have over the current scheme? > 5) DMA to userspace example: > 1 - set capture format (S_FMT) > 2 - request buffers (REQBUFS with V4L2_BUF_REQ_DMA set) > 3 - allocate userspace memory for the number of granted buffers. is it possible to be granted less buffers than requested? when? > 4 - call QUERYBUF on each buffer, filling in dmabuf with a pointer to > the struct v4l2_dmabuffer describing each buffer (note that dmabuf is > ignored if V4L2_BUF_REQ_DMA was not set when the buffers were > requested). so the only difference is that the app instead of the v4l2 layer is doing the allocation, right? The advantage? QUERYBUF pins down the userspace buffers? what happens it that fails? How is the amount of mlocked memory limited? Are multiple opens of the same resource possible? > 5 - perform streaming capture. > 6 - unmap requested buffers (REQBUFS with count set to 0). Simply closing the device would be enough too? > As far as I can see, this API extension would give the maximum > flexibility, with a minimum of incompatibilities. Would the new v4l2_buffer be compatible with the old one?
