Re: [PATCH 05/15] h8300, nds32, openrisc: simplify detection of memory extents
On Tue, Jul 28, 2020 at 08:11:43AM +0300, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Instead of traversing memblock.memory regions to find memory_start and
> memory_end, simply query memblock_{start,end}_of_DRAM().
>
> Signed-off-by: Mike Rapoport
> ---
> arch/h8300/kernel/setup.c| 8 +++-
> arch/nds32/kernel/setup.c| 8 ++--
> arch/openrisc/kernel/setup.c | 9 ++---
> 3 files changed, 7 insertions(+), 18 deletions(-)
Hi Mike,
For the openrisc part:
Acked-by: Stafford Horne
> --- a/arch/openrisc/kernel/setup.c
> +++ b/arch/openrisc/kernel/setup.c
> @@ -48,17 +48,12 @@ static void __init setup_memory(void)
> unsigned long ram_start_pfn;
> unsigned long ram_end_pfn;
> phys_addr_t memory_start, memory_end;
> - struct memblock_region *region;
>
> memory_end = memory_start = 0;
>
> /* Find main memory where is the kernel, we assume its the only one */
> - for_each_memblock(memory, region) {
> - memory_start = region->base;
> - memory_end = region->base + region->size;
> - printk(KERN_INFO "%s: Memory: 0x%x-0x%x\n", __func__,
> -memory_start, memory_end);
> - }
> + memory_start = memblock_start_of_DRAM();
> + memory_end = memblock_end_of_DRAM();
>
> if (!memory_end) {
> panic("No memory!");
> --
> 2.26.2
>
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator
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 > > > > Reviewed-by: Stafford Horne > > > > 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. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 5/5] openrisc: use the generic in-place uncached DMA allocator
On Mon, Feb 24, 2020 at 11:44:45AM -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 Reviewed-by: Stafford Horne I also test booted this series with linux 5.5 on my OpenRISC target. There are no issues. Note, I had an issue with patch 3/5 not cleanly applying with 'git am' but it worked fine using just patch, I didn't get any other details. -Stafford ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 2/2] openrisc: use the generic in-place uncached DMA allocator
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 Reviewed-by: Stafford Horne Also, I test booted openrisc with linux 5.5 + these patches. Thanks for continuing to shrink my code base. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3/7] openrisc: remove the partial DMA_ATTR_NON_CONSISTENT support
On Fri, Jun 14, 2019 at 04:44:27PM +0200, Christoph Hellwig wrote:
> The openrisc DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
> does not provide a cache_sync operation. This means any user of it
> will never be able to actually transfer cache ownership and thus cause
> coherency bugs.
The below looks good. I am always happy to what looks like legacy copy & paste
cruft.
Acked-by: Stafford Horne
> Signed-off-by: Christoph Hellwig
> ---
> arch/openrisc/kernel/dma.c | 22 +-
> 1 file changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/arch/openrisc/kernel/dma.c b/arch/openrisc/kernel/dma.c
> index f79457cb3741..9f25fd0fbb5d 100644
> --- a/arch/openrisc/kernel/dma.c
> +++ b/arch/openrisc/kernel/dma.c
> @@ -98,15 +98,13 @@ arch_dma_alloc(struct device *dev, size_t size,
> dma_addr_t *dma_handle,
>
> va = (unsigned long)page;
>
> - if ((attrs & DMA_ATTR_NON_CONSISTENT) == 0) {
> - /*
> - * We need to iterate through the pages, clearing the dcache for
> - * them and setting the cache-inhibit bit.
> - */
> - if (walk_page_range(va, va + size, &walk)) {
> - free_pages_exact(page, size);
> - return NULL;
> - }
> + /*
> + * We need to iterate through the pages, clearing the dcache for
> + * them and setting the cache-inhibit bit.
> + */
> + if (walk_page_range(va, va + size, &walk)) {
> + free_pages_exact(page, size);
> + return NULL;
> }
>
> return (void *)va;
> @@ -122,10 +120,8 @@ arch_dma_free(struct device *dev, size_t size, void
> *vaddr,
> .mm = &init_mm
> };
>
> - if ((attrs & DMA_ATTR_NON_CONSISTENT) == 0) {
> - /* walk_page_range shouldn't be able to fail here */
> - WARN_ON(walk_page_range(va, va + size, &walk));
> - }
> + /* walk_page_range shouldn't be able to fail here */
> + WARN_ON(walk_page_range(va, va + size, &walk));
>
> free_pages_exact(vaddr, size);
> }
> --
> 2.20.1
>
Re: use the generic dma-noncoherent code for openrisc
On Thu, Jul 19, 2018 at 06:02:28AM -0700, Christoph Hellwig wrote: > Hi Openrisc maintainers, > > can you review these patches to switch openrisc to use the generic > dma-noncoherent code? All the requirements are in mainline already > and we've switched various architectures over to it already. Hi Christoph, Thanks for this, these look good to me. I don't know much about the dma infrastructure in the kernel to tell the truth, but the patches do maintain the original cache flushing and invalidation core logic and I don't see any problems. I have applied these and ran my regular tests, but I don't really have any DMA hardware so the testing doesn't mean much. For upstreaming, do you want me to send these through the openrisc tree, or do you want to send with the dma tree? -Stafford ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
