From: Andreas Herrmann <andreas.herrmann@calxeda.com>
To: Olav Haugan <ohaugan@codeaurora.org>
Cc: Will Deacon <will.deacon@arm.com>,
"tzeng@codeaurora.org" <tzeng@codeaurora.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 13 May 2013 11:07:24 +0200 [thread overview]
Message-ID: <20130513090724.GA10369@alberich> (raw)
In-Reply-To: <5189635A.8090504@codeaurora.org>
On Tue, May 07, 2013 at 04:26:02PM -0400, Olav Haugan wrote:
> Hi Will,
>
> On 4/24/2013 2:55 AM, Will Deacon wrote:
> > On Tue, Apr 23, 2013 at 11:54:53PM +0100, Olav Haugan wrote:
> >> On 4/18/2013 12:01 PM, Will Deacon wrote:
> > Getting phandles has no dependencies on anything -- the only dependency is
> > that the device is added to the bus on which the SMMU sits, just like every
> > other IOMMU driver.
> >
> >>> Why would a page table shared between devices require multiple context
> >>> banks? Multiple SMRs and S2CRs, sure, but they would ultimately point at the
> >>> same context bank (and hence same address space).
> >>
> >> What if you want to have 2 different VMID's being generated? Also, what
> >> about TLB management? If I have two context banks I can invalidate only
> >> entries associated with 1 of the context banks (if VMID differ for the
> >> two context banks).
> >
> > Huh? We allocate one VMID per domain. If you want more VMIDs, use more
> > domains. TLB invalidation is per-domain, so there's no issue there.
>
> If we allocate a new domain you would have another address space (page
> table), no? I was just trying to figure out if your binding proposal
> would allow for 2 context banks in one domain which it does not seem to
> support.
>
> >>> If a master needs to be in two address spaces at once, then it will need to
> >>> attach it's StreamIDs to different domains. You can't place a single
> >>> StreamID in two address spaces (this is an architectural constraint).
> >>
> >> Yes, you would have a separate domain. I am just wondering how I would
> >> model this in DT using the bindings that you are proposing? How does it
> >> work? The bindings specify bus masters to StreamIDs. So if I call attach
> >> with the master device you will allocate a context bank and program the
> >> StreamIDs as specified in the DT. So now if I want to have another
> >> context bank associated with the same master device what do I do? I call
> >> into attach with a new domain but with the same master device but the
> >> master device is already attached to a context/domain.
> >
> > Why would you want to place a StreamID into two domains? That doesn't make
> > any sense and isn't even supported by the architecture (things like
> > conflicting SMR entries may not even be reported).
>
> I think you misunderstood me. I am talking about having for example 1
> master with two (2) context banks so that StreamID "1" goes to CB0 and
> StreamID "2" goes to CB1. This means that the master device is attached
> to two different domains. How do I model this with the the device tree
> bindings?
Hi Olav,
I think with the proposed device tree binding you can't model this.
Do we have such use cases already? Or what future use cases would
require this?
I can imagine of multiple contexts per device for stuff similar to
what PASID in PCI Express are used for.
But in such a case you probably want to have some configurable bits in
the StreamID (that should be set by an SMMU driver). And the DT
binding should contain the number of contexts that a master device can
support.
Andreas
next prev parent reply other threads:[~2013-05-13 9:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-04 16:50 [PATCH] documentation: iommu: add description of ARM System MMU binding Will Deacon
2013-04-05 16:43 ` Rob Herring
2013-04-05 16:57 ` Will Deacon
[not found] ` <20130405165745.GB17151-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-05 18:25 ` Rob Herring
[not found] ` <515F1716.70309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-04-08 8:59 ` Will Deacon
2013-04-05 20:44 ` Olav Haugan
[not found] ` <515F37C1.4000109-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-08 9:25 ` Will Deacon
[not found] ` <20130408092535.GA17476-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-08 17:03 ` Olav Haugan
[not found] ` <5162F87A.7070409-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-10 17:37 ` Will Deacon
[not found] ` <20130410173732.GQ26992-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-13 21:02 ` Olav Haugan
[not found] ` <5169C7D1.8070300-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-15 13:13 ` Will Deacon
2013-04-16 18:18 ` Olav Haugan
[not found] ` <516D9602.2010404-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-18 19:01 ` Will Deacon
2013-04-23 22:54 ` Olav Haugan
[not found] ` <5177113D.7060300-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-24 9:55 ` Will Deacon
2013-05-07 20:26 ` Olav Haugan
2013-05-13 9:07 ` Andreas Herrmann [this message]
2013-05-13 10:04 ` Will Deacon
2013-07-08 16:20 ` Olav Haugan
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=20130513090724.GA10369@alberich \
--to=andreas.herrmann@calxeda.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=ohaugan@codeaurora.org \
--cc=tzeng@codeaurora.org \
--cc=will.deacon@arm.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).