[Linaro-mm-sig] Minutes from V4L2 update call

[Dave Airlie]

On Tue, Mar 27, 2012 at 1:25 PM, Tomasz Stanislawski
<t.stanislaws at samsung.com> wrote:
> Hi Everyone,
>
> I started preparing a support for DMABUF in VIVI allocator.
> I encountered a problem that may involve making an important
> design decision.
>
> Option I
>
> Use existing dma_buf_attach/dma_buf_map_attachment mechanism.
>
> The allocator vb2-vmalloc (thus VIVI) would be relatively easy to
> implement if one would allow to call dma_buf_attach on NULL device.
> AFAIK, dmabuf code does not dereference this pointer.
> Permitting passing NULL as device pointer would allow DMABUF to
> be accessed by importer not associated with any device (like VIVI).
> After obtaining the sglist the importer would map it into its
> kernel address space using kmap or vm_map_ram or remap_pfn_range.
> Note that memory would be pinned after calling dma_buf_map_attachment,
> so the memory will not be freed in parallel.
>
> The cache flushing would still be an unsolved problem but the same
> situation happens for non-NULL devices. It may be fixed by future
> extension to dmabuf API.
>
> I prefer this approach because it is compatible with
> 'importer-maps-memory-for-importer' strategy.
>
> Option II
>
> Recently support for kernel access by CPU for DMABUF was proposed by
> Daniel Vetter. It seams to be suitable for VIVI and vb2-vmalloc allocator.
>
> However there are some issues.
>
> 1. VIVI requires that the whole kernel mapping is contiguous in VMALLOC area,
>   accessible by a single pointer pointing to the first byte of a buffer.
> The interface proposed by Daniel involves calling a dma_buf_kmap. This function
> takes a page number as the argument. However the spec does not guarantee if
> page n and page n+1 would be mapped into sequential addresses. I think that
> this requirement should be added to the spec.
>
> 2. AFAIK, usage of dma_buf_kmap interface does not require any attach operation.
> Therefore CPU access is more-or-less a parallel mechanism for memory access.
>
> Calling dma_buf_map_attachment is seams to be equivalent for calling
> dma_buf_begin_cpu_access for the whole buffer. Plus kmap for all pages
> if an exporter is responsible for mapping memory at dma_buf_map_attachment
>
> Is it really worth to introduce a parallel mechanism?
>
>
>
> Could you give me a hint which solution is better?

Option III - write a vmap interface ala,

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-dmabuf2&id=c481a5451744fe3c4c950a446be10d3212d633d8

I'm using this for i915->udl mappings, though vmap is a limited
resource and I'm sure on ARM its even more limited.

Dave.