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

[Tomasz Stanislawski]

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?


Regards,
Tomasz Stanislawski