From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 000B3C4363A for ; Thu, 22 Oct 2020 18:08:05 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7324D21531 for ; Thu, 22 Oct 2020 18:08:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fuOMQnKO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7324D21531 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=SrUzxgF45cF6egMGMwOMFk0ZGm9mE+9pbQ+xvyvKcro=; b=fuOMQnKO3BBcps32wlGnopRa4 ycy44cMhAYiSQ5IH2kwnOLCt8Icoh+kgK+TLYaS5XhKBLtdisfAAT2ZZTwtNazgPXawZKcJqXEfJT wAL2Jev4YYDX5+Q35dMdkWFrDFmpU0tIStp5j480NzVEYV6P21hVDQW0qSy3uhdWxDxqZc92GIqw6 8O7RQPY5DLkgieWPG2Cd6CIYh5Bw0a8cxdiXCwU4QZHxCiObrHjCaHgfg71izrbOYdu/4LxfPwEmZ Iest+D27yPWMzbN/aUJurgJCMGX/ttT6Xa9gHQSpEO1ZxbAEZrUQYO9epWURkqcy/XTxUmjZDgozi xrsdZeIDw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVez4-0004Bh-8W; Thu, 22 Oct 2020 18:06:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVez1-0004BG-Ti; Thu, 22 Oct 2020 18:06:40 +0000 Received: from gaia (unknown [95.145.162.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7BDE32225F; Thu, 22 Oct 2020 18:06:36 +0000 (UTC) Date: Thu, 22 Oct 2020 19:06:33 +0100 From: Catalin Marinas To: Nicolas Saenz Julienne Subject: Re: [PATCH v4 5/7] arm64: mm: Set ZONE_DMA size based on devicetree's dma-ranges Message-ID: <20201022180632.GI1229@gaia> References: <20201021123437.21538-1-nsaenzjulienne@suse.de> <20201021123437.21538-6-nsaenzjulienne@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201021123437.21538-6-nsaenzjulienne@suse.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201022_140640_311740_14F2DC69 X-CRM114-Status: GOOD ( 18.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, lorenzo.pieralisi@arm.com, will@kernel.org, linux-kernel@vger.kernel.org, jeremy.linton@arm.com, ardb@kernel.org, iommu@lists.linux-foundation.org, robh+dt@kernel.org, linux-rpi-kernel@lists.infradead.org, guohanjun@huawei.com, robin.murphy@arm.com, hch@lst.de, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Oct 21, 2020 at 02:34:35PM +0200, Nicolas Saenz Julienne wrote: > @@ -188,9 +186,11 @@ static phys_addr_t __init max_zone_phys(unsigned int zone_bits) > static void __init zone_sizes_init(unsigned long min, unsigned long max) > { > unsigned long max_zone_pfns[MAX_NR_ZONES] = {0}; > + unsigned int __maybe_unused dt_zone_dma_bits; > > #ifdef CONFIG_ZONE_DMA > - zone_dma_bits = ARM64_ZONE_DMA_BITS; > + dt_zone_dma_bits = ilog2(of_dma_get_max_cpu_address(NULL)); > + zone_dma_bits = min(32U, dt_zone_dma_bits); A thought: can we remove the min here and expand ZONE_DMA to whatever dt_zone_dma_bits says? More on this below. > arm64_dma_phys_limit = max_zone_phys(zone_dma_bits); > max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit); > #endif I was talking earlier to Ard and Robin on the ZONE_DMA32 history and the need for max_zone_phys(). This was rather theoretical, the Seattle platform has all RAM starting above 4GB and that led to an empty ZONE_DMA32 originally. The max_zone_phys() hack was meant to lift ZONE_DMA32 into the bottom of the RAM, on the assumption that such 32-bit devices would have a DMA offset hardwired. We are not aware of any such case on arm64 systems and even on Seattle, IIUC 32-bit devices only work if they are behind an SMMU (so no hardwired offset). In hindsight, it would have made more sense on platforms with RAM above 4GB to expand ZONE_DMA32 to cover the whole memory (so empty ZONE_NORMAL). Something like: diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index a53c1e0fb017..7d5e3dd85617 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -187,8 +187,12 @@ static void __init reserve_elfcorehdr(void) */ static phys_addr_t __init max_zone_phys(unsigned int zone_bits) { - phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, zone_bits); - return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM()); + phys_addr_t zone_mask = 1ULL << zone_bits; + + if (!(memblock_start_of_DRAM() & zone_mask)) + zone_mask = PHYS_ADDR_MAX; + + return min(zone_mask, memblock_end_of_DRAM()); } static void __init zone_sizes_init(unsigned long min, unsigned long max) I don't think this makes any difference for ZONE_DMA unless a broken DT or IORT reports the max CPU address below the start of DRAM. There's a minor issue if of_dma_get_max_cpu_address() matches memblock_end_of_DRAM() but they are not a power of 2. We'd be left with a bit of RAM at the end in ZONE_NORMAL due to ilog2 truncation. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel