devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olav Haugan <ohaugan@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>
Cc: Andreas Herrmann <andreas.herrmann@calxeda.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: Tue, 23 Apr 2013 15:54:53 -0700	[thread overview]
Message-ID: <5177113D.7060300@codeaurora.org> (raw)
In-Reply-To: <20130418190131.GA12344@mudshark.cambridge.arm.com>

Hi Will,

On 4/18/2013 12:01 PM, Will Deacon wrote:
> On Tue, Apr 16, 2013 at 07:18:42PM +0100, Olav Haugan wrote:
>> On 4/15/2013 6:13 AM, Will Deacon wrote:
>>> If so, doesn't that strongly tie your video driver to the SMMU?
>>
>> Isn't this more or less what you are doing in DT where you associate
>> specific devices with an IOMMU (mmu-masters)?
> 
> No. The device-tree describes the *hardware*, as per usual. The StreamIDs
> are fixed properties of the SoC and we can't change them from Linux, so we
> describe all of the StreamIDs upstream of each SMMU so that we can program
> the thing. There's no way to generic way to discover them.

I meant that you are putting phandles to bus masters in the device tree
that use/need the SMMU for VA2PA translation. Doesn't this put a
dependency on the bus master devices? How will this work? Lets say that
we have a device during bootup that needs to use the SMMU (such as a
display processor [DP]). Don't you have cyclic dependency? The SMMU
device needs the DP device (phandle) but the DP device needs the SMMU to
initialize its device driver?

>>> This seems to be where we differ. My anticipated use-case is that a domain
>>> is allocated, which defines an empty address space. Masters are then
>>> attached to the domain by passing their struct device, so this may
>>> correspond to a DMA controller or a video core, in your case. The context
>>> bank is allocated dynamically when the first device is added to the
>>> domain, and then it is subsequently shared between all the masters in that
>>> domain.
>>
>> I feel that there are some limitation with this. Maybe you can address
>> the following:
>>
>> 1) What if you want two context banks in one domain (shared page table)?
> 
> 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).

>> 2) What if a master (device) needs to use 2 or more context banks?
> 
> 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.

Thanks,

Olav Haugan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2013-04-23 22:54 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 [this message]
     [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
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=5177113D.7060300@codeaurora.org \
    --to=ohaugan@codeaurora.org \
    --cc=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=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).