From patchwork Tue Apr 9 06:17:58 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baruch Siach X-Patchwork-Id: 13621867 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0B15AC67861 for ; Tue, 9 Apr 2024 06:18:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ApTumlmfDJc1g+HQVGIL1Sh1h9qdHi6uSAS5cq6jPm4=; b=xlWhwU4NN4C5FN qvK4sdlV8mOdz6eoA9i5E36k90W0JS5VP9GPoq/A5PWQcS/gBbpKs2afXkOq2+rMHkylgBR38jeO0 +uOurNL/q81UTgoLIgjcooKuWJttpWwCYOInCZGotm4mw3mJEKe5WMk+b2lf9NWwO6vh1HriArEaq gW8/qhL9nCBCg1WLRCAv8/rtXB4ikNV6/WEcx5Kjz6qen8uc+1xewJ/1zndjnJF1JMSyJMoD4gsnK xobG+BOGsIQ4dxjA20FNp21Ne5HnadWUKyLbI/LG2tJOb/apgqlRoxb+fPFkFDx6grn8JVn98TonO Y7wYx4J7GW+GHtxR0VHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ru4of-00000000YCe-3eCg; Tue, 09 Apr 2024 06:18:45 +0000 Received: from mail.tkos.co.il ([84.110.109.230]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ru4oI-00000000Y4x-1Fbb for linux-arm-kernel@lists.infradead.org; Tue, 09 Apr 2024 06:18:31 +0000 Received: from tarshish.tkos.co.il (unknown [10.0.8.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.tkos.co.il (Postfix) with ESMTPS id 48858440459; Tue, 9 Apr 2024 09:17:45 +0300 (IDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1712643465; bh=R7K6bnEO9GvrFuZ5cBFijMFOruRQKScFkxZi8ojrTRc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SUexIQz8PPD4zBDvys8qW4vICsMoWwrv/Gnfl1XbfryJUgAXmhmvGF4hBnq0rrs9u dJkOWwvsTTJp49f/96CsJAOe7SVxyJYmn5IBK2tBlDDM4FQfyhOmfOsb7RCYJ7mGFQ Z4pxD5uzbWSNMoTrZSEaMPdDEDESwEICV6BGapb1jO3WPznEXPBWQu8Uyy1eK7bhgh VJ2vFMvDL4Ab8KkyRmwnBkXCZkJWEUa948eREug5DCra0Vd7D1+U+jx3rFF10m0DVj SXe8/7ivvfBvgkUsoa+sOWN7M+3AT9z4tW1kFS6QMaNP60x6miJmpnTgoukgFTIE6O pV1sS2D6zWaJw== From: Baruch Siach To: Christoph Hellwig , Marek Szyprowski , Rob Herring , Saravana Kannan , Catalin Marinas , Will Deacon Cc: Baruch Siach , Robin Murphy , iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, =?utf-8?b?UGV0?= =?utf-8?b?ciBUZXNhxZnDrWs=?= , Ramon Fried , Elad Nachman Subject: [PATCH RFC v2 5/5] arm64: mm: take DMA zone offset into account Date: Tue, 9 Apr 2024 09:17:58 +0300 Message-ID: <2fa9d7954a99b018a32314b9baab25ba18504f15.1712642324.git.baruch@tkos.co.il> X-Mailer: git-send-email 2.43.0 In-Reply-To: References: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240408_231823_893093_10327A09 X-CRM114-Status: GOOD ( 14.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM when RAM starts above 32-bits. This breaks hardware with DMA area that start above 32-bits. But the commit log says that "we haven't noticed any such hardware". It turns out that such hardware does exist. One such platform has RAM starting at 32GB with an internal bus that has the following DMA limits: #address-cells = <2>; #size-cells = <2>; dma-ranges = <0x00 0xc0000000 0x08 0x00000000 0x00 0x40000000>; Devices under this bus can see 1GB of DMA range between 3GB-4GB in each device address space. This range is mapped to CPU memory at 32GB-33GB. With current code DMA allocations for devices under this bus are not limited to DMA area, leading to run-time allocation failure. Modify 'zone_dma_bits' calculation (via dt_zone_dma_bits) to only cover the actual DMA area starting at 'zone_dma_off'. Use the newly introduced 'min' parameter of of_dma_get_cpu_limits() to set 'zone_dma_off'. DMA32 zone is useless in this configuration, so make its limit the same as the DMA zone when the lower DMA limit is higher than 32-bits. The result is DMA zone that properly reflects the hardware constraints as follows: [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x0000000800000000-0x000000083fffffff] [ 0.000000] DMA32 empty [ 0.000000] Normal [mem 0x0000000840000000-0x0000000bffffffff] Suggested-by: Catalin Marinas Signed-off-by: Baruch Siach --- arch/arm64/mm/init.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 77e942ca578b..cd283ae0178d 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -128,9 +128,11 @@ static void __init zone_sizes_init(void) #ifdef CONFIG_ZONE_DMA acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address(); - of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, NULL); + of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, &zone_dma_base); zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit); arm64_dma_phys_limit = max_zone_phys(zone_dma_limit); + if (zone_dma_base > U32_MAX) + dma32_phys_limit = arm64_dma_phys_limit; max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); #endif #ifdef CONFIG_ZONE_DMA32