Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp6259656pxv; Thu, 29 Jul 2021 10:03:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyADf1qyxBBhz6i1/J5fnPz+BZ01MQuBxcSec2S1olFvLHh0hj8MiFxe4rBr6BIQh4tLEli X-Received: by 2002:a17:906:2755:: with SMTP id a21mr5421655ejd.488.1627578186600; Thu, 29 Jul 2021 10:03:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627578186; cv=none; d=google.com; s=arc-20160816; b=U4/yVqA6AbR7pNUPhbsLXhsAtF4r0z3iEoNGD/v8CcJn8fYlfrllupWq1yypEIctsL ImffUTzlPWGQbxiDrcE93WOlK+MbzvEz7mYoHZMo0cMLR7q1qb8ppxgYS+urg58CsNPd aVm16JZUQYNIwP+r7Dr2OttY82ofga7f+qYnlX5HXDlcWcadZor72N428Z9FptzJl64U Swbaa5zIdhCvDymm/BZ6rmJdk5VLcjhSZmFxSHOBI6FpwCggj7ofIyNGmgr9iPjEQ7UT XmdXKOPMYwXN3IaR38TX4g98iq/n/jSTAI1exWmMvrtl608Fe231jzm6xXUhm4ocCBIM f9zQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=70kNlEet96BzzBL4ATGR8UOvO/j/CO15vcPLZpy5SM8=; b=rEnpI9NLO2g7r4IBz060zHBcQjNFRIIehhLzsLjIwzMy4D95/+L6csECMF13656WWR 7jj/GPuuor15maaXcq8jA7dRtJP9A5jvQDQ96QmPKuLHuYdlXlFCctUnjZmvmr7F5m2C aSvLhUVUodhyj+uwjMyJrWeuoPiG/aEh0eOVxJAwrpvXK6iYbxjhkvzna9OaM8oe2D/t Q2vAUfBGEPdwMctxxjAGaXDyd9AD81hQfaCJ7+KRGH0PSDhg8pxRoREEfWUYL2yn33Q4 /ZYMKGD+xyJCrQsfH/t5I00zGiATzgKme0pEPbYj0SSZ9YT1FnMMPQbvcvGu2qPAicDf UtCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e4si402662ejs.733.2021.07.29.10.02.40; Thu, 29 Jul 2021 10:03:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229906AbhG2Q6R (ORCPT + 99 others); Thu, 29 Jul 2021 12:58:17 -0400 Received: from foss.arm.com ([217.140.110.172]:52986 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229739AbhG2Q6Q (ORCPT ); Thu, 29 Jul 2021 12:58:16 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A298F1FB; Thu, 29 Jul 2021 09:58:10 -0700 (PDT) Received: from [10.57.36.146] (unknown [10.57.36.146]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9AF463F73D; Thu, 29 Jul 2021 09:58:08 -0700 (PDT) Subject: Re: [PATCH v7 3/4] iommu: rockchip: Add internal ops to handle variants To: =?UTF-8?Q?Heiko_St=c3=bcbner?= , Benjamin Gaignard , joro@8bytes.org, will@kernel.org, robh+dt@kernel.org, xxm@rock-chips.com, Ezequiel Garcia , Dafna Hirschfeld Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, iommu@lists.linux-foundation.org, kernel@collabora.com, linux-arm-kernel@lists.infradead.org References: <20210525121551.606240-1-benjamin.gaignard@collabora.com> <20210525121551.606240-4-benjamin.gaignard@collabora.com> <3544194.oiGErgHkdL@diego> From: Robin Murphy Message-ID: <06cdd178-66af-9ff7-5100-3da4e901040f@arm.com> Date: Thu, 29 Jul 2021 17:58:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <3544194.oiGErgHkdL@diego> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-07-29 17:08, Heiko Stübner wrote: > Hi Dafna, > > Am Donnerstag, 29. Juli 2021, 17:59:26 CEST schrieb Dafna Hirschfeld: >> On 25.05.21 14:15, Benjamin Gaignard wrote: >>> @@ -879,7 +895,7 @@ static int rk_iommu_enable(struct rk_iommu *iommu) >>> >>> for (i = 0; i < iommu->num_mmu; i++) { >>> rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR, >>> - rk_domain->dt_dma); >>> + rk_ops->dma_addr_dte(rk_domain->dt_dma)); >> >> Hi, >> This is not related to that patch, I was wondring why are all mmu devices initialized >> with the same dt_dma? >> I see for example that the isp0_mmu in rk3399.dtsi has two resources. Can't each resource >> be initialized with different dt_dma and this way there are two dt tables instead of the two mmus pointing >> to the same dt table. > > maybe > git log -1 cd6438c5f8446691afa4829fe1a9d7b656204f11 > > "iommu/rockchip: Reconstruct to support multi slaves > > There are some IPs, such as video encoder/decoder, contains 2 slave iommus, > one for reading and the other for writing. They share the same irq and > clock with master. > > This patch reconstructs to support this case by making them share the same > Page Directory, Page Tables and even the register operations. > That means every instruction to the reading MMU registers would be > duplicated to the writing MMU and vice versa." Right. In theory we *could* maintain a separate pagetable for each IOMMU instance, but it would just lead to a load of complexity and overhead. For a map request, we'd have to do extra work to decide which table(s) need modifying, and duplicate all the work of the actual mapping if it's more than one. For an unmap request, we'd have no choice but to walk *all* the tables backing that domain to figure out which (if any) actually had it mapped in the first place. Given that we already have distinct read and write permissions for mappings within a single table, there's not even any functional benefit that could be gained in this case (and in the more general case where the device might emit all kinds of transactions from all its interfaces you'd have to maintain identical mappings for all its IOMMUs anyway). Saving memory and code complexity by physically sharing one pagetable and not worrying about trying to do selective TLB maintenance is a bigger win than anything else could be. Robin.