Laurent - On 03/18/15 14:49, Tim Nordell wrote:
Digging through to find who is responsible for assigning the virtual addresses, I find that it's buried inside arch/arm/mm/dma-mapping.c:__alloc_iova(...). This call is called individually for each entry in the scatter-gather table via __map_sg_chunk from iommu_map_sg(...). If this is supposed to allocate a contiguous virtual memory region, it seems that __iommu_map_sg(...) should be considering the full buffer range rather than parts of the buffer at a time for the virtual allocation, similar to how __iommu_create_mapping(...) works in the same file. - Tim
I've confirmed that this code is the culprit for allocating a non-contiguous space (called via the dma_map_sg_attrs(...) back down in the videobuf2-dma-contig). I've reworked it for testing so that it does an __alloc_iova(...) on the entire region rather than a chunk at a time, however, I don't think what I have locally is completely the right approach for the generic case since I think technically a given entry in the scatterlist could end up with the end of a page partially used (the per list entry ->offset and such).
Looks like code (the specific functions in mm/dma-mapping.c) in question was last touched in 2012 with a quick git-blame, but I don't know how long the OMAP 3 ISP code has been using this common code. I'm guessing it's only been since the virtual memory manager internal to the IOMMU code was removed in July of last year.
Do you know if this common code is supposed to guarantee a physically contiguous memory region? The documentation for the function doesn't indicate that it should, and it certainly doesn't as-is. It seems like hitting this issue is highly dependent on the size of the buffer one is allocating.
- Tim -- 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
