diff mbox

[2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Message ID 1459467472-31561-3-git-send-email-ttnguyen@apm.com (mailing list archive)
State New, archived
Headers show

Commit Message

Tai Nguyen March 31, 2016, 11:37 p.m. UTC
Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Signed-off-by: Tai Nguyen <ttnguyen@apm.com>
---
 .../devicetree/bindings/perf/apm-xgene-pmu.txt     | 116 +++++++++++++++++++++
 1 file changed, 116 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt

Comments

Mark Rutland April 1, 2016, 12:30 p.m. UTC | #1
Hi,

As per Documentation/devicetree/bindings/submitting-patches.txt, please
put binding patches earlier in a series than the code using them.

On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
> Documentation: Add documentation for APM X-Gene SoC PMU DTS binding
> 
> Signed-off-by: Tai Nguyen <ttnguyen@apm.com>
> ---
>  .../devicetree/bindings/perf/apm-xgene-pmu.txt     | 116 +++++++++++++++++++++
>  1 file changed, 116 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
> 
> diff --git a/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
> new file mode 100644
> index 0000000..40dfd4e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
> @@ -0,0 +1,116 @@
> +* APM X-Gene SoC PMU bindings
> +
> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
> +The following PMU devices are supported:
> +
> +  L3C			- L3 cache controller
> +  IOB			- IO bridge
> +  MCB			- Memory controller bridge
> +  MC			- Memory controller

These sound like separate units. How do these relate?

Is there an SOC-wide PMU that aggregates counters, or are these actually
independent?

> +
> +The following section describes the SoC PMU DT node binding.
> +
> +Required properties:
> +- compatible		: Shall be "apm,xgene-pmu" for revision 1 or
> +                          "apm,xgene-pmu-v2" for revision 2.

That name is very general. Is there not a more specific name for the SOC
PMU?

> +Required properties for L3C subnode:
> +- compatible		: Shall be "apm,xgene-pmu-l3c".
> +- reg			: First resource shall be the L3C PMU resource.
> +- index			: Instance number of the L3C PMU.
> +
> +Required properties for IOB subnode:
> +- compatible		: Shall be "apm,xgene-pmu-iob".
> +- reg			: First resource shall be the IOB PMU resource.
> +- index			: Instance number of the IOB PMU.
> +
> +Required properties for MCB subnode:
> +- compatible		: Shall be "apm,xgene-pmu-mcb".
> +- reg			: First resource shall be the MCB PMU resource.
> +- index			: Instance number of the MCB PMU.
> +
> +Required properties for MC subnode:
> +- compatible		: Shall be "apm,xgene-pmu-mc".
> +- reg			: First resource shall be the MC PMU resource.
> +- index			: Instance number of the MC PMU.

What's the index property useful for?

Thanks,
Mark.
Mark Rutland April 1, 2016, 12:32 p.m. UTC | #2
On Fri, Apr 01, 2016 at 01:30:01PM +0100, Mark Rutland wrote:
> Hi,
> 
> As per Documentation/devicetree/bindings/submitting-patches.txt, please
> put binding patches earlier in a series than the code using them.

Whoops, this patch was in the right place; I'm just reading my mail
wrong. Please ignore this.

Thanks,
Mark.
Mark Rutland April 4, 2016, 11:38 p.m. UTC | #3
On Mon, Apr 04, 2016 at 04:40:33PM -0700, Tai Tri Nguyen wrote:
> On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
> >> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
> >> +The following PMU devices are supported:
> >> +
> >> +  L3C                        - L3 cache controller
> >> +  IOB                        - IO bridge
> >> +  MCB                        - Memory controller bridge
> >> +  MC                 - Memory controller
> >
> > These sound like separate units. How do these relate?
> >
> > Is there an SOC-wide PMU that aggregates counters, or are these actually
> > independent?
> >
> 
> Yes, they are independent, but sharing the same top level status interrupt.
> There's no SOC-wide PMU which aggregates these counters.

If they're just sharing the interrupt, why are they not separate nodes (and
drivers) which simply happen to share an interrupt?

Is there anything else shared?

> >> +The following section describes the SoC PMU DT node binding.
> >> +
> >> +Required properties:
> >> +- compatible         : Shall be "apm,xgene-pmu" for revision 1 or
> >> +                          "apm,xgene-pmu-v2" for revision 2.
> >
> > That name is very general. Is there not a more specific name for the SOC
> > PMU?
> >
> 
> Beside the ARMv8 core PMU which has the compatible name "arm,armv8-pmuv3",
> these are all the PMUs in X-Gene SoCs. Also, we are using the same PMU
> driver across our platforms. I think a general name is what it should be.

Depending on my prior question, I'm not sure that's necessarily true. If
there's no actual shared SoC PMU logic as such, the names below for each
individual PMU seem fine.
 
> >> +Required properties for L3C subnode:
> >> +- compatible         : Shall be "apm,xgene-pmu-l3c".
> >> +- reg                        : First resource shall be the L3C PMU resource.
> >> +- index                      : Instance number of the L3C PMU.
> >> +
> >> +Required properties for IOB subnode:
> >> +- compatible         : Shall be "apm,xgene-pmu-iob".
> >> +- reg                        : First resource shall be the IOB PMU resource.
> >> +- index                      : Instance number of the IOB PMU.
> >> +
> >> +Required properties for MCB subnode:
> >> +- compatible         : Shall be "apm,xgene-pmu-mcb".
> >> +- reg                        : First resource shall be the MCB PMU resource.
> >> +- index                      : Instance number of the MCB PMU.
> >> +
> >> +Required properties for MC subnode:
> >> +- compatible         : Shall be "apm,xgene-pmu-mc".
> >> +- reg                        : First resource shall be the MC PMU resource.
> >> +- index                      : Instance number of the MC PMU.
> >
> > What's the index property useful for?
> >
> 
> The index property is used for indicating the physical hardware PMU id.
> For example, on X-Gene1 there are 4 memory controllers (MC), each of them has
> its own PMU. The index property tells us which MC a PMU belongs to.
> The same for MCB/L3C and IOB.

Sure, but is this simply informative for the user, or does this have an impact
on the programming model?

Thanks,
Mark.
Tai Nguyen April 4, 2016, 11:40 p.m. UTC | #4
Hi Mark,

On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> As per Documentation/devicetree/bindings/submitting-patches.txt, please
> put binding patches earlier in a series than the code using them.
>
> On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
>> Documentation: Add documentation for APM X-Gene SoC PMU DTS binding
>>
>> Signed-off-by: Tai Nguyen <ttnguyen@apm.com>
>> ---
>>  .../devicetree/bindings/perf/apm-xgene-pmu.txt     | 116 +++++++++++++++++++++
>>  1 file changed, 116 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
>> new file mode 100644
>> index 0000000..40dfd4e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
>> @@ -0,0 +1,116 @@
>> +* APM X-Gene SoC PMU bindings
>> +
>> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
>> +The following PMU devices are supported:
>> +
>> +  L3C                        - L3 cache controller
>> +  IOB                        - IO bridge
>> +  MCB                        - Memory controller bridge
>> +  MC                 - Memory controller
>
> These sound like separate units. How do these relate?
>
> Is there an SOC-wide PMU that aggregates counters, or are these actually
> independent?
>

Yes, they are independent, but sharing the same top level status interrupt.
There's no SOC-wide PMU which aggregates these counters.

>> +
>> +The following section describes the SoC PMU DT node binding.
>> +
>> +Required properties:
>> +- compatible         : Shall be "apm,xgene-pmu" for revision 1 or
>> +                          "apm,xgene-pmu-v2" for revision 2.
>
> That name is very general. Is there not a more specific name for the SOC
> PMU?
>

Beside the ARMv8 core PMU which has the compatible name "arm,armv8-pmuv3",
these are all the PMUs in X-Gene SoCs. Also, we are using the same PMU
driver across our platforms. I think a general name is what it should be.

>> +Required properties for L3C subnode:
>> +- compatible         : Shall be "apm,xgene-pmu-l3c".
>> +- reg                        : First resource shall be the L3C PMU resource.
>> +- index                      : Instance number of the L3C PMU.
>> +
>> +Required properties for IOB subnode:
>> +- compatible         : Shall be "apm,xgene-pmu-iob".
>> +- reg                        : First resource shall be the IOB PMU resource.
>> +- index                      : Instance number of the IOB PMU.
>> +
>> +Required properties for MCB subnode:
>> +- compatible         : Shall be "apm,xgene-pmu-mcb".
>> +- reg                        : First resource shall be the MCB PMU resource.
>> +- index                      : Instance number of the MCB PMU.
>> +
>> +Required properties for MC subnode:
>> +- compatible         : Shall be "apm,xgene-pmu-mc".
>> +- reg                        : First resource shall be the MC PMU resource.
>> +- index                      : Instance number of the MC PMU.
>
> What's the index property useful for?
>

The index property is used for indicating the physical hardware PMU id.
For example, on X-Gene1 there are 4 memory controllers (MC), each of them has
its own PMU. The index property tells us which MC a PMU belongs to.
The same for MCB/L3C and IOB.

> Thanks,
> Mark.

Thanks,
Tai
Tai Nguyen April 5, 2016, 6:51 p.m. UTC | #5
Hi Mark,

On Mon, Apr 4, 2016 at 4:38 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Apr 04, 2016 at 04:40:33PM -0700, Tai Tri Nguyen wrote:
>> On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
>> >> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
>> >> +The following PMU devices are supported:
>> >> +
>> >> +  L3C                        - L3 cache controller
>> >> +  IOB                        - IO bridge
>> >> +  MCB                        - Memory controller bridge
>> >> +  MC                 - Memory controller
>> >
>> > These sound like separate units. How do these relate?
>> >
>> > Is there an SOC-wide PMU that aggregates counters, or are these actually
>> > independent?
>> >
>>
>> Yes, they are independent, but sharing the same top level status interrupt.
>> There's no SOC-wide PMU which aggregates these counters.
>
> If they're just sharing the interrupt, why are they not separate nodes (and
> drivers) which simply happen to share an interrupt?
>
> Is there anything else shared?

Yes, a long with the interrupt they also share top level PMU status CSR region.

>
>> >> +The following section describes the SoC PMU DT node binding.
>> >> +
>> >> +Required properties:
>> >> +- compatible         : Shall be "apm,xgene-pmu" for revision 1 or
>> >> +                          "apm,xgene-pmu-v2" for revision 2.
>> >
>> > That name is very general. Is there not a more specific name for the SOC
>> > PMU?
>> >
>>
>> Beside the ARMv8 core PMU which has the compatible name "arm,armv8-pmuv3",
>> these are all the PMUs in X-Gene SoCs. Also, we are using the same PMU
>> driver across our platforms. I think a general name is what it should be.
>
> Depending on my prior question, I'm not sure that's necessarily true. If
> there's no actual shared SoC PMU logic as such, the names below for each
> individual PMU seem fine.
>

Given that they are sharing the same top level PMU status CSRs, a
combined driver
seems to be the best approach in my opinion.

>> >> +Required properties for L3C subnode:
>> >> +- compatible         : Shall be "apm,xgene-pmu-l3c".
>> >> +- reg                        : First resource shall be the L3C PMU resource.
>> >> +- index                      : Instance number of the L3C PMU.
>> >> +
>> >> +Required properties for IOB subnode:
>> >> +- compatible         : Shall be "apm,xgene-pmu-iob".
>> >> +- reg                        : First resource shall be the IOB PMU resource.
>> >> +- index                      : Instance number of the IOB PMU.
>> >> +
>> >> +Required properties for MCB subnode:
>> >> +- compatible         : Shall be "apm,xgene-pmu-mcb".
>> >> +- reg                        : First resource shall be the MCB PMU resource.
>> >> +- index                      : Instance number of the MCB PMU.
>> >> +
>> >> +Required properties for MC subnode:
>> >> +- compatible         : Shall be "apm,xgene-pmu-mc".
>> >> +- reg                        : First resource shall be the MC PMU resource.
>> >> +- index                      : Instance number of the MC PMU.
>> >
>> > What's the index property useful for?
>> >
>>
>> The index property is used for indicating the physical hardware PMU id.
>> For example, on X-Gene1 there are 4 memory controllers (MC), each of them has
>> its own PMU. The index property tells us which MC a PMU belongs to.
>> The same for MCB/L3C and IOB.
>
> Sure, but is this simply informative for the user, or does this have an impact
> on the programming model?
>

Yes, it does impact. For example, there are 4 PMUs associated with 4 MCs.
They all certainly have the same sort of events. The index will help
to determine
the right event users want to monitor. Below is an example of perf list output:
...
mc0/mcu-rd-request/
...
mc1/mcu-rd-request/
...

Regards,
Mark Rutland April 5, 2016, 7:31 p.m. UTC | #6
On Tue, Apr 05, 2016 at 11:51:02AM -0700, Tai Tri Nguyen wrote:
> Hi Mark,
> 
> On Mon, Apr 4, 2016 at 4:38 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Apr 04, 2016 at 04:40:33PM -0700, Tai Tri Nguyen wrote:
> >> On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
> >> >> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
> >> >> +The following PMU devices are supported:
> >> >> +
> >> >> +  L3C                        - L3 cache controller
> >> >> +  IOB                        - IO bridge
> >> >> +  MCB                        - Memory controller bridge
> >> >> +  MC                 - Memory controller
> >> >
> >> > These sound like separate units. How do these relate?
> >> >
> >> > Is there an SOC-wide PMU that aggregates counters, or are these actually
> >> > independent?
> >> >
> >>
> >> Yes, they are independent, but sharing the same top level status interrupt.
> >> There's no SOC-wide PMU which aggregates these counters.
> >
> > If they're just sharing the interrupt, why are they not separate nodes (and
> > drivers) which simply happen to share an interrupt?
> >
> > Is there anything else shared?
> 
> Yes, a long with the interrupt they also share top level PMU status CSR region.

Ah, ok. I had missed that.

What exactly exists in that region? Are the shared registers just for handling
the shared interrupt, or are they used to handle other parts of the PMUs too?

> >> >> +Required properties for L3C subnode:
> >> >> +- compatible         : Shall be "apm,xgene-pmu-l3c".
> >> >> +- reg                        : First resource shall be the L3C PMU resource.
> >> >> +- index                      : Instance number of the L3C PMU.
> >> >> +
> >> >> +Required properties for IOB subnode:
> >> >> +- compatible         : Shall be "apm,xgene-pmu-iob".
> >> >> +- reg                        : First resource shall be the IOB PMU resource.
> >> >> +- index                      : Instance number of the IOB PMU.
> >> >> +
> >> >> +Required properties for MCB subnode:
> >> >> +- compatible         : Shall be "apm,xgene-pmu-mcb".
> >> >> +- reg                        : First resource shall be the MCB PMU resource.
> >> >> +- index                      : Instance number of the MCB PMU.
> >> >> +
> >> >> +Required properties for MC subnode:
> >> >> +- compatible         : Shall be "apm,xgene-pmu-mc".
> >> >> +- reg                        : First resource shall be the MC PMU resource.
> >> >> +- index                      : Instance number of the MC PMU.
> >> >
> >> > What's the index property useful for?
> >> >
> >>
> >> The index property is used for indicating the physical hardware PMU id.
> >> For example, on X-Gene1 there are 4 memory controllers (MC), each of them has
> >> its own PMU. The index property tells us which MC a PMU belongs to.
> >> The same for MCB/L3C and IOB.
> >
> > Sure, but is this simply informative for the user, or does this have an impact
> > on the programming model?
> >
> 
> Yes, it does impact. For example, there are 4 PMUs associated with 4 MCs.
> They all certainly have the same sort of events. The index will help
> to determine
> the right event users want to monitor. Below is an example of perf list output:
> ...
> mc0/mcu-rd-request/
> ...
> mc1/mcu-rd-request/

By "programming model" I mean the way the kernel interacts with the device,
rather than the interface exposed to userspace. For example, does the index
affect which bits are used in the shared CSR region?

If it's only used for the name exposed to userspace, that's fine.

Otherwise, there may be subtle gotchas.

Thanks,
Mark.
Tai Nguyen April 5, 2016, 9:51 p.m. UTC | #7
Hi Mark,

On Tue, Apr 5, 2016 at 12:31 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Apr 05, 2016 at 11:51:02AM -0700, Tai Tri Nguyen wrote:
>> Hi Mark,
>>
>> On Mon, Apr 4, 2016 at 4:38 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Mon, Apr 04, 2016 at 04:40:33PM -0700, Tai Tri Nguyen wrote:
>> >> On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> >> > On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote:
>> >> >> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
>> >> >> +The following PMU devices are supported:
>> >> >> +
>> >> >> +  L3C                        - L3 cache controller
>> >> >> +  IOB                        - IO bridge
>> >> >> +  MCB                        - Memory controller bridge
>> >> >> +  MC                 - Memory controller
>> >> >
>> >> > These sound like separate units. How do these relate?
>> >> >
>> >> > Is there an SOC-wide PMU that aggregates counters, or are these actually
>> >> > independent?
>> >> >
>> >>
>> >> Yes, they are independent, but sharing the same top level status interrupt.
>> >> There's no SOC-wide PMU which aggregates these counters.
>> >
>> > If they're just sharing the interrupt, why are they not separate nodes (and
>> > drivers) which simply happen to share an interrupt?
>> >
>> > Is there anything else shared?
>>
>> Yes, a long with the interrupt they also share top level PMU status CSR region.
>
> Ah, ok. I had missed that.
>
> What exactly exists in that region? Are the shared registers just for handling
> the shared interrupt, or are they used to handle other parts of the PMUs too?

They are shared registers for handling the shared interrupt only,
indicating/masking source of the
shared interrupt.

>
>> >> >> +Required properties for L3C subnode:
>> >> >> +- compatible         : Shall be "apm,xgene-pmu-l3c".
>> >> >> +- reg                        : First resource shall be the L3C PMU resource.
>> >> >> +- index                      : Instance number of the L3C PMU.
>> >> >> +
>> >> >> +Required properties for IOB subnode:
>> >> >> +- compatible         : Shall be "apm,xgene-pmu-iob".
>> >> >> +- reg                        : First resource shall be the IOB PMU resource.
>> >> >> +- index                      : Instance number of the IOB PMU.
>> >> >> +
>> >> >> +Required properties for MCB subnode:
>> >> >> +- compatible         : Shall be "apm,xgene-pmu-mcb".
>> >> >> +- reg                        : First resource shall be the MCB PMU resource.
>> >> >> +- index                      : Instance number of the MCB PMU.
>> >> >> +
>> >> >> +Required properties for MC subnode:
>> >> >> +- compatible         : Shall be "apm,xgene-pmu-mc".
>> >> >> +- reg                        : First resource shall be the MC PMU resource.
>> >> >> +- index                      : Instance number of the MC PMU.
>> >> >
>> >> > What's the index property useful for?
>> >> >
>> >>
>> >> The index property is used for indicating the physical hardware PMU id.
>> >> For example, on X-Gene1 there are 4 memory controllers (MC), each of them has
>> >> its own PMU. The index property tells us which MC a PMU belongs to.
>> >> The same for MCB/L3C and IOB.
>> >
>> > Sure, but is this simply informative for the user, or does this have an impact
>> > on the programming model?
>> >
>>
>> Yes, it does impact. For example, there are 4 PMUs associated with 4 MCs.
>> They all certainly have the same sort of events. The index will help
>> to determine
>> the right event users want to monitor. Below is an example of perf list output:
>> ...
>> mc0/mcu-rd-request/
>> ...
>> mc1/mcu-rd-request/
>
> By "programming model" I mean the way the kernel interacts with the device,
> rather than the interface exposed to userspace. For example, does the index
> affect which bits are used in the shared CSR region?
>
> If it's only used for the name exposed to userspace, that's fine.
>
> Otherwise, there may be subtle gotchas.

No, it doesn't impact in that mean.

Regards,
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
new file mode 100644
index 0000000..40dfd4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/apm-xgene-pmu.txt
@@ -0,0 +1,116 @@ 
+* APM X-Gene SoC PMU bindings
+
+This is APM X-Gene SoC PMU (Performance Monitoring Unit) module.
+The following PMU devices are supported:
+
+  L3C			- L3 cache controller
+  IOB			- IO bridge
+  MCB			- Memory controller bridge
+  MC			- Memory controller
+
+The following section describes the SoC PMU DT node binding.
+
+Required properties:
+- compatible		: Shall be "apm,xgene-pmu" for revision 1 or
+                          "apm,xgene-pmu-v2" for revision 2.
+- regmap-csw		: Regmap of the CPU switch fabric (CSW) resource.
+- regmap-mcba		: Regmap of the MCB-A (memory bridge) resource.
+- regmap-mcbb		: Regmap of the MCB-B (memory bridge) resource.
+- reg			: First resource shall be the CPU bus PMU resource.
+- interrupts            : Interrupt-specifier for PMU IRQ.
+
+Required properties for L3C subnode:
+- compatible		: Shall be "apm,xgene-pmu-l3c".
+- reg			: First resource shall be the L3C PMU resource.
+- index			: Instance number of the L3C PMU.
+
+Required properties for IOB subnode:
+- compatible		: Shall be "apm,xgene-pmu-iob".
+- reg			: First resource shall be the IOB PMU resource.
+- index			: Instance number of the IOB PMU.
+
+Required properties for MCB subnode:
+- compatible		: Shall be "apm,xgene-pmu-mcb".
+- reg			: First resource shall be the MCB PMU resource.
+- index			: Instance number of the MCB PMU.
+
+Required properties for MC subnode:
+- compatible		: Shall be "apm,xgene-pmu-mc".
+- reg			: First resource shall be the MC PMU resource.
+- index			: Instance number of the MC PMU.
+
+Example:
+	csw: csw@7e200000 {
+		compatible = "apm,xgene-csw", "syscon";
+		reg = <0x0 0x7e200000 0x0 0x1000>;
+	};
+
+	mcba: mcba@7e700000 {
+		compatible = "apm,xgene-mcb", "syscon";
+		reg = <0x0 0x7e700000 0x0 0x1000>;
+	};
+
+	mcbb: mcbb@7e720000 {
+		compatible = "apm,xgene-mcb", "syscon";
+		reg = <0x0 0x7e720000 0x0 0x1000>;
+	};
+
+	pmu: pmu@78810000 {
+		compatible = "apm,xgene-pmu-v2";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+		regmap-csw = <&csw>;
+		regmap-mcba = <&mcba>;
+		regmap-mcbb = <&mcbb>;
+		reg = <0x0 0x78810000 0x0 0x1000>;
+		interrupts = <0x0 0x22 0x4>;
+
+		pmul3c@7e610000 {
+			compatible = "apm,xgene-pmu-l3c";
+			reg = <0x0 0x7e610000 0x0 0x1000>;
+			index = <0>;
+		};
+
+		pmuiob@7e940000 {
+			compatible = "apm,xgene-pmu-iob";
+			reg = <0x0 0x7e940000 0x0 0x1000>;
+			index = <0>;
+		};
+
+		pmucmcb@7e710000 {
+			compatible = "apm,xgene-pmu-mcb";
+			reg = <0x0 0x7e710000 0x0 0x1000>;
+			index = <0>;
+		};
+
+		pmucmcb@7e730000 {
+			compatible = "apm,xgene-pmu-mcb";
+			reg = <0x0 0x7e730000 0x0 0x1000>;
+			index = <1>;
+		};
+
+		pmucmc@7e810000 {
+			compatible = "apm,xgene-pmu-mc";
+			reg = <0x0 0x7e810000 0x0 0x1000>;
+			index = <0>;
+		};
+
+		pmucmc@7e850000 {
+			compatible = "apm,xgene-pmu-mc";
+			reg = <0x0 0x7e850000 0x0 0x1000>;
+			index = <1>;
+		};
+
+		pmucmc@7e890000 {
+			compatible = "apm,xgene-pmu-mc";
+			reg = <0x0 0x7e890000 0x0 0x1000>;
+			index = <2>;
+		};
+
+		pmucmc@7e8d0000 {
+			compatible = "apm,xgene-pmu-mc";
+			reg = <0x0 0x7e8d0000 0x0 0x1000>;
+			index = <3>;
+		};
+	};