RE: RFC: extend iommu-map binding to support #iommu-cells > 1

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

 





> -----Original Message-----
> From: Bharat Bhushan
> Sent: Thursday, December 15, 2016 9:46 PM
> To: Stuart Yoder <stuart.yoder@xxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; robin.murphy@xxxxxxx;
> will.deacon@xxxxxxx
> Cc: robh+dt@xxxxxxxxxx; Nipun Gupta <nipun.gupta@xxxxxxx>; Diana Madalina Craciun
> <diana.craciun@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx; iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: RFC: extend iommu-map binding to support #iommu-cells > 1
> 
> 
> 
> > -----Original Message-----
> > From: Stuart Yoder
> > Sent: Friday, December 16, 2016 8:07 AM
> > To: Mark Rutland <mark.rutland@xxxxxxx>; robin.murphy@xxxxxxx;
> > will.deacon@xxxxxxx
> > Cc: robh+dt@xxxxxxxxxx; Bharat Bhushan <bharat.bhushan@xxxxxxx>;
> > Nipun Gupta <nipun.gupta@xxxxxxx>; Diana Madalina Craciun
> > <diana.craciun@xxxxxxx>; devicetree@xxxxxxxxxxxxxxx; iommu@lists.linux-
> > foundation.org
> > Subject: RFC: extend iommu-map binding to support #iommu-cells > 1
> >
> > For context, please see the thread:
> > https://www.spinics.net/lists/arm-kernel/msg539066.html
> >
> > The existing iommu-map binding did not account for the situation where
> > #iommu-cells == 2, as permitted in the ARM SMMU binding.  The 2nd cell of
> > the IOMMU specifier being the SMR mask.  The existing binding defines the
> > mapping as:
> >    Any RID r in the interval [rid-base, rid-base + length) is associated with
> >    the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> >
> > ...and that does not work if iommu-base is 2 cells, the second being the SMR
> > mask.
> >
> > While this can be worked around by always having length=1, it seems we can
> > get this cleaned up by updating the binding definition for iommu-map.
> >
> > See patch below.  Thoughts?
> >
> > Thanks,
> > Stuart
> >
> > -------------------------------------------------------------------------
> >
> > diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> > b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> > index 56c8296..e81b461 100644
> > --- a/Documentation/devicetree/bindings/pci/pci-iommu.txt
> > +++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
> > @@ -38,8 +38,20 @@ Optional properties
> >    The property is an arbitrary number of tuples of
> >    (rid-base,iommu,iommu-base,length).
> >
> > -  Any RID r in the interval [rid-base, rid-base + length) is associated with
> > -  the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
> > +  If the associated IOMMU has an #iommu-cells value of 1, any RID r in
> > + the  interval [rid-base, rid-base + length) is associated with the
> > + listed IOMMU,  with the iommu-specifier (r - rid-base + iommu-base).
> > +
> > +  ARM SMMU Note:
> > +    The ARM SMMU binding permits an #iommu-cells value of 2 and in this
> > +    case defines an IOMMU specifier to be: (stream-id,smr-mask)
> > +
> > +    In an iommu-map this means the iommu-base consists of 2 cells:
> > +        (rid-base,iommu,[stream-id,smr-mask],length).
> > +
> > +    In this case the RID to IOMMU specifier mapping is defined to be:
> > +    any RID r in the interval [rid-base, rid-base + length) is associated
> > +    with the listed IOMMU, with the iommu-specifier (r - rid-base + stream-
> > id).
> 
> Should not this be (r - rid-base + (stream-id & smr-mask)) ?

No, the SMR mask is not applied here-- that is programmed in the SMMU
hardware and not applied by software.  The SMR mask in the case of NXP
is 0x7C00, and so is the inverse of a typical mask of 1 bits.

If the map was defined as:  <0x0 &smmu 0x10 0x7c00 10>;

An RID value of 0x2 would get mapped to the 2-cell specifier: <0x12 0x7c00>

Stuart
--
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