* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
@ 2014-09-14 18:17 Varun Sethi
2014-09-15 2:38 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Varun Sethi @ 2014-09-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
"master-id-bits" property added to the IOMMU device node. This property can
be used by the IOMMU driver to match relevan bits in the master id expressed
by a DMA master.
This can be used to mask out certain bits that get added to the device master id
due to IOMMU topology. For example, in case of MMU-500 the TBUID gets appended to
the master id. This prevents sharing of a stream ID, amongst devices which are
connected to different TBUs.
Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
---
Documentation/devicetree/bindings/iommu/iommu.txt | 29 +++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt
index 5a8b462..f7c8623 100644
--- a/Documentation/devicetree/bindings/iommu/iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/iommu.txt
@@ -63,6 +63,23 @@ Note that these are merely examples and real-world use-cases may use different
definitions to represent their individual needs. Always refer to the specific
IOMMU binding for the exact meaning of the cells that make up the specifier.
+Optional properties:
+--------------------
+- master-id-bits: This specifies number of master id bits used by the iommu, to
+ match master id expressed by the DMA master device. This would be typically used
+ in cases where we need DMA memory isolation between multiple masters. Each master
+ would specify a master id associated with a DMA trasaction.
+
+ The IOMMU driver can use this property to generate a mask to match only relevant
+ bits in the master id. This can be used for masking out certain bits that get
+ added to the master id as a part of the IOMMU topology.
+
+ For example, in case of MMU-500 the TBU identifier is also appended to the master id.
+ This posese issues for software implementations requiring dynamic master id allocation
+ for supporting hot pluggable devices. It's possible to have a device group, with
+ devices connected to different TBUs. Without masking the additional TBU ID bits, we
+ can't share the master id across all devices in the device group.
+
IOMMU master node:
==================
@@ -147,6 +164,12 @@ Multiple-master IOMMU:
iommu {
/* the specifier represents the ID of the master */
#iommu-cells = <1>;
+
+ /*
+ * This specifies number of master id bits used by
+ * the iommu for matching the master id.
+ */
+ master-id-bits = <7>
};
master at 1 {
@@ -173,6 +196,12 @@ Multiple-master IOMMU with configurable DMA window:
* master (i.e. the I/O virtual address space).
*/
#iommu-cells = <4>;
+
+ /*
+ * This specifies number of master id bits used by
+ * the iommu for matching the master id.
+ */
+ master-id-bits = <7>
};
master {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
2014-09-14 18:17 [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device Varun Sethi
@ 2014-09-15 2:38 ` Arnd Bergmann
2014-09-15 10:37 ` Varun Sethi
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2014-09-15 2:38 UTC (permalink / raw)
To: linux-arm-kernel
On Sunday 14 September 2014, Varun Sethi wrote:
> "master-id-bits" property added to the IOMMU device node. This property can
> be used by the IOMMU driver to match relevan bits in the master id expressed
> by a DMA master.
>
> This can be used to mask out certain bits that get added to the device master id
> due to IOMMU topology. For example, in case of MMU-500 the TBUID gets appended to
> the master id. This prevents sharing of a stream ID, amongst devices which are
> connected to different TBUs.
>
> Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
This seems rather specific to MMU-500. I don't think that most IOMMUs would
use the term 'master ID', 'stream ID' or even the general concept, and you don't
expand the acronym 'TBU'. I've seen many IOMMUs and I don't even know what
that means.
Why do you think this is something that is needed to be known at the global
level, rather than a property for some individual drivers?
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
2014-09-15 2:38 ` Arnd Bergmann
@ 2014-09-15 10:37 ` Varun Sethi
2014-09-15 16:57 ` Arnd Bergmann
0 siblings, 1 reply; 6+ messages in thread
From: Varun Sethi @ 2014-09-15 10:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, September 15, 2014 8:08 AM
> To: Sethi Varun-B16395
> Cc: devicetree at vger.kernel.org; iommu at lists.linux-foundation.org;
> thierry.reding at gmail.com; Mark.Rutland at arm.com; will.deacon at arm.com;
> hdoyu at nvidia.com; swarren at nvidia.com; robh+dt at kernel.org; linux-arm-
> kernel at lists.infradead.org; Yoder Stuart-B08248
> Subject: Re: [RFC][PATCH] devicetree: Add master-id-bits property to the
> iommu device
>
> On Sunday 14 September 2014, Varun Sethi wrote:
> > "master-id-bits" property added to the IOMMU device node. This
> > property can be used by the IOMMU driver to match relevan bits in the
> > master id expressed by a DMA master.
> >
> > This can be used to mask out certain bits that get added to the device
> > master id due to IOMMU topology. For example, in case of MMU-500 the
> > TBUID gets appended to the master id. This prevents sharing of a
> > stream ID, amongst devices which are connected to different TBUs.
> >
> > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
>
> This seems rather specific to MMU-500. I don't think that most IOMMUs would
> use the term 'master ID', 'stream ID' or even the general concept, and you
> don't expand the acronym 'TBU'. I've seen many IOMMUs and I don't even
> know what that means.
TBU refers to the translation buffer unit, which is responsible for caching page translations. In case of translation miss in the cache, translation request is forwarded to the TCU (Translation control unit). The master id forwarded to TCU would also contain the TBU ID. Using the master-id-bits property we can mask out the additional TBU bits at the TCU. This is a cause of concern when we want to share master id for devices which are connected to different TBUs. We have a hot pluggable bus architecture, where a device group can have multiple devices connected to different TBUs. So, we need a mechanism to mask out additional TBIU bits.
>
> Why do you think this is something that is needed to be known at the global
> level, rather than a property for some individual drivers?
>
In case of Freescale Layerscape SOCs, number of bits used for defining a stream id are specific to a given platform.
Are you suggesting that this property should be added to the master device node, rather than the iommu node?
-Varun
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
2014-09-15 10:37 ` Varun Sethi
@ 2014-09-15 16:57 ` Arnd Bergmann
2014-09-16 18:04 ` Varun Sethi
0 siblings, 1 reply; 6+ messages in thread
From: Arnd Bergmann @ 2014-09-15 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Monday 15 September 2014, Varun Sethi wrote:
> >
> > This seems rather specific to MMU-500. I don't think that most IOMMUs would
> > use the term 'master ID', 'stream ID' or even the general concept, and you
> > don't expand the acronym 'TBU'. I've seen many IOMMUs and I don't even
> > know what that means.
>
> TBU refers to the translation buffer unit, which is responsible for caching page translations. In case of translation miss in the cache, translation request is forwarded to the TCU (Translation control unit). The master id forwarded to TCU would also contain the TBU ID. Using the master-id-bits property we can mask out the additional TBU bits at the TCU. This is a cause of concern when we want to share master id for devices which are connected to different TBUs. We have a hot pluggable bus architecture, where a device group can have multiple devices connected to different TBUs. So, we need a mechanism to mask out additional TBIU bits.
Ok, I think I understand now
> > Why do you think this is something that is needed to be known at the global
> > level, rather than a property for some individual drivers?
> >
> In case of Freescale Layerscape SOCs, number of bits used for defining a stream id are specific to a given platform.
>
> Are you suggesting that this property should be added to the master device node, rather than the iommu node?
Most importantly, I think this needs to be part of the (iommu) device specific binding, not the
generic binding that is used for all iommus that may or may not have this concept.
I believe in case of the ARM SMMU, it should actually go into the master node as part of
the 'iommus' property, because the mask can be different for each master. If your IOMMU
has a fixed mask that is used for all devices, that's fine and you can put it into
the iommu node itself but document it in the binding for your IOMMU.
For hot-pluggable buses, you probably need to have the 'iommus' property in the node
that corresponds to the bus controller, and that will have a mask that is used for
all devices plugged into it.
Arnd
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
2014-09-15 16:57 ` Arnd Bergmann
@ 2014-09-16 18:04 ` Varun Sethi
2014-09-22 9:23 ` Thierry Reding
0 siblings, 1 reply; 6+ messages in thread
From: Varun Sethi @ 2014-09-16 18:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd,
> -----Original Message-----
> From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> bounces at lists.linux-foundation.org] On Behalf Of Arnd Bergmann
> Sent: Monday, September 15, 2014 10:27 PM
> To: Sethi Varun-B16395
> Cc: Mark.Rutland at arm.com; devicetree at vger.kernel.org;
> swarren at nvidia.com; will.deacon at arm.com; Yoder Stuart-B08248;
> robh+dt at kernel.org; iommu at lists.linux-foundation.org;
> thierry.reding at gmail.com; linux-arm-kernel at lists.infradead.org
> Subject: Re: [RFC][PATCH] devicetree: Add master-id-bits property to the
> iommu device
>
> On Monday 15 September 2014, Varun Sethi wrote:
> > >
> > > This seems rather specific to MMU-500. I don't think that most
> > > IOMMUs would use the term 'master ID', 'stream ID' or even the
> > > general concept, and you don't expand the acronym 'TBU'. I've seen
> > > many IOMMUs and I don't even know what that means.
> >
> > TBU refers to the translation buffer unit, which is responsible for caching
> page translations. In case of translation miss in the cache, translation request is
> forwarded to the TCU (Translation control unit). The master id forwarded to
> TCU would also contain the TBU ID. Using the master-id-bits property we can
> mask out the additional TBU bits at the TCU. This is a cause of concern when we
> want to share master id for devices which are connected to different TBUs. We
> have a hot pluggable bus architecture, where a device group can have multiple
> devices connected to different TBUs. So, we need a mechanism to mask out
> additional TBIU bits.
>
> Ok, I think I understand now
>
> > > Why do you think this is something that is needed to be known at the
> > > global level, rather than a property for some individual drivers?
> > >
> > In case of Freescale Layerscape SOCs, number of bits used for defining a
> stream id are specific to a given platform.
> >
> > Are you suggesting that this property should be added to the master device
> node, rather than the iommu node?
>
> Most importantly, I think this needs to be part of the (iommu) device specific
> binding, not the generic binding that is used for all iommus that may or may not
> have this concept.
>
> I believe in case of the ARM SMMU, it should actually go into the master node
> as part of the 'iommus' property, because the mask can be different for each
> master. If your IOMMU has a fixed mask that is used for all devices, that's fine
> and you can put it into the iommu node itself but document it in the binding for
> your IOMMU.
>
> For hot-pluggable buses, you probably need to have the 'iommus' property in
> the node that corresponds to the bus controller, and that will have a mask that
> is used for all devices plugged into it.
Can I add a note to the generic binding about representing the "mask" as a part of the "iommus" property. This would similar to the note about the "dma-ranges"
-Varun
^ permalink raw reply [flat|nested] 6+ messages in thread
* [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
2014-09-16 18:04 ` Varun Sethi
@ 2014-09-22 9:23 ` Thierry Reding
0 siblings, 0 replies; 6+ messages in thread
From: Thierry Reding @ 2014-09-22 9:23 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Sep 16, 2014 at 06:04:48PM +0000, Varun Sethi wrote:
> Hi Arnd,
>
> > -----Original Message-----
> > From: iommu-bounces at lists.linux-foundation.org [mailto:iommu-
> > bounces at lists.linux-foundation.org] On Behalf Of Arnd Bergmann
> > Sent: Monday, September 15, 2014 10:27 PM
> > To: Sethi Varun-B16395
> > Cc: Mark.Rutland at arm.com; devicetree at vger.kernel.org;
> > swarren at nvidia.com; will.deacon at arm.com; Yoder Stuart-B08248;
> > robh+dt at kernel.org; iommu at lists.linux-foundation.org;
> > thierry.reding at gmail.com; linux-arm-kernel at lists.infradead.org
> > Subject: Re: [RFC][PATCH] devicetree: Add master-id-bits property to the
> > iommu device
> >
> > On Monday 15 September 2014, Varun Sethi wrote:
> > > >
> > > > This seems rather specific to MMU-500. I don't think that most
> > > > IOMMUs would use the term 'master ID', 'stream ID' or even the
> > > > general concept, and you don't expand the acronym 'TBU'. I've seen
> > > > many IOMMUs and I don't even know what that means.
> > >
> > > TBU refers to the translation buffer unit, which is responsible for caching
> > page translations. In case of translation miss in the cache, translation request is
> > forwarded to the TCU (Translation control unit). The master id forwarded to
> > TCU would also contain the TBU ID. Using the master-id-bits property we can
> > mask out the additional TBU bits at the TCU. This is a cause of concern when we
> > want to share master id for devices which are connected to different TBUs. We
> > have a hot pluggable bus architecture, where a device group can have multiple
> > devices connected to different TBUs. So, we need a mechanism to mask out
> > additional TBIU bits.
> >
> > Ok, I think I understand now
> >
> > > > Why do you think this is something that is needed to be known at the
> > > > global level, rather than a property for some individual drivers?
> > > >
> > > In case of Freescale Layerscape SOCs, number of bits used for defining a
> > stream id are specific to a given platform.
> > >
> > > Are you suggesting that this property should be added to the master device
> > node, rather than the iommu node?
> >
> > Most importantly, I think this needs to be part of the (iommu) device specific
> > binding, not the generic binding that is used for all iommus that may or may not
> > have this concept.
> >
> > I believe in case of the ARM SMMU, it should actually go into the master node
> > as part of the 'iommus' property, because the mask can be different for each
> > master. If your IOMMU has a fixed mask that is used for all devices, that's fine
> > and you can put it into the iommu node itself but document it in the binding for
> > your IOMMU.
> >
> > For hot-pluggable buses, you probably need to have the 'iommus' property in
> > the node that corresponds to the bus controller, and that will have a mask that
> > is used for all devices plugged into it.
> Can I add a note to the generic binding about representing the "mask"
> as a part of the "iommus" property. This would similar to the note
> about the "dma-ranges"
I think the concept of a mask is fairly device-specific. Adding a note
to it in the generic binding could be confusing to people working with
IOMMUs that don't know the concept.
dma-ranges on the other hand is a generic property, so referring to it
in the generic binding makes sense.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140922/edd47503/attachment-0001.sig>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-09-22 9:23 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-14 18:17 [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device Varun Sethi
2014-09-15 2:38 ` Arnd Bergmann
2014-09-15 10:37 ` Varun Sethi
2014-09-15 16:57 ` Arnd Bergmann
2014-09-16 18:04 ` Varun Sethi
2014-09-22 9:23 ` Thierry Reding
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).