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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
