On Tue, Apr 24, 2001 at 08:02:16PM -0700, Bill Dirks wrote: > Gerd Knorr wrote: > > Problems/Questions: > > > > * virt_to_bus() is gone in 2.4.x. It is not available any more for > > 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_* functions have alloc and free calls, because they will programm a io memory management unit (for sparc, I think ia64 too). Simply translating memory addresses to bus addresses doesn't work because there is no fixed mapping any more. I've fixed bttv 0.8.x recently to drop the last virt_to_bus() call. Memory menagement looks like this now: - mmap() gives you shared anonymous memory (no vmalloc any more). - It uses kiobufs to lock down the memory pages for DMA. - It builds a scatter list for the pages returned by lock_kiovec() - It calls pci_map_sg() with that scatter list. - The risc code build functions pick the bus addresses from the scatter list. see linux/iobuf.h for kiobufs, Documentation/DMA-mapping.txt for the pci mapping. > > * What exactly is the purpose of the v4l2_q_* functions? Any reason > > not to use the generic lists (linux/lists.h) instead? > > They do exactly what I want. I don't find it useful to have locked every single list operation. Sometimes you have to aquire the lock just for the list operation (happens with bttv mostly if it queues some buffer). Often I have more to do with lock protection than just a single list operation. The irq handler may have to handle multiple list operations, and in needs to do more stuff (hardware programming) with the lock. IMHO the functions which call the list operations should take care about locking. > > * What exactly was the reason to have one mmap() call for every > > buffer instead of one big chunk like in v4l1? > > It just made sense to me that buffers are individually allocated and > freed. I never really wanted to to use mmap() for passing capture > buffers. I'd love to drop mmap() altogether too, but I think we have problems to support devices with on-board memory and those which can't to scatter-gather then ... > mmap() is for mapping file contents to virtual memory, not for > this. Mapping device memory with mmap() is common operation on unix, see framebuffer devices for example. > > Comments? > > If I understand the way your registration process works, when the app > calls open(), a new struct file is created whose fops->open points to > video_open() in videodev.o. The file_get/put functions just play with the reference counters there, they don't allocate a new struct. > Then video_open() substitutes the driver > fops and calls skeleton_open(). So skeleton_open() is never called > directly, but always through video_open(). Yes. > In that case, why not pass > the video_device * to skeleton_open() to save it from having to search > for its video_device *? Hmm, yes, we can put the pointer into private_data before calling the driver's open function for example. > How about changing the "video_" prefix to "v4l_" to avoid namespace > conflicts with linux/drivers/video? There are already two "struct > video_info"s-- in sisfb.h and videodev.h. Only problem is that these structs are seen by userland too, so we would break the v4l API ... Gerd
