On Tue, Sep 16, 2014 at 06:04:48PM +0000, 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

Attachment: pgpbywhwf3X5a.pgp
Description: PGP signature

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Reply via email to