On Tue, Sep 26, 2023 at 09:21:15AM +0100, Robin Murphy wrote: > On 2023-09-26 07:51, Christoph Hellwig wrote: >> On Wed, Sep 20, 2023 at 05:54:26PM +0100, Robin Murphy wrote: >>> As I mentioned before, I think it might make the most sense to make the >>> whole thing into a "proper" dma_alloc_sgtable() function, which can then be >>> used with dma_sync_sgtable_*() as dma_alloc_pages() is used with >>> dma_sync_single_*() (and then dma_alloc_noncontiguous() clearly falls as >>> the special in-between case). >> >> Why not just use dma_alloc_noncontiguous if the caller wants an sgtable >> anyway? > > Because we don't need the restriction of the allocation being > DMA-contiguous (and thus having to fall back to physically-contiguous in > the absence of an IOMMU). That's what vb2_dma_contig already does, whereas > IIUC vb2_dma_sg is for devices which can handle genuine scatter-gather DMA > (and so are less likely to have an IOMMU, and more likely to need the best > shot at piecing together large allocations). Let's just extent dma_alloc_noncontiguous with a max_dma_segments parameter instead of adding yet another API.
