* provide in-place uncached remapping for dma-direct (resend) @ 2020-02-20 17:01 Christoph Hellwig 2020-02-20 17:01 ` [PATCH 1/2] dma-mapping: support setting memory uncached in place Christoph Hellwig 2020-02-20 17:01 ` [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator Christoph Hellwig 0 siblings, 2 replies; 8+ messages in thread From: Christoph Hellwig @ 2020-02-20 17:01 UTC (permalink / raw) To: Jonas Bonn, Stefan Kristiansson, Stafford Horne Cc: Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel Hi all, this series provides support for remapping places uncached in-place in the generic dma-direct code, and moves openrisc over from its own in-place remapping scheme. The arm64 folks also had interest in such a scheme to avoid problems with speculating into cache aliases. Also all architectures that always use small page mappings for the kernel and have non-coherent DMA should look into enabling this scheme, as it is much more efficient than the vmap remapping. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] dma-mapping: support setting memory uncached in place 2020-02-20 17:01 provide in-place uncached remapping for dma-direct (resend) Christoph Hellwig @ 2020-02-20 17:01 ` Christoph Hellwig 2020-02-20 17:21 ` Robin Murphy 2020-02-20 17:01 ` [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator Christoph Hellwig 1 sibling, 1 reply; 8+ messages in thread From: Christoph Hellwig @ 2020-02-20 17:01 UTC (permalink / raw) To: Jonas Bonn, Stefan Kristiansson, Stafford Horne Cc: Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel We currently only support remapping memory as uncached through vmap or a magic uncached segment provided by some architectures. But there is a simpler and much better way available on some architectures where we can just remap the memory in place. The advantages are: 1) no aliasing is possible, which prevents speculating into the cached alias 2) there is no need to allocate new ptes and thus no need for a special pre-allocated pool of memory that can be used with GFP_ATOMIC DMA allocations The downside is that architectures must provide a way to set arbitrary pages uncached in the kernel mapping, which might not be possible on architecture that have a special implicit kernel mapping, and requires splitting of huge page kernel mappings where they exist. Signed-off-by: Christoph Hellwig <hch@lst.de> --- include/linux/dma-noncoherent.h | 3 +++ kernel/dma/Kconfig | 8 ++++++++ kernel/dma/direct.c | 28 ++++++++++++++++++---------- 3 files changed, 29 insertions(+), 10 deletions(-) diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h index ca9b5770caee..0820ec58f119 100644 --- a/include/linux/dma-noncoherent.h +++ b/include/linux/dma-noncoherent.h @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size) void *uncached_kernel_address(void *addr); void *cached_kernel_address(void *addr); +int arch_dma_set_uncached(void *cpu_addr, size_t size); +void arch_dma_clear_uncached(void *cpu_addr, size_t size); + #endif /* _LINUX_DMA_NONCOHERENT_H */ diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 4c103a24e380..7bc0b77f1243 100644 --- a/kernel/dma/Kconfig +++ b/kernel/dma/Kconfig @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP bool select DMA_REMAP +# +# Should be selected if the architecture can remap memory from the page +# allocator and CMA as uncached and provides the arch_dma_set_uncached and +# arch_dma_clear_uncached helpers +# +config ARCH_HAS_DMA_SET_UNCACHED + bool + config DMA_CMA bool "DMA Contiguous Memory Allocator" depends on HAVE_DMA_CONTIGUOUS && CMA diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 6af7ae83c4ad..73fe65a4cbc0 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size), dma_pgprot(dev, PAGE_KERNEL, attrs), __builtin_return_address(0)); - if (!ret) { - dma_free_contiguous(dev, page, size); - return ret; - } - + if (!ret) + goto out_free_pages; memset(ret, 0, size); goto done; } @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, * so log an error and fail. */ dev_info(dev, "Rejecting highmem page from CMA.\n"); - dma_free_contiguous(dev, page, size); - return NULL; + goto out_free_pages; } ret = page_address(page); @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, memset(ret, 0, size); - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && - dma_alloc_need_uncached(dev, attrs)) { + if (dma_alloc_need_uncached(dev, attrs)) { arch_dma_prep_coherent(page, size); - ret = uncached_kernel_address(ret); + + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) { + if (!arch_dma_set_uncached(ret, size)) + goto out_free_pages; + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) { + ret = uncached_kernel_address(ret); + } } done: if (force_dma_unencrypted(dev)) @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, else *dma_handle = phys_to_dma(dev, page_to_phys(page)); return ret; +out_free_pages: + dma_free_contiguous(dev, page, size); + return NULL; } void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr, @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr, if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) vunmap(cpu_addr); + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) + arch_dma_clear_uncached(cpu_addr, size); dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size); } @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) { if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) && !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && dma_alloc_need_uncached(dev, attrs)) return arch_dma_alloc(dev, size, dma_handle, gfp, attrs); @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size, void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs) { if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) && !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && dma_alloc_need_uncached(dev, attrs)) arch_dma_free(dev, size, cpu_addr, dma_addr, attrs); -- 2.24.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] dma-mapping: support setting memory uncached in place 2020-02-20 17:01 ` [PATCH 1/2] dma-mapping: support setting memory uncached in place Christoph Hellwig @ 2020-02-20 17:21 ` Robin Murphy 2020-02-21 14:16 ` Christoph Hellwig 0 siblings, 1 reply; 8+ messages in thread From: Robin Murphy @ 2020-02-20 17:21 UTC (permalink / raw) To: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson, Stafford Horne Cc: Marek Szyprowski, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel On 20/02/2020 5:01 pm, Christoph Hellwig wrote: > We currently only support remapping memory as uncached through vmap > or a magic uncached segment provided by some architectures. But there > is a simpler and much better way available on some architectures where > we can just remap the memory in place. The advantages are: > > 1) no aliasing is possible, which prevents speculating into the > cached alias > 2) there is no need to allocate new ptes and thus no need for a special > pre-allocated pool of memory that can be used with GFP_ATOMIC DMA > allocations > > The downside is that architectures must provide a way to set arbitrary > pages uncached in the kernel mapping, which might not be possible on > architecture that have a special implicit kernel mapping, and requires > splitting of huge page kernel mappings where they exist. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > include/linux/dma-noncoherent.h | 3 +++ > kernel/dma/Kconfig | 8 ++++++++ > kernel/dma/direct.c | 28 ++++++++++++++++++---------- > 3 files changed, 29 insertions(+), 10 deletions(-) > > diff --git a/include/linux/dma-noncoherent.h b/include/linux/dma-noncoherent.h > index ca9b5770caee..0820ec58f119 100644 > --- a/include/linux/dma-noncoherent.h > +++ b/include/linux/dma-noncoherent.h > @@ -111,4 +111,7 @@ static inline void arch_dma_prep_coherent(struct page *page, size_t size) > void *uncached_kernel_address(void *addr); > void *cached_kernel_address(void *addr); > > +int arch_dma_set_uncached(void *cpu_addr, size_t size); > +void arch_dma_clear_uncached(void *cpu_addr, size_t size); > + > #endif /* _LINUX_DMA_NONCOHERENT_H */ > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig > index 4c103a24e380..7bc0b77f1243 100644 > --- a/kernel/dma/Kconfig > +++ b/kernel/dma/Kconfig > @@ -83,6 +83,14 @@ config DMA_DIRECT_REMAP > bool > select DMA_REMAP > > +# > +# Should be selected if the architecture can remap memory from the page > +# allocator and CMA as uncached and provides the arch_dma_set_uncached and > +# arch_dma_clear_uncached helpers > +# > +config ARCH_HAS_DMA_SET_UNCACHED > + bool > + > config DMA_CMA > bool "DMA Contiguous Memory Allocator" > depends on HAVE_DMA_CONTIGUOUS && CMA > diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c > index 6af7ae83c4ad..73fe65a4cbc0 100644 > --- a/kernel/dma/direct.c > +++ b/kernel/dma/direct.c > @@ -169,11 +169,8 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, > ret = dma_common_contiguous_remap(page, PAGE_ALIGN(size), > dma_pgprot(dev, PAGE_KERNEL, attrs), > __builtin_return_address(0)); > - if (!ret) { > - dma_free_contiguous(dev, page, size); > - return ret; > - } > - > + if (!ret) > + goto out_free_pages; > memset(ret, 0, size); > goto done; > } > @@ -186,8 +183,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, > * so log an error and fail. > */ > dev_info(dev, "Rejecting highmem page from CMA.\n"); > - dma_free_contiguous(dev, page, size); > - return NULL; > + goto out_free_pages; > } > > ret = page_address(page); > @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, > > memset(ret, 0, size); > > - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && > - dma_alloc_need_uncached(dev, attrs)) { > + if (dma_alloc_need_uncached(dev, attrs)) { > arch_dma_prep_coherent(page, size); > - ret = uncached_kernel_address(ret); > + > + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) { > + if (!arch_dma_set_uncached(ret, size)) > + goto out_free_pages; > + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) { > + ret = uncached_kernel_address(ret); Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could work for both cases (with arch_dma_clear_uncached() being a no-op for segments). Robin. > + } > } > done: > if (force_dma_unencrypted(dev)) > @@ -207,6 +208,9 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, > else > *dma_handle = phys_to_dma(dev, page_to_phys(page)); > return ret; > +out_free_pages: > + dma_free_contiguous(dev, page, size); > + return NULL; > } > > void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr, > @@ -230,6 +234,8 @@ void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr, > > if (IS_ENABLED(CONFIG_DMA_REMAP) && is_vmalloc_addr(cpu_addr)) > vunmap(cpu_addr); > + else if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) > + arch_dma_clear_uncached(cpu_addr, size); > > dma_free_contiguous(dev, dma_direct_to_page(dev, dma_addr), size); > } > @@ -238,6 +244,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, > dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) > { > if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && > + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) && > !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && > dma_alloc_need_uncached(dev, attrs)) > return arch_dma_alloc(dev, size, dma_handle, gfp, attrs); > @@ -248,6 +255,7 @@ void dma_direct_free(struct device *dev, size_t size, > void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs) > { > if (!IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && > + !IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) && > !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) && > dma_alloc_need_uncached(dev, attrs)) > arch_dma_free(dev, size, cpu_addr, dma_addr, attrs); > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] dma-mapping: support setting memory uncached in place 2020-02-20 17:21 ` Robin Murphy @ 2020-02-21 14:16 ` Christoph Hellwig 0 siblings, 0 replies; 8+ messages in thread From: Christoph Hellwig @ 2020-02-21 14:16 UTC (permalink / raw) To: Robin Murphy Cc: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson, Stafford Horne, Marek Szyprowski, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel On Thu, Feb 20, 2020 at 05:21:35PM +0000, Robin Murphy wrote: >> @@ -196,10 +192,15 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size, >> memset(ret, 0, size); >> - if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT) && >> - dma_alloc_need_uncached(dev, attrs)) { >> + if (dma_alloc_need_uncached(dev, attrs)) { >> arch_dma_prep_coherent(page, size); >> - ret = uncached_kernel_address(ret); >> + >> + if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED)) { >> + if (!arch_dma_set_uncached(ret, size)) >> + goto out_free_pages; >> + } else if (IS_ENABLED(CONFIG_ARCH_HAS_UNCACHED_SEGMENT)) { >> + ret = uncached_kernel_address(ret); > > Hmm, would we actually need to keep ARCH_HAS_UNCACHED_SEGMENT? If > arch_dma_set_uncached() returned void*/ERR_PTR instead, then it could work > for both cases (with arch_dma_clear_uncached() being a no-op for segments). Yes, I think so. I was a little worried about what to do with cached_kernel_address() in that scheme, but it turns out with the recent round of dma-direct cleanup that is actually entirely unused now. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator 2020-02-20 17:01 provide in-place uncached remapping for dma-direct (resend) Christoph Hellwig 2020-02-20 17:01 ` [PATCH 1/2] dma-mapping: support setting memory uncached in place Christoph Hellwig @ 2020-02-20 17:01 ` Christoph Hellwig 2020-02-21 22:14 ` Stafford Horne 1 sibling, 1 reply; 8+ messages in thread From: Christoph Hellwig @ 2020-02-20 17:01 UTC (permalink / raw) To: Jonas Bonn, Stefan Kristiansson, Stafford Horne Cc: Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel Switch openrisc to use the dma-direct allocator and just provide the hooks for setting memory uncached or cached. Signed-off-by: Christoph Hellwig <hch@lst.de> --- arch/openrisc/Kconfig | 1 + arch/openrisc/kernel/dma.c | 51 +++++--------------------------------- 2 files changed, 7 insertions(+), 45 deletions(-) diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig index 1928e061ff96..041fff4326dc 100644 --- a/arch/openrisc/Kconfig +++ b/arch/openrisc/Kconfig @@ -7,6 +7,7 @@ config OPENRISC def_bool y select ARCH_32BIT_OFF_T + select ARCH_HAS_DMA_SET_UNCACHED select ARCH_HAS_SYNC_DMA_FOR_DEVICE select OF select OF_EARLY_FLATTREE diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c index adec711ad39d..c73d2b3ae267 100644 --- a/arch/openrisc/kernel/dma.c +++ b/arch/openrisc/kernel/dma.c @@ -11,8 +11,6 @@ * Copyright (C) 2010-2011 Jonas Bonn <jonas@southpole.se> * * DMA mapping callbacks... - * As alloc_coherent is the only DMA callback being used currently, that's - * the only thing implemented properly. The rest need looking into... */ #include <linux/dma-noncoherent.h> @@ -67,62 +65,25 @@ static const struct mm_walk_ops clear_nocache_walk_ops = { .pte_entry = page_clear_nocache, }; -/* - * Alloc "coherent" memory, which for OpenRISC means simply uncached. - * - * This function effectively just calls __get_free_pages, sets the - * cache-inhibit bit on those pages, and makes sure that the pages are - * flushed out of the cache before they are used. - * - * If the NON_CONSISTENT attribute is set, then this function just - * returns "normal", cachable memory. - * - * There are additional flags WEAK_ORDERING and WRITE_COMBINE to take - * into consideration here, too. All current known implementations of - * the OR1K support only strongly ordered memory accesses, so that flag - * is being ignored for now; uncached but write-combined memory is a - * missing feature of the OR1K. - */ -void * -arch_dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, - gfp_t gfp, unsigned long attrs) +int arch_dma_set_uncached(void *cpu_addr, size_t size) { - unsigned long va; - void *page; - - page = alloc_pages_exact(size, gfp | __GFP_ZERO); - if (!page) - return NULL; - - /* This gives us the real physical address of the first page. */ - *dma_handle = __pa(page); - - va = (unsigned long)page; + unsigned long va = (unsigned long)cpu_addr; /* * We need to iterate through the pages, clearing the dcache for * them and setting the cache-inhibit bit. */ - if (walk_page_range(&init_mm, va, va + size, &set_nocache_walk_ops, - NULL)) { - free_pages_exact(page, size); - return NULL; - } - - return (void *)va; + return walk_page_range(&init_mm, va, va + size, &set_nocache_walk_ops, + NULL); } -void -arch_dma_free(struct device *dev, size_t size, void *vaddr, - dma_addr_t dma_handle, unsigned long attrs) +void arch_dma_clear_uncached(void *cpu_addr, size_t size) { - unsigned long va = (unsigned long)vaddr; + unsigned long va = (unsigned long)cpu_addr; /* walk_page_range shouldn't be able to fail here */ WARN_ON(walk_page_range(&init_mm, va, va + size, &clear_nocache_walk_ops, NULL)); - - free_pages_exact(vaddr, size); } void arch_sync_dma_for_device(phys_addr_t addr, size_t size, -- 2.24.1 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator 2020-02-20 17:01 ` [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator Christoph Hellwig @ 2020-02-21 22:14 ` Stafford Horne 2020-02-24 19:45 ` Christoph Hellwig 0 siblings, 1 reply; 8+ messages in thread From: Stafford Horne @ 2020-02-21 22:14 UTC (permalink / raw) To: Christoph Hellwig Cc: Jonas Bonn, Stefan Kristiansson, Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel On Thu, Feb 20, 2020 at 09:01:39AM -0800, Christoph Hellwig wrote: > Switch openrisc to use the dma-direct allocator and just provide the > hooks for setting memory uncached or cached. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Stafford Horne <shorne@gmail.com> Also, I test booted openrisc with linux 5.5 + these patches. Thanks for continuing to shrink my code base. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator 2020-02-21 22:14 ` Stafford Horne @ 2020-02-24 19:45 ` Christoph Hellwig 2020-02-25 10:10 ` Stafford Horne 0 siblings, 1 reply; 8+ messages in thread From: Christoph Hellwig @ 2020-02-24 19:45 UTC (permalink / raw) To: Stafford Horne Cc: Christoph Hellwig, Jonas Bonn, Stefan Kristiansson, Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel On Sat, Feb 22, 2020 at 07:14:47AM +0900, Stafford Horne wrote: > On Thu, Feb 20, 2020 at 09:01:39AM -0800, Christoph Hellwig wrote: > > Switch openrisc to use the dma-direct allocator and just provide the > > hooks for setting memory uncached or cached. > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > Reviewed-by: Stafford Horne <shorne@gmail.com> > > Also, I test booted openrisc with linux 5.5 + these patches. Thanks for > continuing to shrink my code base. I just resent a new version that changes how the hooks work based on feedback from Robin. Everything should work as-is, but if you have some time to retest that would be great. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator 2020-02-24 19:45 ` Christoph Hellwig @ 2020-02-25 10:10 ` Stafford Horne 0 siblings, 0 replies; 8+ messages in thread From: Stafford Horne @ 2020-02-25 10:10 UTC (permalink / raw) To: Christoph Hellwig Cc: Jonas Bonn, Stefan Kristiansson, Marek Szyprowski, Robin Murphy, Will Deacon, Mark Rutland, openrisc, iommu, linux-arm-kernel, linux-arch, linux-kernel On Mon, Feb 24, 2020 at 08:45:28PM +0100, Christoph Hellwig wrote: > On Sat, Feb 22, 2020 at 07:14:47AM +0900, Stafford Horne wrote: > > On Thu, Feb 20, 2020 at 09:01:39AM -0800, Christoph Hellwig wrote: > > > Switch openrisc to use the dma-direct allocator and just provide the > > > hooks for setting memory uncached or cached. > > > > > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > > > Reviewed-by: Stafford Horne <shorne@gmail.com> > > > > Also, I test booted openrisc with linux 5.5 + these patches. Thanks for > > continuing to shrink my code base. > > I just resent a new version that changes how the hooks work based on > feedback from Robin. Everything should work as-is, but if you have > some time to retest that would be great. No problem. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-02-25 10:10 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-02-20 17:01 provide in-place uncached remapping for dma-direct (resend) Christoph Hellwig 2020-02-20 17:01 ` [PATCH 1/2] dma-mapping: support setting memory uncached in place Christoph Hellwig 2020-02-20 17:21 ` Robin Murphy 2020-02-21 14:16 ` Christoph Hellwig 2020-02-20 17:01 ` [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator Christoph Hellwig 2020-02-21 22:14 ` Stafford Horne 2020-02-24 19:45 ` Christoph Hellwig 2020-02-25 10:10 ` Stafford Horne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).