Laurent -
On 03/18/15 10:21, Laurent Pinchart wrote:
Correct. sg_dma_address() should contain the DMA virtual address when
an IOMMU is used.
I was assuming it was checking the physical memory layout to it without
looking too closely to the code. Armed with that knowledge, I'll dig a
little deeper to see if I can figure out what happened here.
I added a bit of code to where it was printing out the error code to
print out the mapping as vb2_dc_get_contiguous_size(...) sees it. I get
back the following:
[ 200.031249] sgt[0].addr = 0x400a0000 - 0x400affff
[ 200.031280] sgt[1].addr = 0x400b0000 - 0x400bffff
[ 200.031311] sgt[2].addr = 0x400c0000 - 0x400cffff
[ 200.031341] sgt[3].addr = 0x400d0000 - 0x400dffff
[ 200.031372] sgt[4].addr = 0x400e0000 - 0x400effff
[ 200.031402] sgt[5].addr = 0x400f0000 - 0x400fffff
[ 200.031433] sgt[6].addr = 0x40100000 - 0x4010ffff
[ 200.031463] sgt[7].addr = 0x40110000 - 0x4011ffff
[ 200.031494] sgt[8].addr = 0x40120000 - 0x4012ffff
[ 200.031524] sgt[9].addr = 0x40098000 - 0x4009dfff
[ 200.031524] contiguous mapping is too small 589824/614400
Notice that the last section is completely off the wall compared to the
rest?
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
--
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
