On Tue, Dec 18, 2018 at 4:38 PM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Tue, Dec 18, 2018 at 04:22:43PM +0900, Tomasz Figa wrote: > > It kind of limits the usability of this API, since it enforces > > contiguous allocations even for big sizes even for devices behind > > IOMMU (contrary to the case when DMA_ATTR_NON_CONSISTENT is not set), > > but given that it's just a temporary solution for devices like these > > USB cameras, I guess that's fine. > > The problem is that you can't have flexibility and simplicity at the > same time. Once you use kernel virtual address remapping you need to > be prepared to have multiple segments. > > So as I said you can call dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT > in a loop with a suitably small chunk size, then stuff the results into > a scatterlist and map that again for the device share with if you don't > want a single contigous region. You just have to either deal with > non-contigous access from the kernel or use vmap and the right vmap > cache flushing helpers. The point is that you didn't have to do this small chunk loop without DMA_ATTR_NON_CONSISTENT, so it's at least inconsistent now and not sure why it could be better than just a loop of alloc_page(). > > > Note that in V4L2 we use the DMA API extensively, so that we don't > > need to embed any device-specific or integration-specific knowledge in > > the framework. Right now we're using dma_alloc_attrs() with > > driver-provided attrs [1], but current driver never request > > non-consistent memory. We're however thinking about making it possible > > to allocate non-consistent memory. What would you suggest for this? > > > > [1] https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/media/common/videobuf2/videobuf2-dma-contig.c#L139 > > I would advice against new non-consistent users until this series > goes through, mostly because dma_cache_sync is such an amazing bad > API. Otherwise things will just work at the allocation side, you'll > just need to be careful to transfer ownership between the cpu and > the device(s) carefully using the dma_sync_* APIs. Just to clarify, the actual code isn't very likely to surface any time soon. so I assume it would be after this series lands. We will however need an API that can transparently handle both cases of contiguous (without IOMMU) and page-by-page allocations (with IOMMU) behind the scenes, like the current dma_alloc_attrs() without DMA_ATTR_NON_CONSISTENT. Best regards, Tomasz
