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 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 E1FD0C4707B for ; Thu, 18 Jan 2024 11:11:15 +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:In-reply-to: Date:Subject:Cc:To:From:References:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FxnMmGYssL8634Bo+URIFrvrMri0d4DUNU6pnp4WIP0=; b=KvXlzbSUz9mThp BmMIE5N3KuEFnyfOMz43W+uVCTd/QxjLkvmISSXDiwVs8Rb2kH9/KQy7GjuqCIBeZuAx2raAaGQqR LN9iUhW3K7eDIetEwGwYfP5BBP7FyPDqNmBdqnLkOmrqCoaEjts96JAoPU5SUO+x2alrVkC7vrTNM qakwlB1Mi4MXL0PHKt+GMc7igpuQKWmgZC+XwTn2DKX919vuCF88yfPYzyHZXuWeGdOLiWDikavlO 6LkjuU/+32Qp0D35a/webJ1LQyviNQqGaSA/7589kwc6OSazAje2i1eziZRBcc3P+x/MjBESDwy/9 gEyOdZr5TkyRNAERqXqA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rQQIB-002Ss2-1i; Thu, 18 Jan 2024 11:10:39 +0000 Received: from golan.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 1rQQI8-002Sms-05 for linux-arm-kernel@lists.infradead.org; Thu, 18 Jan 2024 11:10:38 +0000 Received: from localhost (unknown [10.0.8.2]) by mail.tkos.co.il (Postfix) with ESMTP id B46D94408C7; Thu, 18 Jan 2024 13:10:19 +0200 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1705576219; bh=GMtd0pstpQcqTleYbfyojTxp00ZU0XHSVR8HGIiOeDM=; h=References:From:To:Cc:Subject:Date:In-reply-to:From; b=muPu86A6ftu2HlsG9jhNTjR4XMmDWwggPY7ZxAaroE5GJfLGriZw3+wA9p66vm7W+ b8v5Fu/BLRu59D2qzb9u7SfoGNmDj0Pdk0GjuunjUdwgywMoSRZoioVkXDxS8M64gU hLP4ed3Dt6wUXVqgm/0NtCFzBKULdsnd2sxFrMtDwtB6YlDCFtoZjzPUN+ODHJ7JCI fgaPMmhnZzDPlDpoKLgdjQ9xW6efT57tO4cVlgk3HrJ7FH8fSJ/IIrb7B+OqebjDNK 7+E1UwyottHI3VU/1jwXOq1CcaBVwAho0Hz/mJNlsxhg3VAyMn+tef/Iokd5FkBz35 EikZ6YBQ0ROhQ== References: <30d81f73-e27e-6cc4-5458-686e3ddd2e5c@linux.com> User-agent: mu4e 1.10.8; emacs 29.1 From: Baruch Siach To: "Christoph Lameter (Ampere)" Cc: Christoph Hellwig , Marek Szyprowski , Rob Herring , Frank Rowand , Catalin Marinas , Will Deacon , Robin Murphy , iommu@lists.linux.dev, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Petr =?utf-8?B?VGVzYcWZw61r?= , Ramon Fried Subject: Re: [PATCH RFC 1/4] of: get dma area lower limit Date: Thu, 18 Jan 2024 12:59:58 +0200 In-reply-to: <30d81f73-e27e-6cc4-5458-686e3ddd2e5c@linux.com> Message-ID: <87cytyx5gf.fsf@tarshish> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240118_031036_545326_BDE1D4BC X-CRM114-Status: GOOD ( 10.60 ) 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: , 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 Hi Christoph On Wed, Jan 17 2024, Christoph Lameter (Ampere) wrote: > On Wed, 27 Dec 2023, Baruch Siach wrote: >> of_dma_get_max_cpu_address() returns the highest CPU address that >> devices can use for DMA. The implicit assumption is that all CPU >> addresses below that limit are suitable for DMA. However the >> 'dma-ranges' property this code uses also encodes a lower limit for DMA >> that is potentially non zero. > > All of memory can be used for DMA by default (==ZONE_NORMAL). ZONE_DMA defines > a special range for devices that are unable to perform DMA to all of > memory. Usually due to the lack of address bit support. > > So I guess that the platform in question here has as a general limit as to > what address spaces I/O devices can do DMA to? DMA to/from devices in bus with 'dma-ranges' property is limited to address space described in 'dma-ranges'. The arm64 platform currently uses 'dma-ranges' as a hint to set ZONE_DMA limits globally. This series is meant to make ZONE_DMA limits adjustment code work better for platforms where the lower DMA limit is above 4GB. This commit adds the ability to extract the lower limit from 'dma-ranges'. baruch -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel