Artur Skawina wrote: > > 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? It is often desirable to DMA directly into a target buffer. For example, into offscreen memory of a video card, or maybe the compression buffers of a codec, etc. The main reason I'm interested is for the offscreen DMA. > > 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? Sometimes the hardware may only support 2 buffers, or there may not be enough resources, etc. > > 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? Yes. As above. > QUERYBUF pins down the userspace buffers? what happens it that fails? The app receives an error code, and must handle it gracefully. > How is the amount of mlocked memory limited? Not yet handled. Any ideas? > Are multiple opens > of the same resource possible? Yes, in a way. Multiple opens of a capture card are possible, but only one open can control a capture resource on the card (the definition of a capture resource is very loose, and depends on the hardware). > > 5 - perform streaming capture. > > 6 - unmap requested buffers (REQBUFS with count set to 0). > > Simply closing the device would be enough too? That would also do, but the apps must have control of the release points for capture resources. You don't want to close the card, and reconfigure from the beginning just to change the image size. > > 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? Yes. Userland apps could be used in the modified without recompiling. -justin
