On Wed, Dec 9, 2020 at 10:05 PM Robin Murphy [off-list ref] wrote:

On 2020-12-09 11:12, Christoph Hellwig wrote:

quoted

On Tue, Dec 08, 2020 at 01:54:00PM +0900, Tomasz Figa wrote:

quoted

quoted

From the media perspective, it would be good to have the vmap

optional, similarly to the DMA_ATTR_NO_KERNEL_MAPPING attribute for
coherent allocations. Actually, in the media drivers, the need to have
a kernel mapping of the DMA buffers corresponds to a minority of the
drivers. Most of them only need to map them to the userspace.

Nevertheless, that minority actually happens to be quite widely used,
e.g. the uvcvideo driver, so we can't go to the other extreme and just
drop the vmap at all.

My main problem is that the DMA_ATTR_NO_KERNEL_MAPPING makes a mess
of an API.  I'd much rather have low-level API that returns the
discontiguous allocations and another one that vmaps them rather
than starting to overload arguments like in dma_alloc_attrs with
DMA_ATTR_NO_KERNEL_MAPPING.

Okay, makes sense. Actually, a separate mapping function makes it
possible to defer creating the mapping to when (and if) it is really
needed.

Agreed - if iommu-dma's dma_alloc_coherent() ends up as little more than
a thin wrapper around those two functions I think that would be a good
sign. It also seems like it might be a good idea for this API to use
scatterlists rather than page arrays as it's fundamental format, to help
reduce impedance with dma-buf -

True.

if we can end up with a wider redesign
that also gets rid of dma_get_sgtable(), all the better!

That would also require taking care of the old dma_alloc_attrs() API.
I guess it could return an already mapped sgtable, with only 1 mapped
entry and as many following entries as needed to describe the physical
pages. To be honest, I'd say this is far out of scope of this
discussion, though.

Best regards,
Tomasz