[E3-hacking] [RFC] [PATCH 1/6] SoC Camera: add driver for OMAP1 camera interface
Guennadi Liakhovetski
g.liakhovetski at gmx.de
Fri Aug 13 09:52:41 BST 2010
On Fri, 13 Aug 2010, Janusz Krzysztofik wrote:
> Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a):
> > On Sun, 1 Aug 2010, Janusz Krzysztofik wrote:
> > > Friday 30 July 2010 20:49:05 Janusz Krzysztofik napisaÅ(a):
> > >
> > > 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.
>
> I already tried before to find out how I could allocate memory at init without
> reinventing a new videobuf-dma-contig implementation. Since in the
> Documentation/video4linux/videobuf I've read that videobuf does not currently
> play well with drivers that play tricks by allocating DMA space at system
> boot time, I've implemented the alternate sg path.
>
> If it's not quite true what the documentation says and you can give me a hint
> how this could be done, I might try again.
For an example look at
arch/arm/mach-mx3/mach-pcm037.c::pcm037_camera_alloc_dma().
> > 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.
>
> My board uses two drivers that allocate dma memory at boot time:
> drivers/video/omap/lcdc.c and sounc/soc/omap/omap-pcm.c. Both use
> alloc_dma_writecombine() for this and work without problems.
dma_alloc_writecombine() also allocates contiguous RAM, right? And it
doesn't use device "local" memory. So, it's chances to fail are the same
as those of dma_alloc_coherent() in the absence of device own memory. I
guess, the sound driver doesn't need much RAM, but if you build your LCDC
driver as a module and load it later after startup, it might get problems
allocating RAM for the framebuffer.
> > 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.
>
> OK, I should have probably said that it looked not possible for me to do it
> without any additional support implemented at videobuf-core (or soc_camera)
> level.
>
> > 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...
>
> That's what I've already discovered, but failed to identify a place in my code
> where I could intercept this failing mmap without replacing parts of the
> videobuf code.
Right, ATM soc-camera just calls videobuf_mmap_mapper() directly in its
mmap method. I could add a callback to struct soc_camera_host_ops like
int (*mmap)(struct soc_camera_device *, struct vm_area_struct *)
and modify soc_camera_mmap() to check, whether the host driver has
implemented it. If so - call it, otherwise call videobuf_mmap_mapper()
directly just like now. So, other drivers would not have to be modified.
And you could implement that .mmap() method, call videobuf_mmap_mapper()
yourself, and if it fails for contig, fall back to SG.
> > 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.
>
> The only way I'm yet able to invent is replacing the
> videobuf_queue->int_ops->mmap_mapper() callback with my own wrapper that
> would intercept a failing videobuf-dma-contig version of mmap_mapper(). This
> could be done in my soc_camera_host->ops->init_videobuf() after the
> videobuf-dma-contig.c version of the videobuf_queue->int_ops->mmap_mapper()
> is installed with the videobuf_queue_dma_contig_init().
>
> Is this method close to what you have on mind?
See, if the above idea would suit your needs.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
More information about the e3-hacking
mailing list