diff mbox

[RFC] devicetree: Add master-id-bits property to the iommu device

Message ID 1410718646-9710-1-git-send-email-Varun.Sethi@freescale.com (mailing list archive)
State New, archived
Headers show

Commit Message

Varun Sethi Sept. 14, 2014, 6:17 p.m. UTC
"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(+)

Comments

Arnd Bergmann Sept. 15, 2014, 2:38 a.m. UTC | #1
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
Varun Sethi Sept. 15, 2014, 10:37 a.m. UTC | #2
Hi Arnd,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: Monday, September 15, 2014 8:08 AM
> To: Sethi Varun-B16395
> Cc: devicetree@vger.kernel.org; iommu@lists.linux-foundation.org;
> thierry.reding@gmail.com; Mark.Rutland@arm.com; will.deacon@arm.com;
> hdoyu@nvidia.com; swarren@nvidia.com; robh+dt@kernel.org; linux-arm-
> kernel@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
Arnd Bergmann Sept. 15, 2014, 4:57 p.m. UTC | #3
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
Varun Sethi Sept. 16, 2014, 6:04 p.m. UTC | #4
Hi Arnd,

> -----Original Message-----
> From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> bounces@lists.linux-foundation.org] On Behalf Of Arnd Bergmann
> Sent: Monday, September 15, 2014 10:27 PM
> To: Sethi Varun-B16395
> Cc: Mark.Rutland@arm.com; devicetree@vger.kernel.org;
> swarren@nvidia.com; will.deacon@arm.com; Yoder Stuart-B08248;
> robh+dt@kernel.org; iommu@lists.linux-foundation.org;
> thierry.reding@gmail.com; linux-arm-kernel@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
Thierry Reding Sept. 22, 2014, 9:23 a.m. UTC | #5
On Tue, Sep 16, 2014 at 06:04:48PM +0000, Varun Sethi wrote:
> Hi Arnd,
> 
> > -----Original Message-----
> > From: iommu-bounces@lists.linux-foundation.org [mailto:iommu-
> > bounces@lists.linux-foundation.org] On Behalf Of Arnd Bergmann
> > Sent: Monday, September 15, 2014 10:27 PM
> > To: Sethi Varun-B16395
> > Cc: Mark.Rutland@arm.com; devicetree@vger.kernel.org;
> > swarren@nvidia.com; will.deacon@arm.com; Yoder Stuart-B08248;
> > robh+dt@kernel.org; iommu@lists.linux-foundation.org;
> > thierry.reding@gmail.com; linux-arm-kernel@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
diff mbox

Patch

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@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 {