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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Arnd,

> -----Original Message-----
> From: iommu-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx [mailto:iommu-
> bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Arnd Bergmann
> Sent: Monday, September 15, 2014 10:27 PM
> To: Sethi Varun-B16395
> Cc: Mark.Rutland@xxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> swarren@xxxxxxxxxx; will.deacon@xxxxxxx; Yoder Stuart-B08248;
> robh+dt@xxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx;
> thierry.reding@xxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux