On Mon, Oct 5, 2020 at 10:26 AM Christoph Hellwig <hch@xxxxxx> wrote: > > On Fri, Oct 02, 2020 at 05:50:40PM +0000, Tomasz Figa wrote: > > Hi Christoph, > > > > On Wed, Sep 30, 2020 at 06:09:17PM +0200, Christoph Hellwig wrote: > > > Add a new API that returns a virtually non-contigous array of pages > > > and dma address. This API is only implemented for dma-iommu and will > > > not be implemented for non-iommu DMA API instances that have to allocate > > > contiguous memory. It is up to the caller to check if the API is > > > available. > > > > Would you mind scheding some more light on what made the previous attempt > > not work well? I liked the previous API because it was more consistent with > > the regular dma_alloc_coherent(). > > The problem is that with a dma_alloc_noncoherent that can return pages > not in the kernel mapping we can't just use virt_to_page to fill in > scatterlists or mmap the buffer to userspace, but would need new helpers > and another two methods. > > > > - no kernel mapping or only temporary kernel mappings are required. > > > That is as a better replacement for DMA_ATTR_NO_KERNEL_MAPPING > > > - a kernel mapping is required for cached and DMA mapped pages, but > > > the driver also needs the pages to e.g. map them to userspace. > > > In that sense it is a replacement for some aspects of the recently > > > removed and never fully implemented DMA_ATTR_NON_CONSISTENT > > > > What's the expected allocation and mapping flow with the latter? Would that be > > > > pages = dma_alloc_noncoherent(...) > > vaddr = vmap(pages, ...); > > > > ? > > Yes. Witht the vmap step optional for replacements of > DMA_ATTR_NO_KERNEL_MAPPING, which is another nightmare to deal with. > > > Would one just use the usual dma_sync_for_{cpu,device}() for cache > > invallidate/clean, while keeping the mapping in place? > > Yes. And make sure the API isn't implemented when VIVT caches are > used, but that isn't really different from the current interface. Okay, thanks. Let's see if we can make necessary changes to the videobuf2. +Sergey Senozhatsky for awareness too. Best regrards, Tomasz