linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: "Heiko Stübner" <heiko@sntech.de>,
	"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
	joro@8bytes.org, will@kernel.org, robh+dt@kernel.org,
	xxm@rock-chips.com, "Ezequiel Garcia" <ezequiel@collabora.com>,
	"Dafna Hirschfeld" <dafna.hirschfeld@collabora.com>
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
Subject: Re: [PATCH v7 3/4] iommu: rockchip: Add internal ops to handle variants
Date: Thu, 29 Jul 2021 17:58:03 +0100	[thread overview]
Message-ID: <06cdd178-66af-9ff7-5100-3da4e901040f@arm.com> (raw)
In-Reply-To: <3544194.oiGErgHkdL@diego>

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.

  reply	other threads:[~2021-07-29 16:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 12:15 [PATCH v7 0/4] Add IOMMU driver for rk356x Benjamin Gaignard
2021-05-25 12:15 ` [PATCH v7 1/4] dt-bindings: iommu: rockchip: Convert IOMMU to DT schema Benjamin Gaignard
2021-05-25 12:15 ` [PATCH v7 2/4] dt-bindings: iommu: rockchip: Add compatible for v2 Benjamin Gaignard
2021-05-25 12:15 ` [PATCH v7 3/4] iommu: rockchip: Add internal ops to handle variants Benjamin Gaignard
2021-07-29 15:59   ` Dafna Hirschfeld
2021-07-29 16:08     ` Heiko Stübner
2021-07-29 16:58       ` Robin Murphy [this message]
2021-07-30 12:52         ` Dafna Hirschfeld
2021-07-30 13:29           ` Robin Murphy
2021-05-25 12:15 ` [PATCH v7 4/4] iommu: rockchip: Add support for iommu v2 Benjamin Gaignard
2021-06-04 14:54 ` [PATCH v7 0/4] Add IOMMU driver for rk356x Joerg Roedel
2021-06-04 14:56   ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06cdd178-66af-9ff7-5100-3da4e901040f@arm.com \
    --to=robin.murphy@arm.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=dafna.hirschfeld@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ezequiel@collabora.com \
    --cc=heiko@sntech.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kernel@collabora.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=will@kernel.org \
    --cc=xxm@rock-chips.com \
    --subject='Re: [PATCH v7 3/4] iommu: rockchip: Add internal ops to handle variants' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).