devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexandre Bailon <abailon@baylibre.com>
To: Robin Murphy <robin.murphy@arm.com>,
	yong.wu@mediatek.com, joro@8bytes.org, will@kernel.org
Cc: matthias.bgg@gmail.com, krzysztof.kozlowski@linaro.org,
	robh+dt@kernel.org, iommu@lists.linux.dev,
	linux-mediatek@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/3] iommu: mediatek: Add support of unmanaged iommu domain
Date: Tue, 31 Jan 2023 16:31:48 +0100	[thread overview]
Message-ID: <21fef8eb-6482-fd8c-118a-c4d9da4cfbaf@baylibre.com> (raw)
In-Reply-To: <0e9f677b-846d-809d-9bc3-30906f703fda@arm.com>



On 1/31/23 15:15, Robin Murphy wrote:
> On 31/01/2023 1:08 pm, Alexandre Bailon wrote:
>> Hi Robin
>>
>> On 1/30/23 13:04, Robin Murphy wrote:
>>> On 2023-01-30 10:27, Alexandre Bailon wrote:
>>>> Currently, the driver can allocate an unmanaged iommu domain.
>>>> But, this only works for SoC having multiple bank or multiple iova 
>>>> region.
>>>
>>> That is for good reason - there is only a single pagetable per bank, 
>>> so if there are multiple devices assigned to a single bank, they 
>>> cannot possibly be attached to different domains at the same time. 
>>> Hence why the banks are modelled as groups.
>> I understand.
>> I am trying to upstream a remoteproc driver but the remote processor is
>> behind the iommu.
>> remoteproc can manage the iommu but it requires an unmanaged domain.
>> I tried a couple of things but this cause code duplication,
>> implies many hacks and not always reliable.
>> Do you have any suggestion ?
> 
> If there are other active devices behind the same IOMMU, and the 
> remoteproc device cannot be isolated into its own bank using the 
> existing IOMMU driver logic, then the remoteproc driver cannot manage 
> the IOMMU directly, and must just use the regular DMA API. There's no 
> way around it; you can't have two different parts of the kernel both 
> thinking they have exclusive control of a single IOMMU address space at 
> the same time. Similarly, remoteproc also cannot take explicit control 
> of a multi-device group if it's not actually in control of the other 
> devices, since their drivers will not be expecting the DMA address space 
> to suddenly change underfoot - that's why iommu_attach_device() has the 
> check which you presumably ran into.
Unfortunately, we can't just use the regular DMA API.
Basically, the firmware use static addresses (and the remote core is 
only supposed to access addresses between 0x60000000 and 0x70000000).
When we use DMA API, we get a random address that doesn't match what the
firmware would expect.
remoteproc use directly the iommu API to map physical address to the
static address expected by the firmware when DMA API can't be use.

Thanks,
Alexandre


  reply	other threads:[~2023-01-31 15:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-30 10:27 [PATCH 0/3] Add support of unmanaged domain to mediatek IOMMU Alexandre Bailon
2023-01-30 10:27 ` [PATCH 1/3] dt-bindings: memory: mediatek: Add support of unmanaged iommu domain Alexandre Bailon
2023-01-30 11:57   ` Alexandre Mergnat
2023-01-30 11:58   ` Robin Murphy
2023-01-30 10:27 ` [PATCH 2/3] iommu: " Alexandre Bailon
2023-01-30 12:04   ` Alexandre Mergnat
2023-01-30 12:04   ` Robin Murphy
2023-01-31 13:08     ` Alexandre Bailon
2023-01-31 14:15       ` Robin Murphy
2023-01-31 15:31         ` Alexandre Bailon [this message]
2023-02-14  5:48           ` Yong Wu (吴勇)
2023-09-14  8:07             ` Alexandre Bailon
2023-09-14 14:19               ` Robin Murphy
2023-01-30 10:27 ` [PATCH 3/3] dt-bindings: iommu: memory: Use unmanaged iommu domain for the APU Alexandre Bailon
2023-01-30 12:04   ` Alexandre Mergnat
2023-01-30 22:50   ` Rob Herring

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=21fef8eb-6482-fd8c-118a-c4d9da4cfbaf@baylibre.com \
    --to=abailon@baylibre.com \
    --cc=devicetree@vger.kernel.org \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=yong.wu@mediatek.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).