Re: [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
On Tue, Sep 16, 2014 at 06:04:48PM +, Varun Sethi wrote: Hi Arnd, -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Arnd Bergmann Sent: Monday, September 15, 2014 10:27 PM To: Sethi Varun-B16395 Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; swar...@nvidia.com; will.dea...@arm.com; Yoder Stuart-B08248; robh...@kernel.org; iommu@lists.linux-foundation.org; thierry.red...@gmail.com; linux-arm-ker...@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 pgpbywhwf3X5a.pgp Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
Hi Arnd, -Original Message- From: iommu-boun...@lists.linux-foundation.org [mailto:iommu- boun...@lists.linux-foundation.org] On Behalf Of Arnd Bergmann Sent: Monday, September 15, 2014 10:27 PM To: Sethi Varun-B16395 Cc: mark.rutl...@arm.com; devicet...@vger.kernel.org; swar...@nvidia.com; will.dea...@arm.com; Yoder Stuart-B08248; robh...@kernel.org; iommu@lists.linux-foundation.org; thierry.red...@gmail.com; linux-arm-ker...@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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [RFC][PATCH] devicetree: Add master-id-bits property to the iommu device
Hi Arnd, -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Monday, September 15, 2014 8:08 AM To: Sethi Varun-B16395 Cc: devicet...@vger.kernel.org; iommu@lists.linux-foundation.org; thierry.red...@gmail.com; mark.rutl...@arm.com; will.dea...@arm.com; hd...@nvidia.com; swar...@nvidia.com; robh...@kernel.org; linux-arm- ker...@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.se...@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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
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.se...@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 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
