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=-5.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham 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 B171CC32792 for ; Thu, 3 Oct 2019 08:12:05 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 88DFC21A4C for ; Thu, 3 Oct 2019 08:12: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="u7gGMl/s"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="YZaBTrmP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 88DFC21A4C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=r6TBwa8kjHtbtedpalOUddyq2/YcCMghWljb9Nhdiyo=; b=u7gGMl/s9F9vWN6ZJvS1Y7yRl pGTeXNmn71hSBMfUHgbPJSCy0sR3/JoMsIPn/maEKZ/pNz4GRKoQc2N9+VxChqJvCo2aHmcRBMWo9 EKGmu0otfNPmS6JZY4OiY91TE/2ret7VGqA1IK1np4QfZbW0rPHDpVBnMcRKgLiCdpkDMdY227O+1 ao81sWCz5alYlepptY3HfrANbrqbyjO+ZZmTqH6iH4ERuVlCyWQoMCR7kyaANWvoa3YIh75r16Z0p kSIzuaaXH3q/VnpDx7LiTg88ND34Svt/NgWWNTYZn5xLVazCAm63/0txVtR19SENTV/vWweA7bFGh AQvlJSZlQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iFwDU-00059A-SA; Thu, 03 Oct 2019 08:12:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iFwDR-00058a-Uk for linux-arm-kernel@lists.infradead.org; Thu, 03 Oct 2019 08:12:03 +0000 Received: from localhost (lfbn-1-10718-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (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 7970121A4C; Thu, 3 Oct 2019 08:12:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570090321; bh=O5XOqVtI749lX0kLTXsizlwyJ9jF3EZNAzgZ3Tj2D4A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YZaBTrmPZzkfsvkluHP0PQmgfB/mq+/dWelyLwPf0GVh7Q3OJfNLZjjv6SAcoERTC cZ0QWTzebb8L6n6es43dgA4s3rvh3bGjNxZp6l9W8J92j/ErUx8pYBq7liCOClYlXp tCpVLRlx8fuqIGiUsb7iaMfTppeMIGRLwyUGX128= Date: Thu, 3 Oct 2019 10:11:58 +0200 From: Maxime Ripard To: Thierry Reding Subject: Re: [PATCH] arm64: tegra: Set dma-ranges for memory subsystem Message-ID: <20191003081158.v72o3rilgg2bhncn@gilmour> References: <20191002154654.225690-1-thierry.reding@gmail.com> <20191002154946.GA225802@ulmo> MIME-Version: 1.0 In-Reply-To: <20191002154946.GA225802@ulmo> User-Agent: NeoMutt/20180716 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191003_011202_039208_E2126D04 X-CRM114-Status: GOOD ( 26.90 ) 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, Arnd Bergmann , Jon Hunter , Rob Herring , linux-tegra@vger.kernel.org, Robin Murphy , Georgi Djakov , linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============7023560359398560420==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7023560359398560420== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bengp4ayl5pew25c" Content-Disposition: inline --bengp4ayl5pew25c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Oct 02, 2019 at 05:49:46PM +0200, Thierry Reding wrote: > On Wed, Oct 02, 2019 at 05:46:54PM +0200, Thierry Reding wrote: > > From: Thierry Reding > > > > On Tegra194, all clients of the memory subsystem can generally address > > 40 bits of system memory. However, bit 39 has special meaning and will > > cause the memory controller to reorder sectors for block-linear buffer > > formats. This is primarily useful for graphics-related devices. > > > > Use of bit 39 must be controlled on a case-by-case basis. Buffers that > > are used with bit 39 set by one device may be used with bit 39 cleared > > by other devices. > > > > Care must be taken to allocate buffers at addresses that do not require > > bit 39 to be set. This is normally not an issue for system memory since > > there are no Tegra-based systems with enough RAM to exhaust the 39-bit > > physical address space. However, when a device is behind an IOMMU, such > > as the ARM SMMU on Tegra194, the IOMMUs input address space can cause > > IOVA allocations to happen in this region. This is for example the case > > when an operating system implements a top-down allocation policy for IO > > virtual addresses. > > > > To account for this, describe the path that memory accesses take through > > the system. Memory clients will send requests to the memory controller, > > which forwards bits [38:0] of the address either to the external memory > > controller or the SMMU, depending on the stream ID of the access. A good > > way to describe this is using the interconnects bindings, see: > > > > Documentation/devicetree/bindings/interconnect/interconnect.txt > > > > The standard "dma-mem" path is used to describe the path towards system > > memory via the memory controller. A dma-ranges property in the memory > > controller's device tree node limits the range of DMA addresses that the > > memory clients can use to bits [38:0], ensuring that bit 39 is not used. > > > > Signed-off-by: Thierry Reding > > --- > > Arnd, Rob, Robin, > > > > This is what I came up with after our discussion on this thread: > > > > [PATCH 00/11] of: dma-ranges fixes and improvements > > > > Please take a look and see if that sounds reasonable. I'm slightly > > unsure about the interconnects bindings as I used them here. According > > to the bindings there's always supposed to be a pair of interconnect > > paths, so this patch is not exactly compliant. It does work fine with > > the __of_get_dma_parent() code that Maxime introduced a couple of months > > ago and really very neatly describes the hardware. Interestingly this > > will come in handy very soon now since we're starting work on a proper > > interconnect provider (the memory controller driver is the natural fit > > for this because it has additional knobs to configure latency and > > priorities, etc.) to implement external memory frequency scaling based > > on bandwidth requests from memory clients. So this all fits together > > very nicely. But as I said, I'm not exactly sure what to add as a second > > entry in "interconnects" to make this compliant with the bindings. It definitely sounds reasonable to me :) Maxime --bengp4ayl5pew25c Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXZWtTgAKCRDj7w1vZxhR xaNSAQDPvQ0Eg3wgAsW+NG/VGPUeXTGz5HZ2S7wOq83jBXQOjwD+Mxiz+DDez9yR wEL8S5X8NUb7rZUsz+nnZoo4Dh142g4= =0yH4 -----END PGP SIGNATURE----- --bengp4ayl5pew25c-- --===============7023560359398560420== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============7023560359398560420==--