> > all architectures (i386 does still work, sparc doesn't for example). > > You have to use the PCI API (see Documentation/DMA-mapping.txt) > > instead. Looks like the mm helper functions are obsolete now... > > Rats, and they were soooo convenient. Right now I would say leave them > in, but make it generate a syslog message informing the user that the > application is out of date the first time they are used. Switch to pci_ functions. They do the right thing and are not that hard to use. > 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. > 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
