| Message ID | 1410718646-9710-1-git-send-email-Varun.Sethi@freescale.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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 --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 {
"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(+)