Re: a saner API for allocating DMA addressable pages v2
On Mon, Sep 14, 2020 at 04:26:17PM +0100, Matthew Wilcox wrote: > On Mon, Sep 14, 2020 at 04:44:16PM +0200, Christoph Hellwig wrote: > > I'm still a little unsure about the API naming, as alloc_pages sort of > > implies a struct page return value, but we return a kernel virtual > > address. > > Erm ... dma_alloc_pages() returns a struct page, so is this sentence > stale? Yes. > You say that like it's a bad thing. I think the problem is more that > people don't understand what non-coherent means and think they're > supporting it when they're not. > > dma_alloc_manual_flushing()? That sounds pretty awkward.. > > > As a follow up I plan to move the implementation of the > > DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given > > that is also is a fundamentally non coherent allocation. The replacement > > for that flag would then return a struct page, as it is allowed to > > actually return pages without a kernel mapping as the name suggested > > (although most of the time they will actually have a kernel mapping..) > > If the page doesn't have a kernel mapping, shouldn't it return a PFN > or a phys_addr? Most APIs we'll feed it into need a struct page. The difference is just that it can be a highmem page. And if we want to get fancy we could change the kernel mapping to PROT_NONE eventually. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: a saner API for allocating DMA addressable pages v2
On Mon, Sep 14, 2020 at 04:44:16PM +0200, Christoph Hellwig wrote: > I'm still a little unsure about the API naming, as alloc_pages sort of > implies a struct page return value, but we return a kernel virtual > address. Erm ... dma_alloc_pages() returns a struct page, so is this sentence stale? >From patch 14: +struct page *dma_alloc_pages(struct device *dev, size_t size, + dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp); > The other alternative would be to name the API > dma_alloc_noncoherent, but the whole non-coherent naming seems to put > people off. You say that like it's a bad thing. I think the problem is more that people don't understand what non-coherent means and think they're supporting it when they're not. dma_alloc_manual_flushing()? > As a follow up I plan to move the implementation of the > DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given > that is also is a fundamentally non coherent allocation. The replacement > for that flag would then return a struct page, as it is allowed to > actually return pages without a kernel mapping as the name suggested > (although most of the time they will actually have a kernel mapping..) If the page doesn't have a kernel mapping, shouldn't it return a PFN or a phys_addr? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
a saner API for allocating DMA addressable pages v2
Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a little unsure about the API naming, as alloc_pages sort of implies a struct page return value, but we return a kernel virtual address. The other alternative would be to name the API dma_alloc_noncoherent, but the whole non-coherent naming seems to put people off. As a follow up I plan to move the implementation of the DMA_ATTR_NO_KERNEL_MAPPING flag over to this framework as well, given that is also is a fundamentally non coherent allocation. The replacement for that flag would then return a struct page, as it is allowed to actually return pages without a kernel mapping as the name suggested (although most of the time they will actually have a kernel mapping..) In addition to the conversions of the existing non-coherent DMA users, I've also added a patch to convert the firewire ohci driver to use the new dma_alloc_pages API. Note that I haven't carried over any Tested-by: tags for the noncoherent allocation conversions as there was a bit of a patch reshuffle, but the result should be the same. The first patch is queued up for 5.9 in the media tree, but included here for completeness. A git tree is available here: git://git.infradead.org/users/hch/misc.git dma_alloc_pages Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma_alloc_pages Changes since v1: - rebased on the latests dma-mapping tree, which merged many of the cleanups - fix an argument passing typo in 53c700, caught by sparse - rename a few macro arguments in 53c700 - pass the right device to the DMA API in the lib82596 drivers - fix memory ownershiptransfers in sgiseeq - better document what a page in the direct kernel mapping means - split into dma_alloc_pages that returns a struct page and is in the direct mapping vs dma_alloc_noncoherent that can be vmapped - conver the firewire ohci driver to dma_alloc_pages Diffstat: ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
