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 352CCC3DA5D for ; Thu, 25 Jul 2024 11:49:52 +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-Type:MIME-Version: Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GeR7dXWykRgA2XlTsfJ9b9n5+W1IjzEVMCyr7PR+xQ4=; b=EXx+JBQezsELNZBh2nCbtY1irR 6uOQOVfXMhjnvfhPBp1Dd4Hm7tQ2Xe/61ZLFjvFlLug3i3T9YHFTOWbh97RUX3MnGgMy+SxjVoRGT RZddUn5U2Z7RcqmGu48HMNzgqf6HboErmtpkDKLK7pr+JvXKRyrSU3nJDHK7xS0i4hMx/ZaWgwqWe gSNNAZkUqJfujP4Gs1Flq0DNutrqFLArCtJqEWvyR6IwKNTN17+NucIu2sCQ8ow2Q6Wmu8SKu+Ws5 Fgza/9Efc/j9vOHrZg5dThaK4/G25PINIyr0TonA2IGoqTrwozXfo00IehgIS4JBFsWEvOO4F+cC0 svmY0FLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sWwyW-00000000o6r-1YM8; Thu, 25 Jul 2024 11:49:36 +0000 Received: from guitar.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 1sWwy6-00000000o4D-3Eqs for linux-arm-kernel@lists.infradead.org; Thu, 25 Jul 2024 11:49:13 +0000 Received: from localhost (unknown [10.0.8.2]) by mail.tkos.co.il (Postfix) with ESMTP id 284E14404C3; Thu, 25 Jul 2024 14:47:51 +0300 (IDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tkos.co.il; s=default; t=1721908071; bh=yE1dvBcrEBKnorpECP4pOnlN7nPfgUokWU3jR2HlwE8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bizVwSo2WQmGu0wUpHnYrd0vmUJZSj2EFi5MQvsuSsHcUPIlfFUeav8XA1ADfxEht swspOZXXy6Ab7EMunaOnm8NHsgOT9449191hCTw2/CpoAtwSwSaAwbieaI7844BSro ptDyP9e+pI/vXYmBCpx+M0RmTU+Lr81JVG8wPU3ZSwi4+YXygklxhz7lCo6Gusy58K seXAU/M/7An4QuSEy4KgL1CDRjrevZeRuLYxoakcQey6W84qW98DoLWlQoXDC09PaI 4x/s1EdCLdeCgMg6IPGd80vPUq/70SWVPgWUFJSRDxadbEb9i2o8jR+4Mi0NXSi22V /YANXGITTzdfw== From: Baruch Siach To: Catalin Marinas Cc: Christoph Hellwig , Marek Szyprowski , Rob Herring , Saravana Kannan , Will Deacon , 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, Petr =?utf-8?B?VGVzYcWZw61r?= , Ramon Fried , Elad Nachman Subject: Re: [PATCH RFC v2 2/5] of: get dma area lower limit In-Reply-To: (Catalin Marinas's message of "Tue, 18 Jun 2024 22:38:29 +0100") References: <230ea13ef8e9f576df849e1b03406184ca890ba8.1712642324.git.baruch@tkos.co.il> Date: Thu, 25 Jul 2024 14:49:01 +0300 Message-ID: <87cyn1k7yq.fsf@tarshish> MIME-Version: 1.0 Content-Type: text/plain X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240725_044911_348544_054C9B9E X-CRM114-Status: GOOD ( 14.22 ) 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 Hi Catalin, On Tue, Jun 18 2024, Catalin Marinas wrote: > On Tue, Apr 09, 2024 at 09:17:55AM +0300, 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. >> >> Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower >> limit for the same 'dma-ranges' property describing the high limit. > > I don't understand the reason for the lower limit. The way the Linux > zones work is that ZONE_DMA always starts from the start of the RAM. It > doesn't matter whether it's 0 or not, you'd not allocate below the start > of RAM anyway. If you have a device that cannot use the bottom of the > RAM, it is pretty broken and not supported by Linux. I won't argue with that assertion. My target system RAM happens to start at that the lower end of devices DMA zone, so I'm fine with skipping this patch. Just curious. What is the inherent limitation that prevents Linux from supporting DMA zone with lower limit above RAM start? Thanks, baruch -- ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -