[E3-hacking] [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface

Janusz Krzysztofik jkrzyszt at tis.icnet.pl
Sun Aug 1 16:51:15 BST 2010

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.

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.


More information about the e3-hacking mailing list