[E3-hacking] [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
g.liakhovetski at gmx.de
Thu Aug 12 22:38:17 BST 2010
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 , 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.
> 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
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
More information about the e3-hacking