On Wed, Dec 9, 2020 at 10:05 PM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 2020-12-09 11:12, Christoph Hellwig wrote: > > On Tue, Dec 08, 2020 at 01:54:00PM +0900, Tomasz Figa wrote: > >> >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
