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).
I previously sent the binding as reply to Jay Chen's thread implementing
device tree support [1]. This posting addresses the comments from that
thread.
Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
as IORT for that implementation (see patch 2). We'll probably want to
also introduce compatible strings for each implementation that has
additional perf events. For example the MMU-600 implementation has
different events for TCU and TBU PMCGs [2], but both components have the
same device IDs. So the driver could differentiate them if they had two
distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
"arm,mmu-600-pmcg-tcu".
The series doesn't deal with this because for testing I use a software
model which only implements architected events. I do not include DTS
change for that platform because enabling PMCGs requires an additional
model option. See my branch smmu/pmu-dt [3] for details.
[1] https://lore.kernel.org/all/20200707150114.GC159413@myrica/
[2] https://developer.arm.com/documentation/100310/0202/Functional-description/Operation/Performance-Monitoring-Unit
[3] https://jpbrucker.net/git/linux/log/?h=smmu/pmu-dt
Jean-Philippe Brucker (2):
dt-bindings: Add Arm SMMUv3 PMCG binding
perf/smmuv3: Add devicetree support
.../bindings/iommu/arm,smmu-v3-pmcg.yaml | 67 +++++++++++++++++++
drivers/perf/arm_smmuv3_pmu.c | 25 ++++++-
2 files changed, 90 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
--
2.33.1
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 <redacted>
---
.../bindings/iommu/arm,smmu-v3-pmcg.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
@@ -0,0 +1,67 @@+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/iommu/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:+-enum:+-hisilicon,smmu-v3-pmcg-hip08+-const:arm,smmu-v3-pmcg+-const:arm,smmu-v3-pmcg++reg:+description:|+Base addresses of the PMCG registers. Either a single address for Page 0+or an additional address for Page 1, where some registers can be+relocated with SMMU_PMCG_CFGR.RELOC_CTRS.+minItems:1+maxItems:2++interrupts:+maxItems:1++msi-parent:true++required:+-compatible+-reg++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 = <0 0x2b420000 0 0x1000>,+<0 0x2b430000 0 0x1000>;+interrupts = <GIC_SPI 80 IRQ_TYPE_EDGE_RISING>;+msi-parent = <&its 0xff0000>;+};++pmu@2b440000 {+compatible = "arm,smmu-v3-pmcg";+reg = <0 0x2b440000 0 0x1000>,+<0 0x2b450000 0 0x1000>;+interrupts = <GIC_SPI 81 IRQ_TYPE_EDGE_RISING>;+msi-parent = <&its 0xff0000>;+};
From: Rob Herring <robh@kernel.org> Date: 2021-11-16 14:03:17
On Tue, 16 Nov 2021 11:35:36 +0000, Jean-Philippe Brucker wrote:
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 <redacted>
---
.../bindings/iommu/arm,smmu-v3-pmcg.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:24:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:25:11: [warning] wrong indentation: expected 12 but found 10 (indentation)
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b420000:reg:0: [0, 725745664, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b420000:reg:1: [0, 725811200, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b440000:reg:0: [0, 725876736, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b440000:reg:1: [0, 725942272, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1555758
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
On Tue, Nov 16, 2021 at 08:02:53AM -0600, Rob Herring wrote:
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:24:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
./Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml:25:11: [warning] wrong indentation: expected 12 but found 10 (indentation)
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b420000:reg:0: [0, 725745664, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b420000:reg:1: [0, 725811200, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b440000:reg:0: [0, 725876736, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.example.dt.yaml: example-0: pmu@2b440000:reg:1: [0, 725942272, 0, 4096] is too long
From schema: /usr/local/lib/python3.8/dist-packages/dtschema/schemas/reg.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1555758
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Right I'll fix those, I had only run dtbs_check
Thanks,
Jean
From: Rob Herring <robh+dt@kernel.org> Date: 2021-11-17 23:20:10
On Tue, Nov 16, 2021 at 5:52 AM Jean-Philippe Brucker
[off-list ref] wrote:
quoted hunk
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 <redacted>
---
.../bindings/iommu/arm,smmu-v3-pmcg.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
+ 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.
Humm, I don't know that I agree they are standalone. They could be I
guess, but looking at the MMU-600 spec the PMCG looks like it's just a
subset of registers in a larger block. This seems similar to MPAM
(which I'm working on a binding for) where it's just a register map
and interrupts, but every other possible resource is unspecified by
the architecture.
The simplest change from this would be just specifying that the PMCG
is child node(s) of whatever it is part of. The extreme would be this
is all part of the SMMU binding (i.e. reg entry X is PMCG registers,
interrupts entry Y is pmu irq).
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-11-18 15:51:03
On 2021-11-17 23:19, Rob Herring wrote:
On Tue, Nov 16, 2021 at 5:52 AM Jean-Philippe Brucker
[off-list ref] wrote:
quoted
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 <redacted>
---
.../bindings/iommu/arm,smmu-v3-pmcg.yaml | 67 +++++++++++++++++++
1 file changed, 67 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu-v3-pmcg.yaml
+ 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.
Humm, I don't know that I agree they are standalone. They could be I
guess, but looking at the MMU-600 spec the PMCG looks like it's just a
subset of registers in a larger block. This seems similar to MPAM
(which I'm working on a binding for) where it's just a register map
and interrupts, but every other possible resource is unspecified by
the architecture.
They're "standalone" in the sense that they don't have to be part of an
SMMU, they could be part of a PCIe root complex or other SoC device that
couples to an SMMU (e.g. anything that can speak AMBA DTI, in the case
of our SMMU implementations).
In fact our SMMU TBUs are pretty much separate devices themselves, they
just *only* speak DTI, so access to their registers is proxied through
the TCU programming interface.
The simplest change from this would be just specifying that the PMCG
is child node(s) of whatever it is part of. The extreme would be this
is all part of the SMMU binding (i.e. reg entry X is PMCG registers,
interrupts entry Y is pmu irq).
Being a child of its associated device doesn't seem too bad
semantically, however how would we describe a PMCG as a child of a PCIe
node when its "reg" property still exists in the parent address space
and not PCI config/memory space like any of its siblings? Also in
practical terms, consuming that binding in Linux and getting the things
to probe when it may want to be independent of whether we even
understand the parent node at all could be... unpleasant.
Robin.
On Thu, Nov 18, 2021 at 03:50:54PM +0000, Robin Murphy wrote:
quoted
quoted
+ 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.
Humm, I don't know that I agree they are standalone. They could be I
guess, but looking at the MMU-600 spec the PMCG looks like it's just a
subset of registers in a larger block. This seems similar to MPAM
(which I'm working on a binding for) where it's just a register map
and interrupts, but every other possible resource is unspecified by
the architecture.
They're "standalone" in the sense that they don't have to be part of an
SMMU, they could be part of a PCIe root complex or other SoC device that
couples to an SMMU (e.g. anything that can speak AMBA DTI, in the case of
our SMMU implementations).
The "standalone" word came from the SMMUv3 spec (IHI0070D.b 10.1):
The Performance Monitor Counter Groups are standalone monitoring
facilities and, as such, can be implemented in separate components that
are all associated with (but not necessarily part of) an SMMU.
In fact our SMMU TBUs are pretty much separate devices themselves, they just
*only* speak DTI, so access to their registers is proxied through the TCU
programming interface.
quoted
The simplest change from this would be just specifying that the PMCG
is child node(s) of whatever it is part of. The extreme would be this
is all part of the SMMU binding (i.e. reg entry X is PMCG registers,
interrupts entry Y is pmu irq).
Being a child of its associated device doesn't seem too bad semantically,
however how would we describe a PMCG as a child of a PCIe node when its
"reg" property still exists in the parent address space and not PCI
config/memory space like any of its siblings? Also in practical terms,
consuming that binding in Linux and getting the things to probe when it may
want to be independent of whether we even understand the parent node at all
could be... unpleasant.
So there are multiple options for what "the PMCG is part of".
(a) The SMMU: the spec guarantees that a PMCG is associated with an SMMU.
(b) The MMIO region: may be within the SMMU (as with MMU-600), outside of
it (as does another implementation, two 64k pages after the SMMU base)
or, theoretically, within a separate device (e.g. PCIe controller).
(c) The thing being measured: does not necessarily match the MMIO region.
For example a TBU attached to the PCIe RC but the PMCG MMIO is within
the SMMU region.
(d) None: the PMCG can be probed and driven separately from the SMMU and
other components, as demonstrated by Linux.
Which one is normally picked to decide where to insert a devicetree node?
I guess (b)? I picked (d) so far as the easiest choice.
(a) is also a reasonable choice, being based on the spec, but it might be
confusing to have a PMCG node inside the SMMU node when the MMIO region is
external, possibly belonging to another device. For the same reason we
could discard (c).
(b) feels more natural, although it's not clear what to do when the PMCG
MMIO region is external or adjacent to the SMMU region. Does the node go
inside the SMMU node or one level up?
Thanks,
Jean
Add device-tree support to the SMMUv3 PMCG. One small cosmetic change
while factoring the option mask printout: don't display it when zero, it
only contains one erratum at the moment.
Signed-off-by: Jay Chen <redacted>
Signed-off-by: Jean-Philippe Brucker <redacted>
---
drivers/perf/arm_smmuv3_pmu.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
@@ -834,7 +842,13 @@ 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_of_options(smmu_pmu);+else+smmu_pmu_get_acpi_options(smmu_pmu);++if(smmu_pmu->options)+dev_notice(dev,"option mask 0x%x\n",smmu_pmu->options);/* Pick one CPU to be the preferred one to use */smmu_pmu->on_cpu=raw_smp_processor_id();
From: John Garry <hidden> Date: 2021-11-16 12:08:12
On 16/11/2021 11:35, Jean-Philippe Brucker wrote:
quoted hunk
Add device-tree support to the SMMUv3 PMCG. One small cosmetic change
while factoring the option mask printout: don't display it when zero, it
only contains one erratum at the moment.
Signed-off-by: Jay Chen <redacted>
Signed-off-by: Jean-Philippe Brucker <redacted>
---
drivers/perf/arm_smmuv3_pmu.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
I don't think that this is necessary. We don't support DT for hip08, nor
have any plans to. Incidentally, was this binding missing in your series?
Thanks,
John
@@ -834,7 +842,13 @@ 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_of_options(smmu_pmu);+ else+ smmu_pmu_get_acpi_options(smmu_pmu);++ if (smmu_pmu->options)+ dev_notice(dev, "option mask 0x%x\n", smmu_pmu->options); /* Pick one CPU to be the preferred one to use */ smmu_pmu->on_cpu = raw_smp_processor_id();
On Tue, Nov 16, 2021 at 12:06:36PM +0000, John Garry wrote:
On 16/11/2021 11:35, Jean-Philippe Brucker wrote:
quoted
Add device-tree support to the SMMUv3 PMCG. One small cosmetic change
while factoring the option mask printout: don't display it when zero, it
only contains one erratum at the moment.
Signed-off-by: Jay Chen <redacted>
Signed-off-by: Jean-Philippe Brucker <redacted>
---
drivers/perf/arm_smmuv3_pmu.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-11-16 12:05:13
On 2021-11-16 11:35, 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).
I previously sent the binding as reply to Jay Chen's thread implementing
device tree support [1]. This posting addresses the comments from that
thread.
Ha, I'd also resurrected this and was planning to post it at some point
this week[0] - you should have said :)
Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
as IORT for that implementation (see patch 2). We'll probably want to
also introduce compatible strings for each implementation that has
additional perf events. For example the MMU-600 implementation has
different events for TCU and TBU PMCGs [2], but both components have the
same device IDs. So the driver could differentiate them if they had two
distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
"arm,mmu-600-pmcg-tcu".
Actually it only needs a general MMU-600 compatible, since once you know
it's an Arm Ltd. implementation, you can assume the pattern for the
IMP_DEF ID registers to figure out the rest.
Robin.
[0] https://gitlab.arm.com/linux-arm/linux-rm/-/commits/smmu-pmcg
On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
quoted
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).
I previously sent the binding as reply to Jay Chen's thread implementing
device tree support [1]. This posting addresses the comments from that
thread.
Ha, I'd also resurrected this and was planning to post it at some point this
week[0] - you should have said :)
Ah sorry about that, I just resent because there was some demand for it at
Linaro
quoted
Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
as IORT for that implementation (see patch 2). We'll probably want to
also introduce compatible strings for each implementation that has
additional perf events. For example the MMU-600 implementation has
different events for TCU and TBU PMCGs [2], but both components have the
same device IDs. So the driver could differentiate them if they had two
distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
"arm,mmu-600-pmcg-tcu".
Actually it only needs a general MMU-600 compatible, since once you know
it's an Arm Ltd. implementation, you can assume the pattern for the IMP_DEF
ID registers to figure out the rest.
It might be an error in the MMU-600 spec specifically, both TBU and TCU
PMU registers have a 0x83 PIDR0, where I think the TBU should be 0x84 (the
revC model uses that value). It's possible that the implementation
actually has 0x84 instead.
Thanks,
Jean
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-11-16 17:00:23
On 2021-11-16 15:42, Jean-Philippe Brucker wrote:
On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
quoted
On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
quoted
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).
I previously sent the binding as reply to Jay Chen's thread implementing
device tree support [1]. This posting addresses the comments from that
thread.
Ha, I'd also resurrected this and was planning to post it at some point this
week[0] - you should have said :)
Ah sorry about that, I just resent because there was some demand for it at
Linaro
Heh, no worries - it's not like you were even CC'ed on the thread where
I only mentioned I *might* do it.
Can I get away with being cheeky and just saying that my review comments
are the diff between my branch and yours, I wonder...
quoted
quoted
Patch 1 adds two compatible strings. "arm,smmu-v3-pmcg" is common to all
PMCGs. "hisilicon,smmu-v3-pmcg-hip08" allows to support the same quirk
as IORT for that implementation (see patch 2). We'll probably want to
also introduce compatible strings for each implementation that has
additional perf events. For example the MMU-600 implementation has
different events for TCU and TBU PMCGs [2], but both components have the
same device IDs. So the driver could differentiate them if they had two
distinct compatible strings such as "arm,mmu-600-pmcg-tbu" and
"arm,mmu-600-pmcg-tcu".
Actually it only needs a general MMU-600 compatible, since once you know
it's an Arm Ltd. implementation, you can assume the pattern for the IMP_DEF
ID registers to figure out the rest.
It might be an error in the MMU-600 spec specifically, both TBU and TCU
PMU registers have a 0x83 PIDR0, where I think the TBU should be 0x84 (the
revC model uses that value). It's possible that the implementation
actually has 0x84 instead.
Yup, it's a mistake in the TRM. I just checked a real MMU-600 and the
PMU PIDRs match the main TCU/TBU PIDRs as expected. At least the MMU-700
docs haven't repeated the same error.
Cheers,
Robin.
On Tue, Nov 16, 2021 at 05:00:14PM +0000, Robin Murphy wrote:
On 2021-11-16 15:42, Jean-Philippe Brucker wrote:
quoted
On Tue, Nov 16, 2021 at 12:02:47PM +0000, Robin Murphy wrote:
quoted
On 2021-11-16 11:35, Jean-Philippe Brucker wrote:
quoted
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).
I previously sent the binding as reply to Jay Chen's thread implementing
device tree support [1]. This posting addresses the comments from that
thread.
Ha, I'd also resurrected this and was planning to post it at some point this
week[0] - you should have said :)
Ah sorry about that, I just resent because there was some demand for it at
Linaro
Heh, no worries - it's not like you were even CC'ed on the thread where I
only mentioned I *might* do it.
Can I get away with being cheeky and just saying that my review comments are
the diff between my branch and yours, I wonder...
Sure, that works for me, I'll send a v2 this week or so
Thanks,
Jean