* [PATCH v2 0/3] perf/smmuv3: Support devicetree
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
multiple independent PMCGs, for example one for the Translation Control
Unit (TCU) and one per Translation Buffer Unit (TBU).
Since v1 [1]:
* Fixed warnings in the binding doc
* Removed hip08 support
* Merged Robin's version. I took the liberty of splitting the driver
patch into 2 and 3. One fix in patch 3, and whitespace changes (the
driver uses spaces instead of tabs to align #define values, which I
was going to fix but actually seems more common across the tree.)
[1] https://lore.kernel.org/linux-iommu/20211116113536.69758-1-jean-philippe@linaro.org/
Jean-Philippe Brucker (2):
dt-bindings: Add Arm SMMUv3 PMCG binding
perf/smmuv3: Add devicetree support
Robin Murphy (1):
perf/smmuv3: Synthesize IIDR from CoreSight ID registers
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
drivers/perf/arm_smmuv3_pmu.c | 66 ++++++++++++++++-
2 files changed, 134 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
--
2.33.1
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 0/3] perf/smmuv3: Support devicetree
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, Jean-Philippe Brucker, robin.murphy,
iommu, uchida.jun, leo.yan, will, linux-arm-kernel
Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
multiple independent PMCGs, for example one for the Translation Control
Unit (TCU) and one per Translation Buffer Unit (TBU).
Since v1 [1]:
* Fixed warnings in the binding doc
* Removed hip08 support
* Merged Robin's version. I took the liberty of splitting the driver
patch into 2 and 3. One fix in patch 3, and whitespace changes (the
driver uses spaces instead of tabs to align #define values, which I
was going to fix but actually seems more common across the tree.)
[1] https://lore.kernel.org/linux-iommu/20211116113536.69758-1-jean-philippe@linaro.org/
Jean-Philippe Brucker (2):
dt-bindings: Add Arm SMMUv3 PMCG binding
perf/smmuv3: Add devicetree support
Robin Murphy (1):
perf/smmuv3: Synthesize IIDR from CoreSight ID registers
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
drivers/perf/arm_smmuv3_pmu.c | 66 ++++++++++++++++-
2 files changed, 134 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
--
2.33.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 0/3] perf/smmuv3: Support devicetree
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
multiple independent PMCGs, for example one for the Translation Control
Unit (TCU) and one per Translation Buffer Unit (TBU).
Since v1 [1]:
* Fixed warnings in the binding doc
* Removed hip08 support
* Merged Robin's version. I took the liberty of splitting the driver
patch into 2 and 3. One fix in patch 3, and whitespace changes (the
driver uses spaces instead of tabs to align #define values, which I
was going to fix but actually seems more common across the tree.)
[1] https://lore.kernel.org/linux-iommu/20211116113536.69758-1-jean-philippe@linaro.org/
Jean-Philippe Brucker (2):
dt-bindings: Add Arm SMMUv3 PMCG binding
perf/smmuv3: Add devicetree support
Robin Murphy (1):
perf/smmuv3: Synthesize IIDR from CoreSight ID registers
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
drivers/perf/arm_smmuv3_pmu.c | 66 ++++++++++++++++-
2 files changed, 134 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
--
2.33.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
2021-11-17 14:48 ` Jean-Philippe Brucker
(?)
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
-1 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add binding for the Arm SMMUv3 PMU. Each node represents a PMCG, and is
placed as a sibling node of the SMMU. Although the PMCGs registers may
be within the SMMU MMIO region, they are separate devices, and there can
be multiple PMCG devices for each SMMU (for example one for the TCU and
one for each TBU).
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
diff --git a/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
new file mode 100644
index 000000000000..a4b53a6a1ebf
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,smmu-v3-pmcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm SMMUv3 Performance Monitor Counter Group
+
+maintainers:
+ - Will Deacon <will@kernel.org>
+ - Robin Murphy <robin.murphy@arm.com>
+
+description: |
+ An SMMUv3 may have several Performance Monitor Counter Group (PMCG).
+ They are standalone performance monitoring units that support both
+ architected and IMPLEMENTATION DEFINED event counters.
+
+properties:
+ $nodename:
+ pattern: "^pmu@[0-9a-f]*"
+ compatible:
+ oneOf:
+ - items:
+ - const: arm,mmu-600-pmcg
+ - const: arm,smmu-v3-pmcg
+ - const: arm,smmu-v3-pmcg
+
+ reg:
+ items:
+ - description: Register page 0
+ - description: Register page 1, if SMMU_PMCG_CFGR.RELOC_CTRS = 1
+ minItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ msi-parent: true
+
+required:
+ - compatible
+ - reg
+
+anyOf:
+ - required:
+ - interrupts
+ - required:
+ - msi-parent
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmu@2b420000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b420000 0x1000>,
+ <0x2b430000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
+
+ pmu@2b440000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b440000 0x1000>,
+ <0x2b450000 0x1000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
--
2.33.1
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, Jean-Philippe Brucker, robin.murphy,
iommu, uchida.jun, leo.yan, will, linux-arm-kernel
Add binding for the Arm SMMUv3 PMU. Each node represents a PMCG, and is
placed as a sibling node of the SMMU. Although the PMCGs registers may
be within the SMMU MMIO region, they are separate devices, and there can
be multiple PMCG devices for each SMMU (for example one for the TCU and
one for each TBU).
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
diff --git a/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
new file mode 100644
index 000000000000..a4b53a6a1ebf
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,smmu-v3-pmcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm SMMUv3 Performance Monitor Counter Group
+
+maintainers:
+ - Will Deacon <will@kernel.org>
+ - Robin Murphy <robin.murphy@arm.com>
+
+description: |
+ An SMMUv3 may have several Performance Monitor Counter Group (PMCG).
+ They are standalone performance monitoring units that support both
+ architected and IMPLEMENTATION DEFINED event counters.
+
+properties:
+ $nodename:
+ pattern: "^pmu@[0-9a-f]*"
+ compatible:
+ oneOf:
+ - items:
+ - const: arm,mmu-600-pmcg
+ - const: arm,smmu-v3-pmcg
+ - const: arm,smmu-v3-pmcg
+
+ reg:
+ items:
+ - description: Register page 0
+ - description: Register page 1, if SMMU_PMCG_CFGR.RELOC_CTRS = 1
+ minItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ msi-parent: true
+
+required:
+ - compatible
+ - reg
+
+anyOf:
+ - required:
+ - interrupts
+ - required:
+ - msi-parent
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmu@2b420000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b420000 0x1000>,
+ <0x2b430000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
+
+ pmu@2b440000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b440000 0x1000>,
+ <0x2b450000 0x1000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
--
2.33.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add binding for the Arm SMMUv3 PMU. Each node represents a PMCG, and is
placed as a sibling node of the SMMU. Although the PMCGs registers may
be within the SMMU MMIO region, they are separate devices, and there can
be multiple PMCG devices for each SMMU (for example one for the TCU and
one for each TBU).
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
.../bindings/perf/arm,smmu-v3-pmcg.yaml | 70 +++++++++++++++++++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
diff --git a/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
new file mode 100644
index 000000000000..a4b53a6a1ebf
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/arm,smmu-v3-pmcg.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/arm,smmu-v3-pmcg.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm SMMUv3 Performance Monitor Counter Group
+
+maintainers:
+ - Will Deacon <will@kernel.org>
+ - Robin Murphy <robin.murphy@arm.com>
+
+description: |
+ An SMMUv3 may have several Performance Monitor Counter Group (PMCG).
+ They are standalone performance monitoring units that support both
+ architected and IMPLEMENTATION DEFINED event counters.
+
+properties:
+ $nodename:
+ pattern: "^pmu@[0-9a-f]*"
+ compatible:
+ oneOf:
+ - items:
+ - const: arm,mmu-600-pmcg
+ - const: arm,smmu-v3-pmcg
+ - const: arm,smmu-v3-pmcg
+
+ reg:
+ items:
+ - description: Register page 0
+ - description: Register page 1, if SMMU_PMCG_CFGR.RELOC_CTRS = 1
+ minItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ msi-parent: true
+
+required:
+ - compatible
+ - reg
+
+anyOf:
+ - required:
+ - interrupts
+ - required:
+ - msi-parent
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pmu@2b420000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b420000 0x1000>,
+ <0x2b430000 0x1000>;
+ interrupts = <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
+
+ pmu@2b440000 {
+ compatible = "arm,smmu-v3-pmcg";
+ reg = <0x2b440000 0x1000>,
+ <0x2b450000 0x1000>;
+ interrupts = <GIC_SPI 81 IRQ_TYPE_EDGE_RISING>;
+ msi-parent = <&its 0xff0000>;
+ };
--
2.33.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 2/3] perf/smmuv3: Add devicetree support
2021-11-17 14:48 ` Jean-Philippe Brucker
(?)
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
-1 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add device-tree support to the SMMUv3 PMCG driver.
Signed-off-by: Jay Chen <jkchen@linux.alibaba.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/perf/arm_smmuv3_pmu.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 226348822ab3..19697617153a 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -47,6 +47,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/msi.h>
+#include <linux/of.h>
#include <linux/perf_event.h>
#include <linux/platform_device.h>
#include <linux/smp.h>
@@ -834,7 +835,8 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return -EINVAL;
}
- smmu_pmu_get_acpi_options(smmu_pmu);
+ if (!dev->of_node)
+ smmu_pmu_get_acpi_options(smmu_pmu);
/* Pick one CPU to be the preferred one to use */
smmu_pmu->on_cpu = raw_smp_processor_id();
@@ -884,9 +886,16 @@ static void smmu_pmu_shutdown(struct platform_device *pdev)
smmu_pmu_disable(&smmu_pmu->pmu);
}
+static const struct of_device_id smmu_pmu_of_match[] = {
+ { .compatible = "arm,smmu-v3-pmcg" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, smmu_pmu_of_match);
+
static struct platform_driver smmu_pmu_driver = {
.driver = {
.name = "arm-smmu-v3-pmcg",
+ .of_match_table = of_match_ptr(smmu_pmu_of_match),
.suppress_bind_attrs = true,
},
.probe = smmu_pmu_probe,
--
2.33.1
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 2/3] perf/smmuv3: Add devicetree support
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, Jean-Philippe Brucker, robin.murphy,
iommu, uchida.jun, leo.yan, will, linux-arm-kernel
Add device-tree support to the SMMUv3 PMCG driver.
Signed-off-by: Jay Chen <jkchen@linux.alibaba.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/perf/arm_smmuv3_pmu.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 226348822ab3..19697617153a 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -47,6 +47,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/msi.h>
+#include <linux/of.h>
#include <linux/perf_event.h>
#include <linux/platform_device.h>
#include <linux/smp.h>
@@ -834,7 +835,8 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return -EINVAL;
}
- smmu_pmu_get_acpi_options(smmu_pmu);
+ if (!dev->of_node)
+ smmu_pmu_get_acpi_options(smmu_pmu);
/* Pick one CPU to be the preferred one to use */
smmu_pmu->on_cpu = raw_smp_processor_id();
@@ -884,9 +886,16 @@ static void smmu_pmu_shutdown(struct platform_device *pdev)
smmu_pmu_disable(&smmu_pmu->pmu);
}
+static const struct of_device_id smmu_pmu_of_match[] = {
+ { .compatible = "arm,smmu-v3-pmcg" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, smmu_pmu_of_match);
+
static struct platform_driver smmu_pmu_driver = {
.driver = {
.name = "arm-smmu-v3-pmcg",
+ .of_match_table = of_match_ptr(smmu_pmu_of_match),
.suppress_bind_attrs = true,
},
.probe = smmu_pmu_probe,
--
2.33.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 2/3] perf/smmuv3: Add devicetree support
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
Add device-tree support to the SMMUv3 PMCG driver.
Signed-off-by: Jay Chen <jkchen@linux.alibaba.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/perf/arm_smmuv3_pmu.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 226348822ab3..19697617153a 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -47,6 +47,7 @@
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/msi.h>
+#include <linux/of.h>
#include <linux/perf_event.h>
#include <linux/platform_device.h>
#include <linux/smp.h>
@@ -834,7 +835,8 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return -EINVAL;
}
- smmu_pmu_get_acpi_options(smmu_pmu);
+ if (!dev->of_node)
+ smmu_pmu_get_acpi_options(smmu_pmu);
/* Pick one CPU to be the preferred one to use */
smmu_pmu->on_cpu = raw_smp_processor_id();
@@ -884,9 +886,16 @@ static void smmu_pmu_shutdown(struct platform_device *pdev)
smmu_pmu_disable(&smmu_pmu->pmu);
}
+static const struct of_device_id smmu_pmu_of_match[] = {
+ { .compatible = "arm,smmu-v3-pmcg" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, smmu_pmu_of_match);
+
static struct platform_driver smmu_pmu_driver = {
.driver = {
.name = "arm-smmu-v3-pmcg",
+ .of_match_table = of_match_ptr(smmu_pmu_of_match),
.suppress_bind_attrs = true,
},
.probe = smmu_pmu_probe,
--
2.33.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-11-17 14:48 ` Jean-Philippe Brucker
(?)
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
-1 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
From: Robin Murphy <robin.murphy@arm.com>
The SMMU_PMCG_IIDR register was not present in older revisions of the
Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
fields from several PIDR registers, allowing us to present a
standardized identifier to userspace.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/perf/arm_smmuv3_pmu.c | 55 ++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 19697617153a..598d6978280d 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -76,6 +76,10 @@
#define SMMU_PMCG_CR 0xE04
#define SMMU_PMCG_CR_ENABLE BIT(0)
#define SMMU_PMCG_IIDR 0xE08
+#define SMMU_PMCG_IIDR_PRODUCTID GENMASK(31, 20)
+#define SMMU_PMCG_IIDR_VARIANT GENMASK(19, 16)
+#define SMMU_PMCG_IIDR_REVISION GENMASK(15, 12)
+#define SMMU_PMCG_IIDR_IMPLEMENTER GENMASK(11, 0)
#define SMMU_PMCG_CEID0 0xE20
#define SMMU_PMCG_CEID1 0xE28
#define SMMU_PMCG_IRQ_CTRL 0xE50
@@ -84,6 +88,20 @@
#define SMMU_PMCG_IRQ_CFG1 0xE60
#define SMMU_PMCG_IRQ_CFG2 0xE64
+/* IMP-DEF ID registers */
+#define SMMU_PMCG_PIDR0 0xFE0
+#define SMMU_PMCG_PIDR0_PART_0 GENMASK(7, 0)
+#define SMMU_PMCG_PIDR1 0xFE4
+#define SMMU_PMCG_PIDR1_DES_0 GENMASK(7, 4)
+#define SMMU_PMCG_PIDR1_PART_1 GENMASK(3, 0)
+#define SMMU_PMCG_PIDR2 0xFE8
+#define SMMU_PMCG_PIDR2_REVISION GENMASK(7, 4)
+#define SMMU_PMCG_PIDR2_DES_1 GENMASK(2, 0)
+#define SMMU_PMCG_PIDR3 0xFEC
+#define SMMU_PMCG_PIDR3_REVAND GENMASK(7, 4)
+#define SMMU_PMCG_PIDR4 0xFD0
+#define SMMU_PMCG_PIDR4_DES_2 GENMASK(3, 0)
+
/* MSI config fields */
#define MSI_CFG0_ADDR_MASK GENMASK_ULL(51, 2)
#define MSI_CFG2_MEMATTR_DEVICE_nGnRE 0x1
@@ -755,6 +773,41 @@ static void smmu_pmu_get_acpi_options(struct smmu_pmu *smmu_pmu)
dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
}
+static bool smmu_pmu_coresight_id_regs(struct smmu_pmu *smmu_pmu)
+{
+ return of_device_is_compatible(smmu_pmu->dev->of_node,
+ "arm,mmu-600-pmcg");
+}
+
+static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
+{
+ u32 iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+
+ if (!iidr && smmu_pmu_coresight_id_regs(smmu_pmu)) {
+ u32 pidr0 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR0);
+ u32 pidr1 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR1);
+ u32 pidr2 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR2);
+ u32 pidr3 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR3);
+ u32 pidr4 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR4);
+
+ u32 productid = FIELD_GET(SMMU_PMCG_PIDR0_PART_0, pidr0) |
+ (FIELD_GET(SMMU_PMCG_PIDR1_PART_1, pidr1) << 8);
+ u32 variant = FIELD_GET(SMMU_PMCG_PIDR2_REVISION, pidr2);
+ u32 revision = FIELD_GET(SMMU_PMCG_PIDR3_REVAND, pidr3);
+ u32 implementer =
+ FIELD_GET(SMMU_PMCG_PIDR1_DES_0, pidr1) |
+ (FIELD_GET(SMMU_PMCG_PIDR2_DES_1, pidr2) << 4) |
+ (FIELD_GET(SMMU_PMCG_PIDR4_DES_2, pidr4) << 8);
+
+ iidr = FIELD_PREP(SMMU_PMCG_IIDR_PRODUCTID, productid) |
+ FIELD_PREP(SMMU_PMCG_IIDR_VARIANT, variant) |
+ FIELD_PREP(SMMU_PMCG_IIDR_REVISION, revision) |
+ FIELD_PREP(SMMU_PMCG_IIDR_IMPLEMENTER, implementer);
+ }
+
+ smmu_pmu->iidr = iidr;
+}
+
static int smmu_pmu_probe(struct platform_device *pdev)
{
struct smmu_pmu *smmu_pmu;
@@ -826,7 +879,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return err;
}
- smmu_pmu->iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+ smmu_pmu_get_iidr(smmu_pmu);
name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "smmuv3_pmcg_%llx",
(res_0->start) >> SMMU_PMCG_PA_SHIFT);
--
2.33.1
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: mark.rutland, devicetree, Jean-Philippe Brucker, robin.murphy,
iommu, uchida.jun, leo.yan, will, linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com>
The SMMU_PMCG_IIDR register was not present in older revisions of the
Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
fields from several PIDR registers, allowing us to present a
standardized identifier to userspace.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/perf/arm_smmuv3_pmu.c | 55 ++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 19697617153a..598d6978280d 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -76,6 +76,10 @@
#define SMMU_PMCG_CR 0xE04
#define SMMU_PMCG_CR_ENABLE BIT(0)
#define SMMU_PMCG_IIDR 0xE08
+#define SMMU_PMCG_IIDR_PRODUCTID GENMASK(31, 20)
+#define SMMU_PMCG_IIDR_VARIANT GENMASK(19, 16)
+#define SMMU_PMCG_IIDR_REVISION GENMASK(15, 12)
+#define SMMU_PMCG_IIDR_IMPLEMENTER GENMASK(11, 0)
#define SMMU_PMCG_CEID0 0xE20
#define SMMU_PMCG_CEID1 0xE28
#define SMMU_PMCG_IRQ_CTRL 0xE50
@@ -84,6 +88,20 @@
#define SMMU_PMCG_IRQ_CFG1 0xE60
#define SMMU_PMCG_IRQ_CFG2 0xE64
+/* IMP-DEF ID registers */
+#define SMMU_PMCG_PIDR0 0xFE0
+#define SMMU_PMCG_PIDR0_PART_0 GENMASK(7, 0)
+#define SMMU_PMCG_PIDR1 0xFE4
+#define SMMU_PMCG_PIDR1_DES_0 GENMASK(7, 4)
+#define SMMU_PMCG_PIDR1_PART_1 GENMASK(3, 0)
+#define SMMU_PMCG_PIDR2 0xFE8
+#define SMMU_PMCG_PIDR2_REVISION GENMASK(7, 4)
+#define SMMU_PMCG_PIDR2_DES_1 GENMASK(2, 0)
+#define SMMU_PMCG_PIDR3 0xFEC
+#define SMMU_PMCG_PIDR3_REVAND GENMASK(7, 4)
+#define SMMU_PMCG_PIDR4 0xFD0
+#define SMMU_PMCG_PIDR4_DES_2 GENMASK(3, 0)
+
/* MSI config fields */
#define MSI_CFG0_ADDR_MASK GENMASK_ULL(51, 2)
#define MSI_CFG2_MEMATTR_DEVICE_nGnRE 0x1
@@ -755,6 +773,41 @@ static void smmu_pmu_get_acpi_options(struct smmu_pmu *smmu_pmu)
dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
}
+static bool smmu_pmu_coresight_id_regs(struct smmu_pmu *smmu_pmu)
+{
+ return of_device_is_compatible(smmu_pmu->dev->of_node,
+ "arm,mmu-600-pmcg");
+}
+
+static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
+{
+ u32 iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+
+ if (!iidr && smmu_pmu_coresight_id_regs(smmu_pmu)) {
+ u32 pidr0 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR0);
+ u32 pidr1 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR1);
+ u32 pidr2 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR2);
+ u32 pidr3 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR3);
+ u32 pidr4 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR4);
+
+ u32 productid = FIELD_GET(SMMU_PMCG_PIDR0_PART_0, pidr0) |
+ (FIELD_GET(SMMU_PMCG_PIDR1_PART_1, pidr1) << 8);
+ u32 variant = FIELD_GET(SMMU_PMCG_PIDR2_REVISION, pidr2);
+ u32 revision = FIELD_GET(SMMU_PMCG_PIDR3_REVAND, pidr3);
+ u32 implementer =
+ FIELD_GET(SMMU_PMCG_PIDR1_DES_0, pidr1) |
+ (FIELD_GET(SMMU_PMCG_PIDR2_DES_1, pidr2) << 4) |
+ (FIELD_GET(SMMU_PMCG_PIDR4_DES_2, pidr4) << 8);
+
+ iidr = FIELD_PREP(SMMU_PMCG_IIDR_PRODUCTID, productid) |
+ FIELD_PREP(SMMU_PMCG_IIDR_VARIANT, variant) |
+ FIELD_PREP(SMMU_PMCG_IIDR_REVISION, revision) |
+ FIELD_PREP(SMMU_PMCG_IIDR_IMPLEMENTER, implementer);
+ }
+
+ smmu_pmu->iidr = iidr;
+}
+
static int smmu_pmu_probe(struct platform_device *pdev)
{
struct smmu_pmu *smmu_pmu;
@@ -826,7 +879,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return err;
}
- smmu_pmu->iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+ smmu_pmu_get_iidr(smmu_pmu);
name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "smmuv3_pmcg_%llx",
(res_0->start) >> SMMU_PMCG_PA_SHIFT);
--
2.33.1
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-11-17 14:48 ` Jean-Philippe Brucker
0 siblings, 0 replies; 42+ messages in thread
From: Jean-Philippe Brucker @ 2021-11-17 14:48 UTC (permalink / raw)
To: robh+dt
Cc: iommu, devicetree, linux-arm-kernel, will, robin.murphy, joro,
mark.rutland, jkchen, leo.yan, uchida.jun, Jean-Philippe Brucker
From: Robin Murphy <robin.murphy@arm.com>
The SMMU_PMCG_IIDR register was not present in older revisions of the
Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
fields from several PIDR registers, allowing us to present a
standardized identifier to userspace.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
---
drivers/perf/arm_smmuv3_pmu.c | 55 ++++++++++++++++++++++++++++++++++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 19697617153a..598d6978280d 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++ b/drivers/perf/arm_smmuv3_pmu.c
@@ -76,6 +76,10 @@
#define SMMU_PMCG_CR 0xE04
#define SMMU_PMCG_CR_ENABLE BIT(0)
#define SMMU_PMCG_IIDR 0xE08
+#define SMMU_PMCG_IIDR_PRODUCTID GENMASK(31, 20)
+#define SMMU_PMCG_IIDR_VARIANT GENMASK(19, 16)
+#define SMMU_PMCG_IIDR_REVISION GENMASK(15, 12)
+#define SMMU_PMCG_IIDR_IMPLEMENTER GENMASK(11, 0)
#define SMMU_PMCG_CEID0 0xE20
#define SMMU_PMCG_CEID1 0xE28
#define SMMU_PMCG_IRQ_CTRL 0xE50
@@ -84,6 +88,20 @@
#define SMMU_PMCG_IRQ_CFG1 0xE60
#define SMMU_PMCG_IRQ_CFG2 0xE64
+/* IMP-DEF ID registers */
+#define SMMU_PMCG_PIDR0 0xFE0
+#define SMMU_PMCG_PIDR0_PART_0 GENMASK(7, 0)
+#define SMMU_PMCG_PIDR1 0xFE4
+#define SMMU_PMCG_PIDR1_DES_0 GENMASK(7, 4)
+#define SMMU_PMCG_PIDR1_PART_1 GENMASK(3, 0)
+#define SMMU_PMCG_PIDR2 0xFE8
+#define SMMU_PMCG_PIDR2_REVISION GENMASK(7, 4)
+#define SMMU_PMCG_PIDR2_DES_1 GENMASK(2, 0)
+#define SMMU_PMCG_PIDR3 0xFEC
+#define SMMU_PMCG_PIDR3_REVAND GENMASK(7, 4)
+#define SMMU_PMCG_PIDR4 0xFD0
+#define SMMU_PMCG_PIDR4_DES_2 GENMASK(3, 0)
+
/* MSI config fields */
#define MSI_CFG0_ADDR_MASK GENMASK_ULL(51, 2)
#define MSI_CFG2_MEMATTR_DEVICE_nGnRE 0x1
@@ -755,6 +773,41 @@ static void smmu_pmu_get_acpi_options(struct smmu_pmu *smmu_pmu)
dev_notice(smmu_pmu->dev, "option mask 0x%x\n", smmu_pmu->options);
}
+static bool smmu_pmu_coresight_id_regs(struct smmu_pmu *smmu_pmu)
+{
+ return of_device_is_compatible(smmu_pmu->dev->of_node,
+ "arm,mmu-600-pmcg");
+}
+
+static void smmu_pmu_get_iidr(struct smmu_pmu *smmu_pmu)
+{
+ u32 iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+
+ if (!iidr && smmu_pmu_coresight_id_regs(smmu_pmu)) {
+ u32 pidr0 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR0);
+ u32 pidr1 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR1);
+ u32 pidr2 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR2);
+ u32 pidr3 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR3);
+ u32 pidr4 = readl(smmu_pmu->reg_base + SMMU_PMCG_PIDR4);
+
+ u32 productid = FIELD_GET(SMMU_PMCG_PIDR0_PART_0, pidr0) |
+ (FIELD_GET(SMMU_PMCG_PIDR1_PART_1, pidr1) << 8);
+ u32 variant = FIELD_GET(SMMU_PMCG_PIDR2_REVISION, pidr2);
+ u32 revision = FIELD_GET(SMMU_PMCG_PIDR3_REVAND, pidr3);
+ u32 implementer =
+ FIELD_GET(SMMU_PMCG_PIDR1_DES_0, pidr1) |
+ (FIELD_GET(SMMU_PMCG_PIDR2_DES_1, pidr2) << 4) |
+ (FIELD_GET(SMMU_PMCG_PIDR4_DES_2, pidr4) << 8);
+
+ iidr = FIELD_PREP(SMMU_PMCG_IIDR_PRODUCTID, productid) |
+ FIELD_PREP(SMMU_PMCG_IIDR_VARIANT, variant) |
+ FIELD_PREP(SMMU_PMCG_IIDR_REVISION, revision) |
+ FIELD_PREP(SMMU_PMCG_IIDR_IMPLEMENTER, implementer);
+ }
+
+ smmu_pmu->iidr = iidr;
+}
+
static int smmu_pmu_probe(struct platform_device *pdev)
{
struct smmu_pmu *smmu_pmu;
@@ -826,7 +879,7 @@ static int smmu_pmu_probe(struct platform_device *pdev)
return err;
}
- smmu_pmu->iidr = readl_relaxed(smmu_pmu->reg_base + SMMU_PMCG_IIDR);
+ smmu_pmu_get_iidr(smmu_pmu);
name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "smmuv3_pmcg_%llx",
(res_0->start) >> SMMU_PMCG_PA_SHIFT);
--
2.33.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-11-17 14:48 ` Jean-Philippe Brucker
(?)
@ 2021-12-07 9:14 ` John Garry via iommu
-1 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 9:14 UTC (permalink / raw)
To: Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, robin.murphy, iommu, uchida.jun,
leo.yan, will, linux-arm-kernel
On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
> From: Robin Murphy<robin.murphy@arm.com>
>
> The SMMU_PMCG_IIDR register was not present in older revisions of the
> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
> fields from several PIDR registers, allowing us to present a
> standardized identifier to userspace.
>
So is there some userspace part to go with this now?
Thanks,
John
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 9:14 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry via iommu @ 2021-12-07 9:14 UTC (permalink / raw)
To: Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, will, iommu, uchida.jun, leo.yan,
robin.murphy, linux-arm-kernel
On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
> From: Robin Murphy<robin.murphy@arm.com>
>
> The SMMU_PMCG_IIDR register was not present in older revisions of the
> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
> fields from several PIDR registers, allowing us to present a
> standardized identifier to userspace.
>
So is there some userspace part to go with this now?
Thanks,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 9:14 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 9:14 UTC (permalink / raw)
To: Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, robin.murphy, iommu, uchida.jun,
leo.yan, will, linux-arm-kernel
On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
> From: Robin Murphy<robin.murphy@arm.com>
>
> The SMMU_PMCG_IIDR register was not present in older revisions of the
> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
> fields from several PIDR registers, allowing us to present a
> standardized identifier to userspace.
>
So is there some userspace part to go with this now?
Thanks,
John
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 9:14 ` John Garry via iommu
(?)
@ 2021-12-07 12:04 ` Robin Murphy
-1 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:04 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 2021-12-07 09:14, John Garry wrote:
> On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
>> From: Robin Murphy<robin.murphy@arm.com>
>>
>> The SMMU_PMCG_IIDR register was not present in older revisions of the
>> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
>> fields from several PIDR registers, allowing us to present a
>> standardized identifier to userspace.
>>
> So is there some userspace part to go with this now?
FWIW I've not looked into it - is it just a case of someone knocking out
some JSON from the MMU-600/700 TRMs, or is there still mroe to do? I had
the impression that *some* part of the process was stalled until
implementations can start providing meaningful IIDRs, but I wasn't sure
whether that was tooling or just data. I just work the low-level
enablement angle :)
Robin.
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:04 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:04 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 2021-12-07 09:14, John Garry wrote:
> On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
>> From: Robin Murphy<robin.murphy@arm.com>
>>
>> The SMMU_PMCG_IIDR register was not present in older revisions of the
>> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
>> fields from several PIDR registers, allowing us to present a
>> standardized identifier to userspace.
>>
> So is there some userspace part to go with this now?
FWIW I've not looked into it - is it just a case of someone knocking out
some JSON from the MMU-600/700 TRMs, or is there still mroe to do? I had
the impression that *some* part of the process was stalled until
implementations can start providing meaningful IIDRs, but I wasn't sure
whether that was tooling or just data. I just work the low-level
enablement angle :)
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:04 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:04 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 2021-12-07 09:14, John Garry wrote:
> On 17/11/2021 14:48, Jean-Philippe Brucker wrote:
>> From: Robin Murphy<robin.murphy@arm.com>
>>
>> The SMMU_PMCG_IIDR register was not present in older revisions of the
>> Arm SMMUv3 spec. On Arm Ltd. implementations, the IIDR value consists of
>> fields from several PIDR registers, allowing us to present a
>> standardized identifier to userspace.
>>
> So is there some userspace part to go with this now?
FWIW I've not looked into it - is it just a case of someone knocking out
some JSON from the MMU-600/700 TRMs, or is there still mroe to do? I had
the impression that *some* part of the process was stalled until
implementations can start providing meaningful IIDRs, but I wasn't sure
whether that was tooling or just data. I just work the low-level
enablement angle :)
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 12:04 ` Robin Murphy
(?)
@ 2021-12-07 12:28 ` John Garry via iommu
-1 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 12:28 UTC (permalink / raw)
To: Robin Murphy, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 07/12/2021 12:04, Robin Murphy wrote:
>>>
>> So is there some userspace part to go with this now?
>
> FWIW I've not looked into it - is it just a case of someone knocking out
> some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
That should just be it.
> I had
> the impression that *some* part of the process was stalled until
> implementations can start providing meaningful IIDRs, but I wasn't sure
> whether that was tooling or just data. I just work the low-level
> enablement angle :)
Tooling should be ok, but I would just like to see more of these JSONs
so any tooling issues can be ironed out.
Cheers,
John
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:28 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry via iommu @ 2021-12-07 12:28 UTC (permalink / raw)
To: Robin Murphy, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 07/12/2021 12:04, Robin Murphy wrote:
>>>
>> So is there some userspace part to go with this now?
>
> FWIW I've not looked into it - is it just a case of someone knocking out
> some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
That should just be it.
> I had
> the impression that *some* part of the process was stalled until
> implementations can start providing meaningful IIDRs, but I wasn't sure
> whether that was tooling or just data. I just work the low-level
> enablement angle :)
Tooling should be ok, but I would just like to see more of these JSONs
so any tooling issues can be ironed out.
Cheers,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:28 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 12:28 UTC (permalink / raw)
To: Robin Murphy, Jean-Philippe Brucker, robh+dt
Cc: mark.rutland, devicetree, iommu, uchida.jun, leo.yan, will,
linux-arm-kernel
On 07/12/2021 12:04, Robin Murphy wrote:
>>>
>> So is there some userspace part to go with this now?
>
> FWIW I've not looked into it - is it just a case of someone knocking out
> some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
That should just be it.
> I had
> the impression that *some* part of the process was stalled until
> implementations can start providing meaningful IIDRs, but I wasn't sure
> whether that was tooling or just data. I just work the low-level
> enablement angle :)
Tooling should be ok, but I would just like to see more of these JSONs
so any tooling issues can be ironed out.
Cheers,
John
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 12:28 ` John Garry via iommu
(?)
@ 2021-12-07 12:48 ` Robin Murphy
-1 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:48 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, leo.yan
Cc: mark.rutland, devicetree, iommu, robh+dt, uchida.jun, will,
linux-arm-kernel
On 2021-12-07 12:28, John Garry via iommu wrote:
> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>
>>> So is there some userspace part to go with this now?
>>
>> FWIW I've not looked into it - is it just a case of someone knocking
>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
>
> That should just be it.
>
>> I had the impression that *some* part of the process was stalled until
>> implementations can start providing meaningful IIDRs, but I wasn't
>> sure whether that was tooling or just data. I just work the low-level
>> enablement angle :)
>
> Tooling should be ok, but I would just like to see more of these JSONs
> so any tooling issues can be ironed out.
Sounds good - Jean, Leo, is that something Linaro might like to pick up
as part of the PMCG interest, or shall I make a note on my to-do list
for the new year?
Thanks,
Robin.
>
> Cheers,
> John
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:48 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:48 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, leo.yan
Cc: mark.rutland, devicetree, iommu, uchida.jun, will,
linux-arm-kernel, robh+dt
On 2021-12-07 12:28, John Garry via iommu wrote:
> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>
>>> So is there some userspace part to go with this now?
>>
>> FWIW I've not looked into it - is it just a case of someone knocking
>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
>
> That should just be it.
>
>> I had the impression that *some* part of the process was stalled until
>> implementations can start providing meaningful IIDRs, but I wasn't
>> sure whether that was tooling or just data. I just work the low-level
>> enablement angle :)
>
> Tooling should be ok, but I would just like to see more of these JSONs
> so any tooling issues can be ironed out.
Sounds good - Jean, Leo, is that something Linaro might like to pick up
as part of the PMCG interest, or shall I make a note on my to-do list
for the new year?
Thanks,
Robin.
>
> Cheers,
> John
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 12:48 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 12:48 UTC (permalink / raw)
To: John Garry, Jean-Philippe Brucker, leo.yan
Cc: mark.rutland, devicetree, iommu, uchida.jun, will,
linux-arm-kernel, robh+dt
On 2021-12-07 12:28, John Garry via iommu wrote:
> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>
>>> So is there some userspace part to go with this now?
>>
>> FWIW I've not looked into it - is it just a case of someone knocking
>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to do?
>
> That should just be it.
>
>> I had the impression that *some* part of the process was stalled until
>> implementations can start providing meaningful IIDRs, but I wasn't
>> sure whether that was tooling or just data. I just work the low-level
>> enablement angle :)
>
> Tooling should be ok, but I would just like to see more of these JSONs
> so any tooling issues can be ironed out.
Sounds good - Jean, Leo, is that something Linaro might like to pick up
as part of the PMCG interest, or shall I make a note on my to-do list
for the new year?
Thanks,
Robin.
>
> Cheers,
> John
>
> _______________________________________________
> iommu mailing list
> iommu@lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/iommu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 12:48 ` Robin Murphy
(?)
@ 2021-12-07 13:20 ` Leo Yan
-1 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:20 UTC (permalink / raw)
To: Robin Murphy
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
> On 2021-12-07 12:28, John Garry via iommu wrote:
> > On 07/12/2021 12:04, Robin Murphy wrote:
> > > > >
> > > > So is there some userspace part to go with this now?
> > >
> > > FWIW I've not looked into it - is it just a case of someone knocking
> > > out some JSON from the MMU-600/700 TRMs, or is there still mroe to
> > > do?
> >
> > That should just be it.
Hope I didn't arrive too late :)
Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
which is just addressed by this patchset; and the PMU event aliasing
for SMMUv3 PMU, before I inquired with John and John said he would
upstream the related patches after kernel can export a IIDR value via
sysfs node.
Seems to me, after this patchset for DT binding and PMU event alias
patches are landed to the mainline kernel, it would be perfect.
> > > I had the impression that *some* part of the process was stalled
> > > until implementations can start providing meaningful IIDRs, but I
> > > wasn't sure whether that was tooling or just data. I just work the
> > > low-level enablement angle :)
> >
> > Tooling should be ok, but I would just like to see more of these JSONs
> > so any tooling issues can be ironed out.
>
> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
> part of the PMCG interest, or shall I make a note on my to-do list for the
> new year?
I took a look for current patch for using PIDR to synthesize IIDR, it
looks good to me. But I tested it on Hisilicon D06 board and observed
the composed IIDR values are still zeros.
I added a printk sentence to dump iidr value at the end of the function
smmu_pmu_get_iidr():
leoy@ubuntu:~$ dmesg | grep iidr
[ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
[ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
[ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
[ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
[ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
[ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
[ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
[ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
Please confirm if this is expected or not? I think this might
introduce difficulty for John for the PMU event alias patches, which
is dependent on a non-zero IIDR.
At last, very appreciate your (Jean-Philippe, Robin and John) help!
Thanks,
Leo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:20 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:20 UTC (permalink / raw)
To: Robin Murphy
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
> On 2021-12-07 12:28, John Garry via iommu wrote:
> > On 07/12/2021 12:04, Robin Murphy wrote:
> > > > >
> > > > So is there some userspace part to go with this now?
> > >
> > > FWIW I've not looked into it - is it just a case of someone knocking
> > > out some JSON from the MMU-600/700 TRMs, or is there still mroe to
> > > do?
> >
> > That should just be it.
Hope I didn't arrive too late :)
Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
which is just addressed by this patchset; and the PMU event aliasing
for SMMUv3 PMU, before I inquired with John and John said he would
upstream the related patches after kernel can export a IIDR value via
sysfs node.
Seems to me, after this patchset for DT binding and PMU event alias
patches are landed to the mainline kernel, it would be perfect.
> > > I had the impression that *some* part of the process was stalled
> > > until implementations can start providing meaningful IIDRs, but I
> > > wasn't sure whether that was tooling or just data. I just work the
> > > low-level enablement angle :)
> >
> > Tooling should be ok, but I would just like to see more of these JSONs
> > so any tooling issues can be ironed out.
>
> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
> part of the PMCG interest, or shall I make a note on my to-do list for the
> new year?
I took a look for current patch for using PIDR to synthesize IIDR, it
looks good to me. But I tested it on Hisilicon D06 board and observed
the composed IIDR values are still zeros.
I added a printk sentence to dump iidr value at the end of the function
smmu_pmu_get_iidr():
leoy@ubuntu:~$ dmesg | grep iidr
[ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
[ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
[ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
[ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
[ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
[ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
[ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
[ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
Please confirm if this is expected or not? I think this might
introduce difficulty for John for the PMU event alias patches, which
is dependent on a non-zero IIDR.
At last, very appreciate your (Jean-Philippe, Robin and John) help!
Thanks,
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:20 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:20 UTC (permalink / raw)
To: Robin Murphy
Cc: mark.rutland, Jean-Philippe Brucker, devicetree, iommu, robh+dt,
uchida.jun, will, linux-arm-kernel
On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
> On 2021-12-07 12:28, John Garry via iommu wrote:
> > On 07/12/2021 12:04, Robin Murphy wrote:
> > > > >
> > > > So is there some userspace part to go with this now?
> > >
> > > FWIW I've not looked into it - is it just a case of someone knocking
> > > out some JSON from the MMU-600/700 TRMs, or is there still mroe to
> > > do?
> >
> > That should just be it.
Hope I didn't arrive too late :)
Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
which is just addressed by this patchset; and the PMU event aliasing
for SMMUv3 PMU, before I inquired with John and John said he would
upstream the related patches after kernel can export a IIDR value via
sysfs node.
Seems to me, after this patchset for DT binding and PMU event alias
patches are landed to the mainline kernel, it would be perfect.
> > > I had the impression that *some* part of the process was stalled
> > > until implementations can start providing meaningful IIDRs, but I
> > > wasn't sure whether that was tooling or just data. I just work the
> > > low-level enablement angle :)
> >
> > Tooling should be ok, but I would just like to see more of these JSONs
> > so any tooling issues can be ironed out.
>
> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
> part of the PMCG interest, or shall I make a note on my to-do list for the
> new year?
I took a look for current patch for using PIDR to synthesize IIDR, it
looks good to me. But I tested it on Hisilicon D06 board and observed
the composed IIDR values are still zeros.
I added a printk sentence to dump iidr value at the end of the function
smmu_pmu_get_iidr():
leoy@ubuntu:~$ dmesg | grep iidr
[ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
[ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
[ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
[ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
[ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
[ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
[ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
[ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
Please confirm if this is expected or not? I think this might
introduce difficulty for John for the PMU event alias patches, which
is dependent on a non-zero IIDR.
At last, very appreciate your (Jean-Philippe, Robin and John) help!
Thanks,
Leo
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 13:20 ` Leo Yan
(?)
@ 2021-12-07 13:46 ` Robin Murphy
-1 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 13:46 UTC (permalink / raw)
To: Leo Yan
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On 2021-12-07 13:20, Leo Yan wrote:
> On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
>> On 2021-12-07 12:28, John Garry via iommu wrote:
>>> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>>>
>>>>> So is there some userspace part to go with this now?
>>>>
>>>> FWIW I've not looked into it - is it just a case of someone knocking
>>>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to
>>>> do?
>>>
>>> That should just be it.
>
> Hope I didn't arrive too late :)
>
> Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
> which is just addressed by this patchset; and the PMU event aliasing
> for SMMUv3 PMU, before I inquired with John and John said he would
> upstream the related patches after kernel can export a IIDR value via
> sysfs node.
>
> Seems to me, after this patchset for DT binding and PMU event alias
> patches are landed to the mainline kernel, it would be perfect.
>
>>>> I had the impression that *some* part of the process was stalled
>>>> until implementations can start providing meaningful IIDRs, but I
>>>> wasn't sure whether that was tooling or just data. I just work the
>>>> low-level enablement angle :)
>>>
>>> Tooling should be ok, but I would just like to see more of these JSONs
>>> so any tooling issues can be ironed out.
>>
>> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
>> part of the PMCG interest, or shall I make a note on my to-do list for the
>> new year?
>
> I took a look for current patch for using PIDR to synthesize IIDR, it
> looks good to me. But I tested it on Hisilicon D06 board and observed
> the composed IIDR values are still zeros.
>
> I added a printk sentence to dump iidr value at the end of the function
> smmu_pmu_get_iidr():
>
> leoy@ubuntu:~$ dmesg | grep iidr
> [ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
> [ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
> [ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
> [ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
> [ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
> [ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
> [ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
> [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
>
> Please confirm if this is expected or not? I think this might
> introduce difficulty for John for the PMU event alias patches, which
> is dependent on a non-zero IIDR.
Yes, from previous discussions I believe the HiSilicon implementations
don't have much meaningful ID information at all (hence why we have to
match ACPI table headers to identify the counter erratum). My trick only
works for Arm Ltd. implementations since they happen to have the IMP-DEF
CoreSight registers with the same information as would be in the future
IIDR.
To clarify, the proposal at this point is to write up JSON files for
MMU-600/MMU-700, based on this patch, in order to pipe-clean the process
for future SMMUv3.3 PMCG implementations with real IIDRs.
Whether other implementers might retroactively define "equivalent" IIDR
values for their existing implementations in a way we could potentially
quirk in the driver is an orthogonal question.
Cheers,
Robin.
>
> At last, very appreciate your (Jean-Philippe, Robin and John) help!
>
> Thanks,
> Leo
>
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:46 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 13:46 UTC (permalink / raw)
To: Leo Yan
Cc: mark.rutland, Jean-Philippe Brucker, devicetree, iommu, robh+dt,
uchida.jun, will, linux-arm-kernel
On 2021-12-07 13:20, Leo Yan wrote:
> On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
>> On 2021-12-07 12:28, John Garry via iommu wrote:
>>> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>>>
>>>>> So is there some userspace part to go with this now?
>>>>
>>>> FWIW I've not looked into it - is it just a case of someone knocking
>>>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to
>>>> do?
>>>
>>> That should just be it.
>
> Hope I didn't arrive too late :)
>
> Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
> which is just addressed by this patchset; and the PMU event aliasing
> for SMMUv3 PMU, before I inquired with John and John said he would
> upstream the related patches after kernel can export a IIDR value via
> sysfs node.
>
> Seems to me, after this patchset for DT binding and PMU event alias
> patches are landed to the mainline kernel, it would be perfect.
>
>>>> I had the impression that *some* part of the process was stalled
>>>> until implementations can start providing meaningful IIDRs, but I
>>>> wasn't sure whether that was tooling or just data. I just work the
>>>> low-level enablement angle :)
>>>
>>> Tooling should be ok, but I would just like to see more of these JSONs
>>> so any tooling issues can be ironed out.
>>
>> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
>> part of the PMCG interest, or shall I make a note on my to-do list for the
>> new year?
>
> I took a look for current patch for using PIDR to synthesize IIDR, it
> looks good to me. But I tested it on Hisilicon D06 board and observed
> the composed IIDR values are still zeros.
>
> I added a printk sentence to dump iidr value at the end of the function
> smmu_pmu_get_iidr():
>
> leoy@ubuntu:~$ dmesg | grep iidr
> [ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
> [ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
> [ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
> [ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
> [ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
> [ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
> [ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
> [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
>
> Please confirm if this is expected or not? I think this might
> introduce difficulty for John for the PMU event alias patches, which
> is dependent on a non-zero IIDR.
Yes, from previous discussions I believe the HiSilicon implementations
don't have much meaningful ID information at all (hence why we have to
match ACPI table headers to identify the counter erratum). My trick only
works for Arm Ltd. implementations since they happen to have the IMP-DEF
CoreSight registers with the same information as would be in the future
IIDR.
To clarify, the proposal at this point is to write up JSON files for
MMU-600/MMU-700, based on this patch, in order to pipe-clean the process
for future SMMUv3.3 PMCG implementations with real IIDRs.
Whether other implementers might retroactively define "equivalent" IIDR
values for their existing implementations in a way we could potentially
quirk in the driver is an orthogonal question.
Cheers,
Robin.
>
> At last, very appreciate your (Jean-Philippe, Robin and John) help!
>
> Thanks,
> Leo
>
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:46 ` Robin Murphy
0 siblings, 0 replies; 42+ messages in thread
From: Robin Murphy @ 2021-12-07 13:46 UTC (permalink / raw)
To: Leo Yan
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On 2021-12-07 13:20, Leo Yan wrote:
> On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
>> On 2021-12-07 12:28, John Garry via iommu wrote:
>>> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>>>
>>>>> So is there some userspace part to go with this now?
>>>>
>>>> FWIW I've not looked into it - is it just a case of someone knocking
>>>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to
>>>> do?
>>>
>>> That should just be it.
>
> Hope I didn't arrive too late :)
>
> Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
> which is just addressed by this patchset; and the PMU event aliasing
> for SMMUv3 PMU, before I inquired with John and John said he would
> upstream the related patches after kernel can export a IIDR value via
> sysfs node.
>
> Seems to me, after this patchset for DT binding and PMU event alias
> patches are landed to the mainline kernel, it would be perfect.
>
>>>> I had the impression that *some* part of the process was stalled
>>>> until implementations can start providing meaningful IIDRs, but I
>>>> wasn't sure whether that was tooling or just data. I just work the
>>>> low-level enablement angle :)
>>>
>>> Tooling should be ok, but I would just like to see more of these JSONs
>>> so any tooling issues can be ironed out.
>>
>> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
>> part of the PMCG interest, or shall I make a note on my to-do list for the
>> new year?
>
> I took a look for current patch for using PIDR to synthesize IIDR, it
> looks good to me. But I tested it on Hisilicon D06 board and observed
> the composed IIDR values are still zeros.
>
> I added a printk sentence to dump iidr value at the end of the function
> smmu_pmu_get_iidr():
>
> leoy@ubuntu:~$ dmesg | grep iidr
> [ 28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
> [ 28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
> [ 28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
> [ 28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
> [ 28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
> [ 28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
> [ 28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
> [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
>
> Please confirm if this is expected or not? I think this might
> introduce difficulty for John for the PMU event alias patches, which
> is dependent on a non-zero IIDR.
Yes, from previous discussions I believe the HiSilicon implementations
don't have much meaningful ID information at all (hence why we have to
match ACPI table headers to identify the counter erratum). My trick only
works for Arm Ltd. implementations since they happen to have the IMP-DEF
CoreSight registers with the same information as would be in the future
IIDR.
To clarify, the proposal at this point is to write up JSON files for
MMU-600/MMU-700, based on this patch, in order to pipe-clean the process
for future SMMUv3.3 PMCG implementations with real IIDRs.
Whether other implementers might retroactively define "equivalent" IIDR
values for their existing implementations in a way we could potentially
quirk in the driver is an orthogonal question.
Cheers,
Robin.
>
> At last, very appreciate your (Jean-Philippe, Robin and John) help!
>
> Thanks,
> Leo
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 13:46 ` Robin Murphy
(?)
@ 2021-12-07 13:59 ` Leo Yan
-1 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:59 UTC (permalink / raw)
To: Robin Murphy
Cc: mark.rutland, Jean-Philippe Brucker, devicetree, iommu, robh+dt,
uchida.jun, will, linux-arm-kernel
On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:
[...]
> > [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> >
> > Please confirm if this is expected or not? I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
>
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
>
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
>
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.
Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.
Thanks for explanation.
Leo
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:59 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:59 UTC (permalink / raw)
To: Robin Murphy
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:
[...]
> > [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> >
> > Please confirm if this is expected or not? I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
>
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
>
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
>
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.
Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.
Thanks for explanation.
Leo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 13:59 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 13:59 UTC (permalink / raw)
To: Robin Murphy
Cc: John Garry, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 01:46:49PM +0000, Robin Murphy wrote:
[...]
> > [ 28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> >
> > Please confirm if this is expected or not? I think this might
> > introduce difficulty for John for the PMU event alias patches, which
> > is dependent on a non-zero IIDR.
>
> Yes, from previous discussions I believe the HiSilicon implementations don't
> have much meaningful ID information at all (hence why we have to match ACPI
> table headers to identify the counter erratum). My trick only works for Arm
> Ltd. implementations since they happen to have the IMP-DEF CoreSight
> registers with the same information as would be in the future IIDR.
>
> To clarify, the proposal at this point is to write up JSON files for
> MMU-600/MMU-700, based on this patch, in order to pipe-clean the process for
> future SMMUv3.3 PMCG implementations with real IIDRs.
>
> Whether other implementers might retroactively define "equivalent" IIDR
> values for their existing implementations in a way we could potentially
> quirk in the driver is an orthogonal question.
Agreed, it makes sense that supports the standard IP modules in
the mainline kernel at this stage.
Thanks for explanation.
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 13:59 ` Leo Yan
(?)
@ 2021-12-07 14:00 ` John Garry via iommu
-1 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 14:00 UTC (permalink / raw)
To: Leo Yan, Robin Murphy
Cc: Jean-Philippe Brucker, mark.rutland, devicetree, iommu,
uchida.jun, will, linux-arm-kernel, robh+dt
On 07/12/2021 13:59, Leo Yan wrote:
>> Whether other implementers might retroactively define "equivalent" IIDR
>> values for their existing implementations in a way we could potentially
>> quirk in the driver is an orthogonal question.
> Agreed, it makes sense that supports the standard IP modules in
> the mainline kernel at this stage.
>
> Thanks for explanation.
Leo, if you really want this to work on D06, I could also hack some
out-of-tree perf tool patches for you. I'm not sure if you're interested
in that. Let me know.
Thanks,
John
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 14:00 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry via iommu @ 2021-12-07 14:00 UTC (permalink / raw)
To: Leo Yan, Robin Murphy
Cc: mark.rutland, Jean-Philippe Brucker, devicetree, iommu, robh+dt,
uchida.jun, will, linux-arm-kernel
On 07/12/2021 13:59, Leo Yan wrote:
>> Whether other implementers might retroactively define "equivalent" IIDR
>> values for their existing implementations in a way we could potentially
>> quirk in the driver is an orthogonal question.
> Agreed, it makes sense that supports the standard IP modules in
> the mainline kernel at this stage.
>
> Thanks for explanation.
Leo, if you really want this to work on D06, I could also hack some
out-of-tree perf tool patches for you. I'm not sure if you're interested
in that. Let me know.
Thanks,
John
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 14:00 ` John Garry via iommu
0 siblings, 0 replies; 42+ messages in thread
From: John Garry @ 2021-12-07 14:00 UTC (permalink / raw)
To: Leo Yan, Robin Murphy
Cc: Jean-Philippe Brucker, mark.rutland, devicetree, iommu,
uchida.jun, will, linux-arm-kernel, robh+dt
On 07/12/2021 13:59, Leo Yan wrote:
>> Whether other implementers might retroactively define "equivalent" IIDR
>> values for their existing implementations in a way we could potentially
>> quirk in the driver is an orthogonal question.
> Agreed, it makes sense that supports the standard IP modules in
> the mainline kernel at this stage.
>
> Thanks for explanation.
Leo, if you really want this to work on D06, I could also hack some
out-of-tree perf tool patches for you. I'm not sure if you're interested
in that. Let me know.
Thanks,
John
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
2021-12-07 14:00 ` John Garry via iommu
(?)
@ 2021-12-07 14:04 ` Leo Yan
-1 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 14:04 UTC (permalink / raw)
To: John Garry
Cc: Robin Murphy, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 02:00:35PM +0000, John Garry wrote:
> On 07/12/2021 13:59, Leo Yan wrote:
> > > Whether other implementers might retroactively define "equivalent" IIDR
> > > values for their existing implementations in a way we could potentially
> > > quirk in the driver is an orthogonal question.
> > Agreed, it makes sense that supports the standard IP modules in
> > the mainline kernel at this stage.
> >
> > Thanks for explanation.
>
> Leo, if you really want this to work on D06, I could also hack some
> out-of-tree perf tool patches for you. I'm not sure if you're interested in
> that. Let me know.
No, please don't spend time on this. I just use D06 platform to
verify SMMUv3 relevant patches, but have no requirement for profiling
SMMUv3 on it. Anyway, thanks a lot!
Leo
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 14:04 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 14:04 UTC (permalink / raw)
To: John Garry
Cc: mark.rutland, Jean-Philippe Brucker, devicetree, will, iommu,
robh+dt, uchida.jun, Robin Murphy, linux-arm-kernel
On Tue, Dec 07, 2021 at 02:00:35PM +0000, John Garry wrote:
> On 07/12/2021 13:59, Leo Yan wrote:
> > > Whether other implementers might retroactively define "equivalent" IIDR
> > > values for their existing implementations in a way we could potentially
> > > quirk in the driver is an orthogonal question.
> > Agreed, it makes sense that supports the standard IP modules in
> > the mainline kernel at this stage.
> >
> > Thanks for explanation.
>
> Leo, if you really want this to work on D06, I could also hack some
> out-of-tree perf tool patches for you. I'm not sure if you're interested in
> that. Let me know.
No, please don't spend time on this. I just use D06 platform to
verify SMMUv3 relevant patches, but have no requirement for profiling
SMMUv3 on it. Anyway, thanks a lot!
Leo
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
@ 2021-12-07 14:04 ` Leo Yan
0 siblings, 0 replies; 42+ messages in thread
From: Leo Yan @ 2021-12-07 14:04 UTC (permalink / raw)
To: John Garry
Cc: Robin Murphy, Jean-Philippe Brucker, mark.rutland, devicetree,
iommu, uchida.jun, will, linux-arm-kernel, robh+dt
On Tue, Dec 07, 2021 at 02:00:35PM +0000, John Garry wrote:
> On 07/12/2021 13:59, Leo Yan wrote:
> > > Whether other implementers might retroactively define "equivalent" IIDR
> > > values for their existing implementations in a way we could potentially
> > > quirk in the driver is an orthogonal question.
> > Agreed, it makes sense that supports the standard IP modules in
> > the mainline kernel at this stage.
> >
> > Thanks for explanation.
>
> Leo, if you really want this to work on D06, I could also hack some
> out-of-tree perf tool patches for you. I'm not sure if you're interested in
> that. Let me know.
No, please don't spend time on this. I just use D06 platform to
verify SMMUv3 relevant patches, but have no requirement for profiling
SMMUv3 on it. Anyway, thanks a lot!
Leo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] perf/smmuv3: Support devicetree
2021-11-17 14:48 ` Jean-Philippe Brucker
(?)
@ 2021-12-14 14:04 ` Will Deacon
-1 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2021-12-14 14:04 UTC (permalink / raw)
To: robh+dt, Jean-Philippe Brucker
Cc: catalin.marinas, kernel-team, Will Deacon, uchida.jun, leo.yan,
joro, devicetree, jkchen, iommu, mark.rutland, robin.murphy,
linux-arm-kernel
On Wed, 17 Nov 2021 14:48:42 +0000, Jean-Philippe Brucker wrote:
> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
> multiple independent PMCGs, for example one for the Translation Control
> Unit (TCU) and one per Translation Buffer Unit (TBU).
>
> Since v1 [1]:
> * Fixed warnings in the binding doc
> * Removed hip08 support
> * Merged Robin's version. I took the liberty of splitting the driver
> patch into 2 and 3. One fix in patch 3, and whitespace changes (the
> driver uses spaces instead of tabs to align #define values, which I
> was going to fix but actually seems more common across the tree.)
>
> [...]
Applied to arm64 (for-next/perf-smmu), thanks!
[1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
https://git.kernel.org/arm64/c/2704e7594383
[2/3] perf/smmuv3: Add devicetree support
https://git.kernel.org/arm64/c/3f7be4356176
[3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
https://git.kernel.org/arm64/c/df457ca973fe
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] perf/smmuv3: Support devicetree
@ 2021-12-14 14:04 ` Will Deacon
0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2021-12-14 14:04 UTC (permalink / raw)
To: robh+dt, Jean-Philippe Brucker
Cc: mark.rutland, devicetree, Will Deacon, catalin.marinas,
robin.murphy, iommu, uchida.jun, leo.yan, kernel-team,
linux-arm-kernel
On Wed, 17 Nov 2021 14:48:42 +0000, Jean-Philippe Brucker wrote:
> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
> multiple independent PMCGs, for example one for the Translation Control
> Unit (TCU) and one per Translation Buffer Unit (TBU).
>
> Since v1 [1]:
> * Fixed warnings in the binding doc
> * Removed hip08 support
> * Merged Robin's version. I took the liberty of splitting the driver
> patch into 2 and 3. One fix in patch 3, and whitespace changes (the
> driver uses spaces instead of tabs to align #define values, which I
> was going to fix but actually seems more common across the tree.)
>
> [...]
Applied to arm64 (for-next/perf-smmu), thanks!
[1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
https://git.kernel.org/arm64/c/2704e7594383
[2/3] perf/smmuv3: Add devicetree support
https://git.kernel.org/arm64/c/3f7be4356176
[3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
https://git.kernel.org/arm64/c/df457ca973fe
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] perf/smmuv3: Support devicetree
@ 2021-12-14 14:04 ` Will Deacon
0 siblings, 0 replies; 42+ messages in thread
From: Will Deacon @ 2021-12-14 14:04 UTC (permalink / raw)
To: robh+dt, Jean-Philippe Brucker
Cc: catalin.marinas, kernel-team, Will Deacon, uchida.jun, leo.yan,
joro, devicetree, jkchen, iommu, mark.rutland, robin.murphy,
linux-arm-kernel
On Wed, 17 Nov 2021 14:48:42 +0000, Jean-Philippe Brucker wrote:
> Add devicetree binding for the SMMUv3 PMU, called Performance Monitoring
> Counter Group (PMCG) in the spec. Each SMMUv3 implementation can have
> multiple independent PMCGs, for example one for the Translation Control
> Unit (TCU) and one per Translation Buffer Unit (TBU).
>
> Since v1 [1]:
> * Fixed warnings in the binding doc
> * Removed hip08 support
> * Merged Robin's version. I took the liberty of splitting the driver
> patch into 2 and 3. One fix in patch 3, and whitespace changes (the
> driver uses spaces instead of tabs to align #define values, which I
> was going to fix but actually seems more common across the tree.)
>
> [...]
Applied to arm64 (for-next/perf-smmu), thanks!
[1/3] dt-bindings: Add Arm SMMUv3 PMCG binding
https://git.kernel.org/arm64/c/2704e7594383
[2/3] perf/smmuv3: Add devicetree support
https://git.kernel.org/arm64/c/3f7be4356176
[3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers
https://git.kernel.org/arm64/c/df457ca973fe
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2021-12-14 14:06 UTC | newest]
Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-17 14:48 [PATCH v2 0/3] perf/smmuv3: Support devicetree Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 1/3] dt-bindings: Add Arm SMMUv3 PMCG binding Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 2/3] perf/smmuv3: Add devicetree support Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` [PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-11-17 14:48 ` Jean-Philippe Brucker
2021-12-07 9:14 ` John Garry
2021-12-07 9:14 ` John Garry
2021-12-07 9:14 ` John Garry via iommu
2021-12-07 12:04 ` Robin Murphy
2021-12-07 12:04 ` Robin Murphy
2021-12-07 12:04 ` Robin Murphy
2021-12-07 12:28 ` John Garry
2021-12-07 12:28 ` John Garry
2021-12-07 12:28 ` John Garry via iommu
2021-12-07 12:48 ` Robin Murphy
2021-12-07 12:48 ` Robin Murphy
2021-12-07 12:48 ` Robin Murphy
2021-12-07 13:20 ` Leo Yan
2021-12-07 13:20 ` Leo Yan
2021-12-07 13:20 ` Leo Yan
2021-12-07 13:46 ` Robin Murphy
2021-12-07 13:46 ` Robin Murphy
2021-12-07 13:46 ` Robin Murphy
2021-12-07 13:59 ` Leo Yan
2021-12-07 13:59 ` Leo Yan
2021-12-07 13:59 ` Leo Yan
2021-12-07 14:00 ` John Garry
2021-12-07 14:00 ` John Garry
2021-12-07 14:00 ` John Garry via iommu
2021-12-07 14:04 ` Leo Yan
2021-12-07 14:04 ` Leo Yan
2021-12-07 14:04 ` Leo Yan
2021-12-14 14:04 ` [PATCH v2 0/3] perf/smmuv3: Support devicetree Will Deacon
2021-12-14 14:04 ` Will Deacon
2021-12-14 14:04 ` Will Deacon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.