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
next prev parent reply other threads:[~2014-07-04 8:13 UTC|newest]
Thread overview: 15+ 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
[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 ` [PATCH 2/5] iommu/arm-smmu: add support for PCI master devices Will Deacon
[not found] ` <1404125530-17984-3-git-send-email-will.deacon-5wv7dgnIgG8@public.gmane.org>
2014-07-03 14:22 ` Varun Sethi
[not found] ` <a9de518782874b5c8ddd366e6617b8de-AZ66ij2kwaacCcN9WK45f+O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-07-03 14:43 ` Will Deacon
[not found] ` <20140703144341.GC14305-5wv7dgnIgG8@public.gmane.org>
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-09 13:26 ` Will Deacon
[not found] ` <20140709132653.GM9485-5wv7dgnIgG8@public.gmane.org>
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-10-06 12:42 ` Will Deacon
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 ` [PATCH 4/5] iommu/arm-smmu: remove support for chained SMMUs Will Deacon
2014-06-30 10:52 ` [PATCH 5/5] iommu/arm-smmu: prefer stage-1 mappings where we have a choice Will Deacon
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 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).