On Wendesday, 23 March 2011, at 11:00:06, Guennadi Liakhovetski wrote: > > You might want to retest ams-delta with the camera on the current > (next or git://linuxtv.org/media_tree.git staging/for_v2.6.39) kernel > ... Hi Guennadi, With the patch I've just submitted to the linux-media list (http://www.spinics.net/lists/linux-media/msg31255.html), the 2.6.39-rc2 OMAP1 camera driver still works for me as before, but only in SG mode. I'm no longer able to use it in CONTIG mode after videobuf-dma-contig.c has been changed with commit 35d9f510b67b10338161aba6229d4f55b4000f5b, "V4L: videobuf, don't use dma addr as physical", supposed to correct potential issues on IOMMU euqipped machines. Since there were no actual problems reported before, I suppose the old code, which was passing to remap_pfn_range() a physical page number calculated from dma_alloc_coherent() privided dma_handle, worked correctly on all platforms actually using videobud-dma-config. Now, on my ARM machine, a completely different, then completely wrong physical address, calculated as virt_to_phys(dma_alloc_coherent()), is used instead of the dma_handle, which causes the machine to hang. AFAICS, incompatibility of the new code with the ARM architecture has been already pointed out as a potential issue by Lauent Pinchart (http://www.spinics.net/lists/linux-media/msg29544.html), but the patch has been accepted regardless. I suspect the problem may affect other ARM subarchitectures, not only OMAP1, but have no way to verify this. Anyone with a suitable hardware, can you please verify and report if your machine is affected or not? I've tried to resolve the problem by conditionally (#ifdef CONFIG_ARM) replacing remap_pfn_range() with ARM specific dma_mmap_coherent(), but with not much success so far. While this still seems a possibly correct solution to me (see sound/core/pcm_native.c for an example, architecture independent driver code which already implements a similiar method), I found that the dma_mmap_coherent() does its job for me only with the first buffer, failing with the second one because of negative buffer size vs. available vma space comparison. It seems to me that there may be something wrong with vma->vm_pgoff handling, but I'm not sure if in the V4L videobuf, or in the ARM DMA, or in a yet another piece of code. Not being able to work out a solution myself, other than reverting back to the old code for ARM, I hope someone can come out with a better idea. 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
