From: Olav Haugan <ohaugan@codeaurora.org>
To: Andreas Herrmann <andreas.herrmann@calxeda.com>
Cc: "linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
Will Deacon <will.deacon@arm.com>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"tzeng@codeaurora.org" <tzeng@codeaurora.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 08 Jul 2013 09:20:25 -0700 [thread overview]
Message-ID: <51DAE6C9.1000106@codeaurora.org> (raw)
In-Reply-To: <20130513090724.GA10369@alberich>
Hi Andreas,
On 5/13/2013 2:07 AM, Andreas Herrmann wrote:
> On Tue, May 07, 2013 at 04:26:02PM -0400, Olav Haugan wrote:
>>
>>>>> 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.
>
Sorry for the late reply.
The only real use case at this time for a master having more than 1 CB
is for content protection I believe. I understand that this driver does
not currently support content protection or anything related to security.
Thanks,
Olav Haugan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
WARNING: multiple messages have this Message-ID (diff)
From: ohaugan@codeaurora.org (Olav Haugan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] documentation: iommu: add description of ARM System MMU binding
Date: Mon, 08 Jul 2013 09:20:25 -0700 [thread overview]
Message-ID: <51DAE6C9.1000106@codeaurora.org> (raw)
In-Reply-To: <20130513090724.GA10369@alberich>
Hi Andreas,
On 5/13/2013 2:07 AM, Andreas Herrmann wrote:
> On Tue, May 07, 2013 at 04:26:02PM -0400, Olav Haugan wrote:
>>
>>>>> 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.
>
Sorry for the late reply.
The only real use case at this time for a master having more than 1 CB
is for content protection I believe. I understand that this driver does
not currently support content protection or anything related to security.
Thanks,
Olav Haugan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
next prev parent reply other threads:[~2013-07-08 16:20 UTC|newest]
Thread overview: 38+ 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-04 16:50 ` Will Deacon
2013-04-05 16:43 ` Rob Herring
2013-04-05 16:43 ` Rob Herring
2013-04-05 16:57 ` Will Deacon
2013-04-05 16:57 ` Will Deacon
[not found] ` <20130405165745.GB17151-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-05 18:25 ` Rob Herring
2013-04-05 18:25 ` Rob Herring
[not found] ` <515F1716.70309-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-04-08 8:59 ` Will Deacon
2013-04-08 8:59 ` Will Deacon
2013-04-05 20:44 ` Olav Haugan
2013-04-05 20:44 ` Olav Haugan
[not found] ` <515F37C1.4000109-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-08 9:25 ` Will Deacon
2013-04-08 9:25 ` Will Deacon
[not found] ` <20130408092535.GA17476-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-08 17:03 ` Olav Haugan
2013-04-08 17:03 ` Olav Haugan
[not found] ` <5162F87A.7070409-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-10 17:37 ` Will Deacon
2013-04-10 17:37 ` Will Deacon
[not found] ` <20130410173732.GQ26992-MRww78TxoiP5vMa5CHWGZ34zcgK1vI+I0E9HWUfgJXw@public.gmane.org>
2013-04-13 21:02 ` Olav Haugan
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-15 13:13 ` Will Deacon
2013-04-16 18:18 ` Olav Haugan
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-18 19:01 ` Will Deacon
2013-04-23 22:54 ` Olav Haugan
2013-04-23 22:54 ` Olav Haugan
[not found] ` <5177113D.7060300-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2013-04-24 9:55 ` Will Deacon
2013-04-24 9:55 ` Will Deacon
2013-05-07 20:26 ` Olav Haugan
2013-05-07 20:26 ` Olav Haugan
2013-05-13 9:07 ` Andreas Herrmann
2013-05-13 9:07 ` Andreas Herrmann
2013-05-13 10:04 ` Will Deacon
2013-05-13 10:04 ` Will Deacon
2013-07-08 16:20 ` Olav Haugan [this message]
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=51DAE6C9.1000106@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 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.