This patch series adds proper support for describing and probing the
Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
the SMMU in Devicetree, and updates the relevant drivers accordingly.

The SMMU v3 architecture allows an optional PMCG block, typically
associated with TCUs, to be implemented within the SMMU register
address space. For example, mmu700 PMCG is at the offset 0x2000 of the
TCU page 0.

Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
referencing the existing arm,smmu-v3-pmcg binding.

Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
child nodes described in DT once the SMMU probe succeeds.

Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
PMCG is described as a child node. The PMCG registers occupy a sub-region
of the parent SMMU MMIO window, which is already requested by the SMMU

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Peng Fan (3):
      dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
      iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
      perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG

 .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
 drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
 3 files changed, 29 insertions(+), 3 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-smmu-perf-754367fe66c8

Best regards,
-- 
Peng Fan <peng.fan@nxp.com>

On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
> This patch series adds proper support for describing and probing the
> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
> the SMMU in Devicetree, and updates the relevant drivers accordingly.
> 
> The SMMU v3 architecture allows an optional PMCG block, typically
> associated with TCUs, to be implemented within the SMMU register
> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
> TCU page 0.

But what's wrong with the existing binding? Especially given that it 
even has an upstream user already:

https://git.kernel.org/torvalds/c/aef9703dcbf8

> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
> referencing the existing arm,smmu-v3-pmcg binding.
> 
> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
> child nodes described in DT once the SMMU probe succeeds.
> 
> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
> PMCG is described as a child node. The PMCG registers occupy a sub-region
> of the parent SMMU MMIO window, which is already requested by the SMMU

That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't 
reserve implementation defined register space") nearly 6 years ago, 
where the whole purpose was to support Arm's PMCG implementation 
properly. What kernel is this based on?

Thanks,
Robin.

> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (3):
>        dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>        iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>        perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
> 
>   .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
>   drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
>   3 files changed, 29 insertions(+), 3 deletions(-)
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-smmu-perf-754367fe66c8
> 
> Best regards,

On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> This patch series adds proper support for describing and probing the
>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>> 
>> The SMMU v3 architecture allows an optional PMCG block, typically
>> associated with TCUs, to be implemented within the SMMU register
>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> TCU page 0.
>
>But what's wrong with the existing binding? Especially given that it even has
>an upstream user already:
>
>https://git.kernel.org/torvalds/c/aef9703dcbf8
>
>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> referencing the existing arm,smmu-v3-pmcg binding.
>> 
>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> child nodes described in DT once the SMMU probe succeeds.
>> 
>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>> of the parent SMMU MMIO window, which is already requested by the SMMU
>
>That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>reserve implementation defined register space") nearly 6 years ago, where the
>whole purpose was to support Arm's PMCG implementation properly. What kernel
>is this based on?

Seems I am wrong. I thought PMCG is in page 0, so there were resource
conflicts. I just retest without this patchset, all goes well.

But from dt perspective, should the TCU PMCG node be child node of
SMMU node?

Thanks,
Peng

>
>Thanks,
>Robin.
>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Peng Fan (3):
>>        dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
>>        iommu/arm-smmu-v3: Populate PMU child devices from Devicetree
>>        perf/arm-smmuv3: Avoid double-requesting shared SMMU MMIO for PMCG
>> 
>>   .../devicetree/bindings/iommu/arm,smmu-v3.yaml        | 10 ++++++++++
>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c           |  3 +++
>>   drivers/perf/arm_smmuv3_pmu.c                         | 19 ++++++++++++++++---
>>   3 files changed, 29 insertions(+), 3 deletions(-)
>> ---
>> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
>> change-id: 20260408-smmu-perf-754367fe66c8
>> 
>> Best regards,
>
>

On 08/04/2026 2:47 pm, Peng Fan wrote:
> On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>> On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>>> This patch series adds proper support for describing and probing the
>>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>>>
>>> The SMMU v3 architecture allows an optional PMCG block, typically
>>> associated with TCUs, to be implemented within the SMMU register
>>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>>> TCU page 0.
>>
>> But what's wrong with the existing binding? Especially given that it even has
>> an upstream user already:
>>
>> https://git.kernel.org/torvalds/c/aef9703dcbf8
>>
>>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>>> referencing the existing arm,smmu-v3-pmcg binding.
>>>
>>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>>> child nodes described in DT once the SMMU probe succeeds.
>>>
>>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>>> of the parent SMMU MMIO window, which is already requested by the SMMU
>>
>> That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>> reserve implementation defined register space") nearly 6 years ago, where the
>> whole purpose was to support Arm's PMCG implementation properly. What kernel
>> is this based on?
> 
> Seems I am wrong. I thought PMCG is in page 0, so there were resource
> conflicts. I just retest without this patchset, all goes well.
> 
> But from dt perspective, should the TCU PMCG node be child node of
> SMMU node?

No. PMCGs can be used entirely independently of the SMMU itself, and 
while most of the events do relate to SMMU translation and thus aren't 
necessarily meaningful if it's not in use, there are still some which 
can be useful for basic traffic counting, monitoring GPT/translation 
activity from _other_ security states (if observation is delegated to 
Non-Secure) and possibly other things, even if the "main" Non-Secure 
SMMU interface isn't advertised at all. It would be unreasonable to 
require the SMMU node to be present and enabled *and* have a driver to 
populate PMCGs, to monitor events which are outside the scope of that 
driver.

Thanks,
Robin.

Hi Robin,

On Fri, Apr 10, 2026 at 01:07:29PM +0100, Robin Murphy wrote:
>On 08/04/2026 2:47 pm, Peng Fan wrote:
>> On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>> > On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>> > > This patch series adds proper support for describing and probing the
>> > > Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>> > > the SMMU in Devicetree, and updates the relevant drivers accordingly.
>> > > 
>> > > The SMMU v3 architecture allows an optional PMCG block, typically
>> > > associated with TCUs, to be implemented within the SMMU register
>> > > address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>> > > TCU page 0.
>> > 
>> > But what's wrong with the existing binding? Especially given that it even has
>> > an upstream user already:
>> > 
>> > https://git.kernel.org/torvalds/c/aef9703dcbf8
>> > 
>> > > Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>> > > referencing the existing arm,smmu-v3-pmcg binding.
>> > > 
>> > > Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>> > > child nodes described in DT once the SMMU probe succeeds.
>> > > 
>> > > Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>> > > PMCG is described as a child node. The PMCG registers occupy a sub-region
>> > > of the parent SMMU MMIO window, which is already requested by the SMMU
>> > 
>> > That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>> > reserve implementation defined register space") nearly 6 years ago, where the
>> > whole purpose was to support Arm's PMCG implementation properly. What kernel
>> > is this based on?
>> 
>> Seems I am wrong. I thought PMCG is in page 0, so there were resource
>> conflicts. I just retest without this patchset, all goes well.
>> 
>> But from dt perspective, should the TCU PMCG node be child node of
>> SMMU node?
>
>No. PMCGs can be used entirely independently of the SMMU itself, and while
>most of the events do relate to SMMU translation and thus aren't necessarily
>meaningful if it's not in use, there are still some which can be useful for
>basic traffic counting, monitoring GPT/translation activity from _other_
>security states (if observation is delegated to Non-Secure) and possibly
>other things, even if the "main" Non-Secure SMMU interface isn't advertised
>at all. It would be unreasonable to require the SMMU node to be present and
>enabled *and* have a driver to populate PMCGs, to monitor events which are
>outside the scope of that driver.

Thanks for explaining this in detail.

Just have one more question, we are using mmu-700, but MMU-700 implementation
defined TCU and TBU events are not supported.

Should we introduce a compatible string saying "arm,mmu700-tcu-pmcg" or
"arm,mmu700-tbu-pmcg"? TBH, I have not checked MMU600(AE) or else.

Thanks,
Peng

>
>Thanks,
>Robin.
>

On 2026-04-14 8:47 am, Peng Fan wrote:
> Hi Robin,
> 
> On Fri, Apr 10, 2026 at 01:07:29PM +0100, Robin Murphy wrote:
>> On 08/04/2026 2:47 pm, Peng Fan wrote:
>>> On Wed, Apr 08, 2026 at 12:15:31PM +0100, Robin Murphy wrote:
>>>> On 2026-04-08 8:51 am, Peng Fan (OSS) wrote:
>>>>> This patch series adds proper support for describing and probing the
>>>>> Arm SMMU v3 PMCG (Performance Monitor Control Group) as a child node of
>>>>> the SMMU in Devicetree, and updates the relevant drivers accordingly.
>>>>>
>>>>> The SMMU v3 architecture allows an optional PMCG block, typically
>>>>> associated with TCUs, to be implemented within the SMMU register
>>>>> address space. For example, mmu700 PMCG is at the offset 0x2000 of the
>>>>> TCU page 0.
>>>>
>>>> But what's wrong with the existing binding? Especially given that it even has
>>>> an upstream user already:
>>>>
>>>> https://git.kernel.org/torvalds/c/aef9703dcbf8
>>>>
>>>>> Patch 1 updates the SMMU v3 Devicetree binding to allow PMCG child nodes,
>>>>> referencing the existing arm,smmu-v3-pmcg binding.
>>>>>
>>>>> Patch 2 updates the arm-smmu-v3 driver to populate platform devices for
>>>>> child nodes described in DT once the SMMU probe succeeds.
>>>>>
>>>>> Patch 3 updates the SMMUv3 PMU driver to correctly handle MMIO mapping when
>>>>> PMCG is described as a child node. The PMCG registers occupy a sub-region
>>>>> of the parent SMMU MMIO window, which is already requested by the SMMU
>>>>
>>>> That has not been the case since 52f3fab0067d ("iommu/arm-smmu-v3: Don't
>>>> reserve implementation defined register space") nearly 6 years ago, where the
>>>> whole purpose was to support Arm's PMCG implementation properly. What kernel
>>>> is this based on?
>>>
>>> Seems I am wrong. I thought PMCG is in page 0, so there were resource
>>> conflicts. I just retest without this patchset, all goes well.
>>>
>>> But from dt perspective, should the TCU PMCG node be child node of
>>> SMMU node?
>>
>> No. PMCGs can be used entirely independently of the SMMU itself, and while
>> most of the events do relate to SMMU translation and thus aren't necessarily
>> meaningful if it's not in use, there are still some which can be useful for
>> basic traffic counting, monitoring GPT/translation activity from _other_
>> security states (if observation is delegated to Non-Secure) and possibly
>> other things, even if the "main" Non-Secure SMMU interface isn't advertised
>> at all. It would be unreasonable to require the SMMU node to be present and
>> enabled *and* have a driver to populate PMCGs, to monitor events which are
>> outside the scope of that driver.
> 
> Thanks for explaining this in detail.
> 
> Just have one more question, we are using mmu-700, but MMU-700 implementation
> defined TCU and TBU events are not supported.
> 
> Should we introduce a compatible string saying "arm,mmu700-tcu-pmcg" or
> "arm,mmu700-tbu-pmcg"? TBH, I have not checked MMU600(AE) or else.

MMU-700 and all other Arm implementations are still fully compatible 
with "arm,mmu-600-pmcg" in terms of what that means. That lets the 
driver correctly construct the "identifier" attribute, which then allows 
userspace to know what exact PMU implementation it is.

We don't maintain ever-growing lists of aliases for imp-def events in 
the kernel driver, same as we don't for CPU PMUs either. Generally, 
anyone who has reason to go near those is likely to already have the TRM 
to hand and thus have the encodings anyway, but I suppose you could add 
jevents with the proper meaningful descriptions if you really wanted to.

Thanks,
Robin.