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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html