From patchwork Thu Aug 1 08:25:05 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baruch Siach X-Patchwork-Id: 13749964 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 907B0C49EA1 for ; Thu, 1 Aug 2024 08:26:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=GXGqFvF9FigHS/WIbogqirivQyp2qY7Vokm9IbHHV0g=; b=z8k+24mDDnebmzBFmBj9TN85lx eSBg0ZuFN+dm67ZjyriQnCBLvFNo/yr21LXd+S3QQTAjsoPwCZQ9979zpXkqUSuU/GJnfyl6+zvtZ jEOvc65sD24cQsDSRqKJr2kVOo0JOxD5ZDriTaPtynq58fdh1bq2gfEi6T4RIW7bPI3M7n4bz9/SQ aIHSq48eaW7Z9FXWVFZxu9TFSuILqhGRqoPA8cFOJ4t6YJOMzXSa+AsnTxENuBdWeiV1NSKuStx9T LdC4WV+R2dUFleZtPkSFcaoC9Dp1eVcWwh+uhuIfsQy2d9n5G6Oymc3Hq1x/Ao37I1IFPuGTK8pM7 HpLLdWyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZR8M-00000004LQv-40Jn; Thu, 01 Aug 2024 08:26:02 +0000 Received: from golan.tkos.co.il ([84.110.109.230] helo=mail.tkos.co.il) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZR7s-00000004LGE-2Yjk for linux-arm-kernel@lists.infradead.org; Thu, 01 Aug 2024 08:25:34 +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 2C0424403E6; Thu, 1 Aug 2024 11:24:05 +0300 (IDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1722500645; bh=e4Yj33YrCMXIAhWSQdxNKN5zPpV1PvwBwZyzghUIBMk=; h=From:To:Cc:Subject:Date:From; b=MO+oof9hDinlwTZLphphkO6pelfCsHxYxJT4C+Os5kSj1t+43czch0I6u23S4KUfu PfGWEk7NoZj3A9BJoFch2FAl4appafP9F83imsHL1OdV1bSejsH4eVEanTVffDe6JX QlIAMEMHeKOJRgrcMIDYtDxc1iCrHYRJMGRJxsGGGoupMtfZ32BCKXetYX8E13E9fW ODXffujw3tqQNWsuIT0SR4/yG8AAIcYni+NuPF0i0ugO+JcpU3BxcQwJKqv0B/ylce rD3xBWePHo3b0Nwf/hetxL7yfuEL91j/d4ktrcDmk6HlKjpyNskSqTdJwkYgJtpnyJ j1T+l6rnBLP8w== From: Baruch Siach To: Christoph Hellwig , Marek Szyprowski , Catalin Marinas , Will Deacon Cc: Baruch Siach , Robin Murphy , iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, =?utf-8?b?UGV0ciBUZXNhxZnDrWs=?= , Ramon Fried , Elad Nachman Subject: [PATCH v4 0/2] dma: support DMA zone starting above 4GB Date: Thu, 1 Aug 2024 11:25:05 +0300 Message-ID: X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240801_012533_102409_3FA8E89A X-CRM114-Status: GOOD ( 14.54 ) 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 DMA zones code assumes that DMA lower limit is zero. When there is no RAM below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire RAM[0]. My target platform has RAM starting at 32GB. Devices with 30-bit DMA mask are mapped to 1GB at the bottom of RAM, between 32GB - 33GB. DMA zone over the entire RAM breaks DMA allocation for these devices. In response to a previous RFC hack[1] Catalin Marinas suggested to add a separate offset value as base address for the DMA zone, and then refined the suggestion to use start of RAM[3]. This series attempts to implement that suggestion. With this series applied, the DMA zone covers the right RAM range for my platform. v4: * Drop last patch. zone_dma_limit includes RAM base address. * Adjust DMA zone selection in swiotlb as well. * Don't change max_zone_phys() behaviour * Update code to fallback to DMA zone when zone_dma_limit > DMA_BIT_MASK(32) v3: * Rebase on v6.11-rc1. * Drop zone_dma_base. Use memblock_start_of_DRAM() instead. * Drop DT patches. Low DMA range limit no longer needed. * Add patch to improve dma_direct_optimal_gfp_mask() heuristics as Catalin suggested. RFC v2: * Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to simplify subsequent patches * Test on real hardware RFC v1: https://lore.kernel.org/all/cover.1703683642.git.baruch@tkos.co.il/ [0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the max_zone_phys() calculation") [1] https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.baruch@tkos.co.il/ [2] https://lore.kernel.org/all/ZZ2HnHJV3gdzu1Aj@arm.com/ [3] https://lore.kernel.org/all/ZnH-VU2iz9Q2KLbr@arm.com/ Baruch Siach (1): dma: improve DMA zone selection Catalin Marinas (1): dma: replace zone_dma_bits by zone_dma_limit arch/arm64/mm/init.c | 30 +++++++++++++++--------------- arch/powerpc/mm/mem.c | 9 ++++----- arch/s390/mm/init.c | 2 +- include/linux/dma-direct.h | 2 +- kernel/dma/direct.c | 10 +++++----- kernel/dma/pool.c | 5 +++-- kernel/dma/swiotlb.c | 6 +++--- 7 files changed, 32 insertions(+), 32 deletions(-) base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b