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

[Janusz Krzysztofik]

Saturday 14 August 2010 06:47:56 Marin Mitov napisał(a):
> On Friday, August 13, 2010 10:13:08 pm Janusz Krzysztofik wrote:
> > Friday 13 August 2010 11:11:52 Marin Mitov napisał(a):
> > > On Friday, August 13, 2010 11:52:41 am Guennadi Liakhovetski wrote:
> > > > On Fri, 13 Aug 2010, Janusz Krzysztofik wrote:
> > > > > Thursday 12 August 2010 23:38:17 Guennadi Liakhovetski napisał(a):
> > > > > > 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().
> >
> > Yes, this is the solution that suffers from the already discussed
> > limitation of not being able to remap a memory with different attributes,
> > which affects OMAP1 as well.
> >
> > > For preallocating dma-coherent memory for device personal use during
> > > device probe() time (when the memory is less fragmented compared to
> > > open() time) see also dt3155_alloc_coherent/dt3155_free_coherent in
> > > drivers/staging/dt3155v4l/dt3155vfl.c (for x86 arch, I do not know if
> > > it works for arm arch)
> >
> > With this workaround applied, I get much better results, thank you Marin.
> > However, it seems not bullet proof, since mmap still happens to fail for
> > a reason not quite clear to me:
>
> This is just a preallocation of coherent memory kept for further private
> driver use, should not be connected to mmap problem.

I'm not sure if it is related or not. This "mmap problem" exhibits ultimately 
when my driver is trying to allocate a piece of memory that has been 
preallocated that "custom" way.

> > Maybe I should preallocate a few more pages than will be actually used by
> > the driver?
> >
> > Anyways, I'm not sure if this piece of code could be accepted for
> > inclusion into the mainline tree, perhaps only under drivers/staging.
>
> The idea for the piece of code I have proposed to you is taken from the
> functions dma_declare_coherent_memory()/dma_release_declared_memory() in
> mainline drivers/base/dma-coherent.c

Then why not using the dma_declare_coherent_memory(), possibly after providing 
a patch that corrects a problem with it if there is one, instead of 
reimplementing it inside a driver?

If I understood what a difference it could make if we put a 
dma_alloc_coherent() returned virtual address space pointer to the allocated 
region, instead of the ioremapped physical address base of this region, to 
the dev->dma_mem->virt_base, then maybe I could say something more on this.

Thanks,
Janusz