All of lore.kernel.org
 help / color / mirror / Atom feed
From: joro <joro@8bytes.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-rockchip <linux-rockchip@lists.infradead.org>,
	iommu <iommu@lists.linux-foundation.org>, will <will@kernel.org>,
	hch <hch@lst.de>
Subject: Re: Different type iommus integrated in a SoC
Date: Fri, 4 Jun 2021 17:44:45 +0200	[thread overview]
Message-ID: <YLpKbRVU1YPD/73L@8bytes.org> (raw)
In-Reply-To: <5d7127d5-b73c-2002-1734-98aab2295c8e@arm.com>

On Thu, Jun 03, 2021 at 01:05:43PM +0100, Robin Murphy wrote:
> Hooray! I've been forecasting this for years, but the cases we regularly hit
> with internal FPGA prototyping (nor the secret unused MMU-400 I found on
> RK3288) have never really been a strong enough argument to stand behind.
> 
> Based on what I remember from looking into this a few years ago, converting
> *most* of the API to per-device ops (now via dev->iommu) is trivial; the
> main challenge will be getting the per-device data bootstrapped in
> iommu_probe_device(), which would probably need to rely on the fwspec and/or
> list of registered IOMMU instances.
> 
> The other notable thing which will need to change is the domain allocation
> interface, but in practice I think everyone who calls iommu_domain_alloc()
> today is in fact doing so for a specific device, so I don't think it's as
> big a problem as it might first appear.

Yeah, I think for that we have to give up on the promise that a domain
can be assigned to _any_ device. But this promise doesn't even hold true
now when there are several IOMMU of the same type but with different
feature sets in a system.

So I happily review patches enabling the Multi-IOMMU SOCs :)

Regards,

	Joerg
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: joro <joro@8bytes.org>
To: Robin Murphy <robin.murphy@arm.com>
Cc: "xxm@rock-chips.com" <xxm@rock-chips.com>, hch <hch@lst.de>,
	will <will@kernel.org>, iommu <iommu@lists.linux-foundation.org>,
	linux-rockchip <linux-rockchip@lists.infradead.org>
Subject: Re: Different type iommus integrated in a SoC
Date: Fri, 4 Jun 2021 17:44:45 +0200	[thread overview]
Message-ID: <YLpKbRVU1YPD/73L@8bytes.org> (raw)
In-Reply-To: <5d7127d5-b73c-2002-1734-98aab2295c8e@arm.com>

On Thu, Jun 03, 2021 at 01:05:43PM +0100, Robin Murphy wrote:
> Hooray! I've been forecasting this for years, but the cases we regularly hit
> with internal FPGA prototyping (nor the secret unused MMU-400 I found on
> RK3288) have never really been a strong enough argument to stand behind.
> 
> Based on what I remember from looking into this a few years ago, converting
> *most* of the API to per-device ops (now via dev->iommu) is trivial; the
> main challenge will be getting the per-device data bootstrapped in
> iommu_probe_device(), which would probably need to rely on the fwspec and/or
> list of registered IOMMU instances.
> 
> The other notable thing which will need to change is the domain allocation
> interface, but in practice I think everyone who calls iommu_domain_alloc()
> today is in fact doing so for a specific device, so I don't think it's as
> big a problem as it might first appear.

Yeah, I think for that we have to give up on the promise that a domain
can be assigned to _any_ device. But this promise doesn't even hold true
now when there are several IOMMU of the same type but with different
feature sets in a system.

So I happily review patches enabling the Multi-IOMMU SOCs :)

Regards,

	Joerg

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  parent reply	other threads:[~2021-06-04 15:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-27  2:37 Different type iommus integrated in a SoC xxm
2021-06-03 12:05 ` Robin Murphy
2021-06-03 12:05   ` Robin Murphy
2021-06-03 12:24   ` Peter Geis
2021-06-03 12:24     ` Peter Geis
2021-06-03 12:49     ` Robin Murphy
2021-06-03 12:49       ` Robin Murphy
2021-06-04 15:44   ` joro [this message]
2021-06-04 15:44     ` joro

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=YLpKbRVU1YPD/73L@8bytes.org \
    --to=joro@8bytes.org \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.