Gerd Knorr wrote: > > > > * virt_to_bus() is gone in 2.4.x. It is not available any more for > > > 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. > > Hmm, a compile time warning would be better IMHO, as it is a driver devel > issue. But I have no idea how to do that ... Urgh... Not sure myself, would it be possible to put it in a #define ? eg: #define v4l2_vmalloc(x) \ #warning Old stuff \ v4l2_old_vmalloc(x) The #warning would probably not be expanded correctly. > > > * What exactly is the purpose of the v4l2_q_* functions? Any reason > > > not to use the generic lists (linux/lists.h) instead? > > > > v4l2_q functions include locking. I suppose they could be implemented > > on top of lists, but the current implementation is pretty clean and > > solid. > > Is this useful? My driver code often looks like this: > > spin_lock(btv->lock); > /* list operations, maybe multiple */ > /* other stuff which needs run locked (tell the hardware about > the new buffer, ...) */ > spin_unlock(btv->lock); The queues are also the primary comms path between the irq and the system - you have to lock these too. Also some drivers (like bttv2) try not to keep global locks for too long, as it interferes with multiple opens. I think these locks are a very good idea. > so there is no point in using list ops which include locking ... > > > > * What exactly was the reason to have one mmap() call for every buffer > > > instead of one big chunk like in v4l1? As the drivers have to > > > support one big chunk anyway for full v4l1 backward compatibility, > > > > Not really - only if the apps don't check the number of buffers returned > > by GMBUF (if they do, you get full v4l1 compatibility, but only 1 > > buffer...) > > The point of using mmap()ed buffers is being able to do double buffering. > Just one buffer isn't really useful ... Well, yes, but it will at least be functional... > > > why not handle v4l2 the same way? That would make things a bit easier > > > I think. And for dma-to-userland support we have to touch the API > > > anyway ... > > > > I'm not sure about this one. You probably find that there is some > > hardware that ca[tures onto on-board memory at some fixed locations? > > You can let the applications map the whole memory block then. > > > Not really sure, but the flexibility is good. > > I don't think having multiple mappings gives you more flexibility as > you can do in the nopage handler whatever you want. It's just a virtual > mapping which has nothing to do with the physical memory locations. > > > 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)? > > I'm thinking about using a (userspace pointer, length) tuple to reference > the buffer memory. > > For a kernel buffer the driver has to fill this. It will point into the > memory chunk mapped by the application first for obvious reasons, and the > driver even can pick fixed locations if it wants. > > For userland buffers the application has specify that tuple: either > register a fixed set of buffers first (QUERYBUF) or fill them for every > QBUF. Not sure yet which way is better. Of course the later is more > flexible, but allocating new buffers all the time isn't for free (neither > for the v4l driver nor for the application which might want to put stuff > directly into X11 MIT SHM blocks for example). This technique does have some valid points - it could clean up the driver a bit even, but I wu\ould like some input from someone with more experience - how seriously will this impact the current flexibility, if at all? -justin
