Re: [PATCH v2 25/26] omap3isp: Move to videobuf2

[Tim Nordell <tim.nordell@logicpd.com>]

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