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

[Guennadi Liakhovetski]

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/