From patchwork Wed Dec 27 15:04:24 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baruch Siach X-Patchwork-Id: 13505343 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 5C637C46CD4 for ; Wed, 27 Dec 2023 15:05:25 +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: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:In-Reply-To:References: List-Owner; bh=pfStFXe0ffSksdIyFuRTXSboP7gzZbozsHUVxKRjjYM=; b=T8G42rAyZMEzRx BWV/LER8IgsVvf+ldyzyV/omAqOEj1BfqaqYpY4zi1nIgEjNJ8GjKWd2QQTVkJDthDns94itFoYdf EEyWw5UHQCpYrtk7PZSiMp/kXW4dHTPxgYRIOaRJEGkXYp2sn5qtbL8FyhaoJ1RWJZu9Sd8nP5wvZ 4/OJWVdQe2ECDmc2o6LVYANedw9BJ/TJuGSNU0n3LINO3A/Cg1G4pVXIE0HQuF9R52k8zTPVTi/x3 Ndzcq8EG8dG7ZJiBcAMOZ5S0mj2P4jq6kNx3MxMaC4WO8lO7TUmCd7SH5ky/mHuE9EFExGW87Thm6 Oa1+IouOT2Nr+G4czP4w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rIVSq-00EtNU-1m; Wed, 27 Dec 2023 15:04:56 +0000 Received: from wiki.tkos.co.il ([84.110.109.230] helo=mail.tkos.co.il) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rIVSm-00EtKR-2O for linux-arm-kernel@lists.infradead.org; Wed, 27 Dec 2023 15:04:54 +0000 Received: from tarshish.tkos.co.il (unknown [10.0.8.3]) (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 D227F440EEA; Wed, 27 Dec 2023 17:02:42 +0200 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1703689363; bh=y8Nqn3nQCHk0ZkaLekGkm1wv2WHjXjHEQwYVdlqYNw4=; h=From:To:Cc:Subject:Date:From; b=hnJQS6E5gkFfPmVbn1G49jTHXsTmr28HHzApegH3Nh9uekRNg9Nbx84gIjPyM3meI B8aDIqGf/Cr0ZojHC7jU8qFTXNPe1NRx/vx/d9LhZ3tWMp5ciEu2nvUHwI6e7bhxza xO5ybfJWayCkTVkJEUz7SGOFZ13gv3Hq/0ZSAJl/oEJ9L5n5lcsdhrhAZr4Vb04R6Z Ho0ve/unVDMr1V8ygeQNTlk1OsaVmZse2wMAEBJBfWzOh7D/3p6mJCX8cqvXFRKrF0 hOKP8FT6xS/ukTmxy1iYpucdb2Cus5fLrSV3LUfP9lILR0YnojWWhRtCNqttY+Ez7K Ut+N1A26VCJhQ== From: Baruch Siach To: Christoph Hellwig , Marek Szyprowski , Rob Herring , Frank Rowand , 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, =?utf-8?b?UGV0ciBUZXNhxZnDrWs=?= , Ramon Fried Subject: [PATCH RFC 0/4] arm64: support DMA zone starting above 4GB Date: Wed, 27 Dec 2023 17:04:24 +0200 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-20231227_070453_264243_F7C7AEA5 X-CRM114-Status: GOOD ( 12.07 ) 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]. The platform I have has RAM starting at 32GB. Devices with 30-bit DMA mask are mapped to 1GB at the bottom of RAM, between 32GB - 33GB. A 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. This RFC series attempts to implement that suggestion. With this series applied, the DMA zone covers the right RAM range for my platform. [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/ Baruch Siach (4): of: get dma area lower limit of: unittest: add test for of_dma_get_cpu_limits() 'min' param dma-direct: add offset to zone_dma_bits arm64: mm: take DMA zone offset into account arch/arm64/mm/init.c | 18 +++++++++++++----- drivers/of/address.c | 38 +++++++++++++++++++++++++++----------- drivers/of/unittest.c | 17 ++++++++++------- include/linux/dma-direct.h | 1 + include/linux/of.h | 11 ++++++++--- kernel/dma/direct.c | 10 ++++++---- kernel/dma/pool.c | 2 +- kernel/dma/swiotlb.c | 5 +++-- 8 files changed, 69 insertions(+), 33 deletions(-)