Alan Cox wrote: > > v4l2_q functions include locking. I suppose they could be implemented > > on top of lists, but the current implementation is pretty clean and > > solid. > > Taking and releasing locks is expensive on many x86 boxes so taking them > for each list op can be bad. Yes, except that v4l2_q's are always used for communicating with the irq handler, so _must_ always get a lock anyway. It is a nice, simple helper that greatly simplifies the capture core of most drivers. > > Wouldn't one single block be _worse_ for dma-to-userland? Restricting > > the user to one big buffer, instead of pointing the driver to multiple > > independant buffers, or do you plan to differentiate the two techniques > > (in which case, why kill the ability to mmap multiple buffers)? > > If you have one hardware buffer then transferring it in a bh after each irq > to a a ring buffer in kernel space make sense. You then map the ring buffer > to keep down to one copy. I meant to do this for the PMS but never got time I was referring to userland buffers. It is probably much more convenient for the user to allocate a separate memory area for each image buffer, rather than one big memory area. I am not entirely sure, but if you wanted to allocate multiple Xshm image buffers, and then display them in sequence, X would not give them to you in a contiguous block - you would want to be able to dma to each individually. -justin
