On 03/18/15 16:44, Sakari Ailus wrote:
I don't think omap3isp has been using this very long. A few minor versions
perhaps.
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.
I guess there aren't too many drivers that may map large areas of memory
pinned using get_user_pages() to IOMMU. If dma_map_sg() couldn't be used to
allocate virtually contiguous memory, then what could be? This looks like a
bug in __iommu_map_sg() to me.
Cc the iommu list.
After staring at this for a while, I realized that the mm/dma-mapping.c
is doing exactly what it's supposed to (and works similarly to how I was
starting to refactor the outer function) and that the omap3isp driver
needs to do one further step in initialization.
There is a call dma_set_max_seg_size(...) that defines how the code in
dma-mapping.c chunks things up. If it's set larger, the dma-mapping
routine will allocate larger physically contiguous chunks in the virtual
memory space. Any clue where the best place in omap3isp to set this is?
At least it's a short patch to omap3isp to fix this behavior. I'll be
sending a patch along shortly.
- 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
