> > > I still want to keep vmalloc_to_bus() for drivers that need to process > > > the data from the hardware. I will investigate how to reimplement it > > > without virt_to_bus(). > > > > You can't. At least you can't build a plug-in replacement. The pci_* [ ... ] > > >From what I have seen, it would be possible, if we add v4l2_alloc and > v4l2_free type functions too - basically a complete set of memory > management helpers. Yes, if you make it symmetrical with alloc+free helpers it will work. It just isn't a plug-in replacement any more as you have to fix the drivers to use the new functions. > Allocate buffer memory for each capture buffer. [ ... ] Problem #1: bttv 0.8.x does not allocate memory. bttv gives you a just a shared anonymous mapping, and the kernel vm will allocate and map these pages on use. It is normal userspace memory, it is _not_ unswappable kernel memory remapped to userspace. The only difference between memory allocated using mmap(MAP_ANONYMOUS) and using bttv 0.8.x is that in the second case the bttv driver knows the userspace pointer for the mapping. It effectively does already dma-to-userspace, the only reason why mmap() is involved here is API compatibility. And the only difference between capture using read() and mmap() is that in the first case bttv will use the data pointer passed in by the read() system call and in the second case the it will use the pointer(s) saved at mmap() time. Of course it does not work this way for all pieces of hardware. Some can't do scatter-gather and therefore need one big piece of memory (using the bigphysmem patch or something like that). Same is true for on-board memory. > To maintain v4l1 compatibility, use the virtual mapping capabilities to > map multiple buffers back to a contiguous userspace buffer. That works only if you have some piece of memory (vmalloc, on-board memory, ...) which you remap into the applications address space. > From what I > can see, this should be very easy, and require very little additional > code (much less than the current technique of maintaining two separate > buffer styles. The problem I see here is that there are many different ways to handle mmap(). I don't think there is a reasonable way to hide v4l1 and v4l2 style mmap() differences in the compatibility layer. That's why I'd like handle v4l2 the same way as v4l1, so the drivers don't need to handle both. Gerd
