On Sun, 1 Aug 2010, Janusz Krzysztofik wrote: > Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ?(a): > > Friday 30 July 2010 13:07:42 Guennadi Liakhovetski napisaÅ?(a): > > > On Sun, 18 Jul 2010, Janusz Krzysztofik wrote: > > > > This is a V4L2 driver for TI OMAP1 SoC camera interface. > > > > > > > > Two versions of the driver are provided, using either > > > > videobuf-dma-contig or videobuf-dma-sg. The former uses less processing > > > > power, but often fails to allocate contignuous buffer memory. The > > > > latter is free of this problem, but generates tens of DMA interrupts > > > > per frame. > > > > > > Hm, would it be difficult to first try contig, and if it fails - fall > > > back to sg? > > > > Hmm, let me think about it. > > Hi Gennadi, > > For me, your idea of frist trying contig and then falling back to sg if it > fails, sounds great. However, I'm not sure if implementing it at a specific > hardware driver level is a good solution. Nor soc_camera framework seems the > right place for it either. > > I think the right way would be if implemented at the videobuf-core level. > Then, drivers should be able to initialize both paths, providing queue > callbacks for both sets of methods, contig and sg, for videobuf sole use. Ok, here're my thoughts about this: 1. We've discussed this dynamic switching a bit on IRC today. The first reaction was - you probably should concentrate on getting the contiguous version to work reliably. I.e., to reserve the memory in the board init code similar, how other contig users currently do it. But given problems with this aproach in the current ARM tree [1], this might be a bit difficult. Still, those problems have to be and will be fixed somehow eventually, so, you might prefer to still just go that route. 2. If you do want to do the switching - we also discussed, how forthcoming changes to the videobuf subsystem will affest this work. I do not think it would be possible to implement this switching in the videobuf core. Remember, with the videobuf API you first call the respective implementation init method, which doesn't fail. Then, in REQBUFS ioctl you call videobuf_reqbufs(), which might already fail but normally doesn't. The biggest problem is the mmap call with the contig videobuf implementation. This one is likely to fail. So, you would have to catch the failing mmap, call videobuf_mmap_free(), then init the SG videobuf, request buffers and mmap them... With my 2 patches from today, there is only one process (file descriptor, to be precise), that manages the videobuf queue. So, this all can only be implemented in your driver. [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/8560 > I'm not sure if I have enough skills to implement this idea. However, if there > is a consensus on its general usfullness as a videobuf extension, I can have > a look at it in my spare time. > > For now, I'd propose limiting my changes for v2 to splitting both methods into > separate sections, not interleaved with #ifdefs like they are now, as you've > already suggested. Yep, so, I think, your choice is either to drop sg completely, or to separate the two cleanly and switch between them dynamically in your driver. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
