> > 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
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
