From: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
To: Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: "arnd-r2nGTMty4D4@public.gmane.org"
<arnd-r2nGTMty4D4@public.gmane.org>,
Marc Zyngier <Marc.Zyngier-5wv7dgnIgG8@public.gmane.org>,
Stuart Yoder
<stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org"
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
"thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org"
<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices
Date: Fri, 4 Jul 2014 09:13:31 +0100 [thread overview]
Message-ID: <20140704081331.GB23379@arm.com> (raw)
In-Reply-To: <3b9f2103f5c44958a74f1e594a58d58a-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
On Fri, Jul 04, 2014 at 08:41:53AM +0100, Varun Sethi wrote:
> Hi Will,
Hey Varun,
> > Once Thierry's generic IOMMU binding is sorted, we should look at adding
> > support for the Stream ID description. Have you looked at that at all?
> >
> Yes, I have looked at the bindings. Would we need to represent the stream
> ids for PCI devices in the device tree? Why do we want to depend on the
> firmware to map the requestor id to the stream id? It can be handled using
> the APIs proposed by Alex Williamson. This is similar to IOMMU group
> determination, which is handled by the IOMMU driver.
Well, there could easily be a fixed mapping from the ID at the host controller
and the ID seem by the SMMU (e.g. two host controllers sharing an SMMU?). I
don't think walking the PCI buses can help you there.
The way I was thinking to handle this is that we express SID = RID +
offset. In the device-tree, we can then describe a range of RIDs on the host
controller, a single offset, and we get back a range of SIDs.
In the worst case scenario, each RID maps to a totally random SID, so then
you have a huge table describing the mapping. I *think* this is actually
unlikely, and if we ever see such a device we can either have a large
mapping or put it into C code for that specific SoC (if it's really huge).
FWIW: I believe that the ACPI folks are thinking along similar lines.
Will
WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices
Date: Fri, 4 Jul 2014 09:13:31 +0100 [thread overview]
Message-ID: <20140704081331.GB23379@arm.com> (raw)
In-Reply-To: <3b9f2103f5c44958a74f1e594a58d58a@BL2PR03MB468.namprd03.prod.outlook.com>
On Fri, Jul 04, 2014 at 08:41:53AM +0100, Varun Sethi wrote:
> Hi Will,
Hey Varun,
> > Once Thierry's generic IOMMU binding is sorted, we should look at adding
> > support for the Stream ID description. Have you looked at that at all?
> >
> Yes, I have looked at the bindings. Would we need to represent the stream
> ids for PCI devices in the device tree? Why do we want to depend on the
> firmware to map the requestor id to the stream id? It can be handled using
> the APIs proposed by Alex Williamson. This is similar to IOMMU group
> determination, which is handled by the IOMMU driver.
Well, there could easily be a fixed mapping from the ID at the host controller
and the ID seem by the SMMU (e.g. two host controllers sharing an SMMU?). I
don't think walking the PCI buses can help you there.
The way I was thinking to handle this is that we express SID = RID +
offset. In the device-tree, we can then describe a range of RIDs on the host
controller, a single offset, and we get back a range of SIDs.
In the worst case scenario, each RID maps to a totally random SID, so then
you have a huge table describing the mapping. I *think* this is actually
unlikely, and if we ever see such a device we can either have a large
mapping or put it into C code for that specific SoC (if it's really huge).
FWIW: I believe that the ACPI folks are thinking along similar lines.
Will
next prev parent reply other threads:[~2014-07-04 8:13 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-30 10:52 [PATCH 0/5] iommu/arm-smmu: Updates for 3.17 Will Deacon
2014-06-30 10:52 ` Will Deacon
[not found] ` <1404125530-17984-1-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-06-30 10:52 ` [PATCH 1/5] iommu/arm-smmu: fix calculation of TCR.T0SZ Will Deacon
2014-06-30 10:52 ` Will Deacon
2014-06-30 10:52 ` [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices Will Deacon
2014-06-30 10:52 ` Will Deacon
[not found] ` <1404125530-17984-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-07-03 14:22 ` Varun Sethi
2014-07-03 14:22 ` Varun Sethi
[not found] ` <a9de518782874b5c8ddd366e6617b8de-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-07-03 14:43 ` Will Deacon
2014-07-03 14:43 ` Will Deacon
[not found] ` <20140703144341.GC14305-5wv7dgnIgG8@public.gmane.org>
2014-07-04 7:41 ` Varun Sethi
2014-07-04 7:41 ` Varun Sethi
[not found] ` <3b9f2103f5c44958a74f1e594a58d58a-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-07-04 8:13 ` Will Deacon [this message]
2014-07-04 8:13 ` Will Deacon
2014-07-09 13:26 ` Will Deacon
2014-07-09 13:26 ` Will Deacon
[not found] ` <20140709132653.GM9485-5wv7dgnIgG8@public.gmane.org>
2014-07-09 14:13 ` Alex Williamson
2014-07-09 14:13 ` Alex Williamson
[not found] ` <1404915184.4256.160.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2014-07-09 16:39 ` Will Deacon
2014-07-09 16:39 ` Will Deacon
2014-10-06 12:42 ` Will Deacon
2014-10-06 12:42 ` Will Deacon
2014-07-09 14:21 ` Varun Sethi
2014-07-09 14:21 ` Varun Sethi
2014-06-30 10:52 ` [PATCH 3/5] iommu/arm-smmu: caps: add IOMMU_CAP_INTR_REMAP capability Will Deacon
2014-06-30 10:52 ` Will Deacon
2014-06-30 10:52 ` [PATCH 4/5] iommu/arm-smmu: remove support for chained SMMUs Will Deacon
2014-06-30 10:52 ` Will Deacon
2014-06-30 10:52 ` [PATCH 5/5] iommu/arm-smmu: prefer stage-1 mappings where we have a choice Will Deacon
2014-06-30 10:52 ` Will Deacon
2014-07-09 6:36 ` leizhen
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=20140704081331.GB23379@arm.com \
--to=will.deacon-5wv7dgnigg8@public.gmane.org \
--cc=Marc.Zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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.