Re: [PATCH 09/12] dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc bus

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

 



On 2020-05-22 00:10, Rob Herring wrote:
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
<lorenzo.pieralisi@xxxxxxx> wrote:

From: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>

The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.

Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
msi-map property.

Signed-off-by: Laurentiu Tudor <laurentiu.tudor@xxxxxxx>
Cc: Rob Herring <robh+dt@xxxxxxxxxx>
---
  .../devicetree/bindings/misc/fsl,qoriq-mc.txt | 30 +++++++++++++++++--
  1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 9134e9bcca56..b0813b2d0493 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -18,9 +18,9 @@ same hardware "isolation context" and a 10-bit value called an ICID
  the requester.

  The generic 'iommus' property is insufficient to describe the relationship
-between ICIDs and IOMMUs, so an iommu-map property is used to define
-the set of possible ICIDs under a root DPRC and how they map to
-an IOMMU.
+between ICIDs and IOMMUs, so the iommu-map and msi-map properties are used
+to define the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU and a GIC ITS respectively.

  For generic IOMMU bindings, see
  Documentation/devicetree/bindings/iommu/iommu.txt.
@@ -28,6 +28,9 @@ Documentation/devicetree/bindings/iommu/iommu.txt.
  For arm-smmu binding, see:
  Documentation/devicetree/bindings/iommu/arm,smmu.yaml.

+For GICv3 and GIC ITS bindings, see:
+Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml.
+
  Required properties:

      - compatible
@@ -119,6 +122,15 @@ Optional properties:
    associated with the listed IOMMU, with the iommu-specifier
    (i - icid-base + iommu-base).

+- msi-map: Maps an ICID to a GIC ITS and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).

I'm confused because the example has GIC ITS phandle, not an IOMMU.

What is an iommu-base?

Right, I was already halfway through writing a reply to say that all the copy-pasted "iommu" references here should be using the terminology from the pci-msi.txt binding instead.

+
+  Any ICID in the interval [icid-base, icid-base + length) is
+  associated with the listed GIC ITS, with the iommu-specifier
+  (i - icid-base + iommu-base).
  Example:

          smmu: iommu@5000000 {
@@ -128,6 +140,16 @@ Example:
                 ...
          };

+       gic: interrupt-controller@6000000 {
+               compatible = "arm,gic-v3";
+               ...
+               its: gic-its@6020000 {
+                       compatible = "arm,gic-v3-its";
+                       msi-controller;
+                       ...
+               };
+       };
+
          fsl_mc: fsl-mc@80c000000 {
                  compatible = "fsl,qoriq-mc";
                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
@@ -135,6 +157,8 @@ Example:
                  msi-parent = <&its>;

Side note: is it right to keep msi-parent here? It rather implies that the MC itself has a 'native' Device ID rather than an ICID, which I believe is not strictly true. Plus it's extra-confusing that it doesn't specify an ID either way, since that makes it look like the legacy PCI case that gets treated implicitly as an identity msi-map, which makes no sense at all to combine with an actual msi-map.

                  /* define map for ICIDs 23-64 */
                  iommu-map = <23 &smmu 23 41>;
+                /* define msi map for ICIDs 23-64 */
+                msi-map = <23 &its 23 41>;

Seeing 23 twice is odd. The numbers to the right of 'its' should be an
ITS number space.

On about 99% of systems the values in the SMMU Stream ID and ITS Device ID spaces are going to be the same. Nobody's going to bother carrying *two* sets of sideband data across the interconnect if they don't have to ;)

Robin.

                  #address-cells = <3>;
                  #size-cells = <1>;

--
2.26.1

_______________________________________________
iommu mailing list
iommu@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/iommu




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux