Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6130144ybi; Wed, 31 Jul 2019 08:50:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzZlqNWNb0yd51/BGsjEgpeSnc2yemZXc3CyOpM9oaURjSOFxr/LHDQ4gVVojohHiEy+QtN X-Received: by 2002:a17:902:244:: with SMTP id 62mr27239980plc.243.1564588245122; Wed, 31 Jul 2019 08:50:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564588245; cv=none; d=google.com; s=arc-20160816; b=a+XlCuBmTvy4zuVHo42Fb2hJjw3SrqqWO8HPokB9OM1ffNaVctfvwviW0usSIC46DG IxTBWRRqoCCg+O0hBbu8YxhA8WytbVSp6Zx3Gfp8MQI/dR5NdwzGU5L3Gi4wd7/zSu4z plExJaPbqXUsZ2AfUnkrSZyOmsG3F+mOgJDFcb6l2Cl5ATPWF47WQ4i+DlgQbcKP5y7t YmEcLKCoGbxIneQwlHVhfju+UDlMd07ilOc1Ki55cjGyZ2i9UWKbiVEHEwihAIwqOJ67 Ha4a7TV7ysdvcZIFJFOTKti76cUv3BGGTI/9m3bPm0TnWlyftDvFwOJ4mkmrT1HUyiTM ARUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=S8bOWZs8wa2CgfkuK8HhPjYI682g9sPrNBOqzgGn9pw=; b=Bwg9FWazJS9tGQBIDOcos8v6BE+wpmt1kCa5mBupDnYg9Ildi0ByYBPwnUNvGhAEAa 71ak2EgDnkjNBVBuLB6prYPpuaNJDxgqdxE0vaRhZOFhDyCJgUjHdx4CEVak6PgHHIUn wIolVf+fPObrsJ2+06Ww5bGdmc3rRoUDKf030feTCBgrmqvSjfA25cZkzvSi5funCGr2 IpU2DZXQVcQP9GzYZveuM+Z4Y746zYeq7P0+E8DKyXaIYsSWblgFQ8cyquy868j1ur4v n3lL0P3f+prdr47RB14nJwBwBbIxvde5PdJS5mjt+OAkazhHulPXccmtKssyfWaClKU9 IXcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p15si24096860pgm.299.2019.07.31.08.50.29; Wed, 31 Jul 2019 08:50:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730253AbfGaPsK (ORCPT + 99 others); Wed, 31 Jul 2019 11:48:10 -0400 Received: from mx2.suse.de ([195.135.220.15]:50172 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1730245AbfGaPsI (ORCPT ); Wed, 31 Jul 2019 11:48:08 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id A068AAFA5; Wed, 31 Jul 2019 15:48:06 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org, Will Deacon Cc: phill@raspberryi.org, f.fainelli@gmail.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, eric@anholt.net, mbrugger@suse.com, nsaenzjulienne@suse.de, akpm@linux-foundation.org, frowand.list@gmail.com, m.szyprowski@samsung.com, linux-rpi-kernel@lists.infradead.org Subject: [PATCH 5/8] arm64: use ZONE_DMA on DMA addressing limited devices Date: Wed, 31 Jul 2019 17:47:48 +0200 Message-Id: <20190731154752.16557-6-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.22.0 In-Reply-To: <20190731154752.16557-1-nsaenzjulienne@suse.de> References: <20190731154752.16557-1-nsaenzjulienne@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org So far all arm64 devices have supported 32 bit DMA masks for their peripherals. This is not true anymore for the Raspberry Pi 4. Most of it's peripherals can only address the first GB or memory of a total of up to 4 GB. This goes against ZONE_DMA32's original intent, and breaks other subsystems as it's expected for ZONE_DMA32 to be addressable with a 32 bit mask. So it was decided to use ZONE_DMA for this specific case. Devices with with 32 bit DMA addressing support will still bypass ZONE_DMA but those who don't will create both zones. ZONE_DMA will contain the memory addressable by all the SoC's devices and ZONE_DMA32 the rest of the 32 bit addressable memory. Signed-off-by: Nicolas Saenz Julienne --- arch/arm64/Kconfig | 4 ++++ arch/arm64/mm/init.c | 38 ++++++++++++++++++++++++++++++++------ 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3adcec05b1f6..a9fd71d3bc8e 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -266,6 +266,10 @@ config GENERIC_CSUM config GENERIC_CALIBRATE_DELAY def_bool y +config ZONE_DMA + bool "Support DMA zone" if EXPERT + default y + config ZONE_DMA32 bool "Support DMA32 zone" if EXPERT default y diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 1c4ffabbe1cb..f5279ef85756 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -50,6 +50,13 @@ s64 memstart_addr __ro_after_init = -1; EXPORT_SYMBOL(memstart_addr); +/* + * We might create both a ZONE_DMA and ZONE_DMA32. ZONE_DMA is needed if there + * are periferals unable to address the first naturally aligned 4GB of ram. + * ZONE_DMA32 will be expanded to cover the rest of that memory. If such + * limitations doesn't exist only ZONE_DMA32 is created. + */ +phys_addr_t arm64_dma_phys_limit __ro_after_init; phys_addr_t arm64_dma32_phys_limit __ro_after_init; #ifdef CONFIG_KEXEC_CORE @@ -193,6 +200,9 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) { unsigned long max_zone_pfns[MAX_NR_ZONES] = {0}; +#ifdef CONFIG_ZONE_DMA + max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); +#endif #ifdef CONFIG_ZONE_DMA32 max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit); #endif @@ -207,14 +217,19 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) { struct memblock_region *reg; unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES]; + unsigned long max_dma = PFN_DOWN(arm64_dma_phys_limit); unsigned long max_dma32 = min; memset(zone_size, 0, sizeof(zone_size)); +#ifdef CONFIG_ZONE_DMA + if (max_dma) + zone_size[ZONE_DMA] = max_dma - min; +#endif /* 4GB maximum for 32-bit only capable devices */ #ifdef CONFIG_ZONE_DMA32 max_dma32 = PFN_DOWN(arm64_dma32_phys_limit); - zone_size[ZONE_DMA32] = max_dma32 - min; + zone_size[ZONE_DMA32] = max_dma32 - max_dma - min; #endif zone_size[ZONE_NORMAL] = max - max_dma32; @@ -226,11 +241,17 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max) if (start >= max) continue; - +#ifdef CONFIG_ZONE_DMA + if (start < max_dma) { + unsigned long dma_end = min_not_zero(end, max_dma); + zhole_size[ZONE_DMA] -= dma_end - start; + } +#endif #ifdef CONFIG_ZONE_DMA32 if (start < max_dma32) { - unsigned long dma_end = min(end, max_dma32); - zhole_size[ZONE_DMA32] -= dma_end - start; + unsigned long dma32_end = min(end, max_dma32); + unsigned long dma32_start = max(start, max_dma); + zhole_size[ZONE_DMA32] -= dma32_end - dma32_start; } #endif if (end > max_dma32) { @@ -418,6 +439,11 @@ void __init arm64_memblock_init(void) early_init_fdt_scan_reserved_mem(); + if (IS_ENABLED(CONFIG_ZONE_DMA)) + arm64_dma_phys_limit = max_zone_dma_phys(); + else + arm64_dma_phys_limit = 0; + /* 4GB maximum for 32-bit only capable devices */ if (IS_ENABLED(CONFIG_ZONE_DMA32)) arm64_dma32_phys_limit = max_zone_dma32_phys(); @@ -430,7 +456,7 @@ void __init arm64_memblock_init(void) high_memory = __va(memblock_end_of_DRAM() - 1) + 1; - dma_contiguous_reserve(arm64_dma32_phys_limit); + dma_contiguous_reserve(arm64_dma_phys_limit ? : arm64_dma32_phys_limit); } void __init bootmem_init(void) @@ -533,7 +559,7 @@ static void __init free_unused_memmap(void) */ void __init mem_init(void) { - if (swiotlb_force == SWIOTLB_FORCE || + if (swiotlb_force == SWIOTLB_FORCE || arm64_dma_phys_limit || max_pfn > (arm64_dma32_phys_limit >> PAGE_SHIFT)) swiotlb_init(1); else -- 2.22.0