From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 07/11] arm: perf: document PMU affinity binding
Date: Mon, 17 Nov 2014 15:01:46 +0000 [thread overview]
Message-ID: <20141117150145.GA25416@leverpostej> (raw)
In-Reply-To: <CAL_Jsq+u9--tP-pYBut0V6oAnRDbwqpaJ9UMyW55AhCNFV10sA@mail.gmail.com>
Hi Rob,
I appear to have typo'd your address when posting this. Sorry about
that; I'll make sure it doesn't happen again.
On Mon, Nov 17, 2014 at 02:32:57PM +0000, Rob Herring wrote:
> On Fri, Nov 7, 2014 at 10:25 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > To describe the various ways CPU PMU interrupts might be wired up, we
> > can refer to the topology information in the device tree.
> >
> > This patch adds a new property to the PMU binding, interrupts-affinity,
> > which describes the relationship between CPUs and interrupts. This
> > information is necessary to handle systems with heterogeneous PMU
> > implementations (e.g. big.LITTLE). Documentation is added describing the
> > use of said property.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/pmu.txt | 104 +++++++++++++++++++++++++-
> > 1 file changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
> > index 75ef91d..23a0675 100644
> > --- a/Documentation/devicetree/bindings/arm/pmu.txt
> > +++ b/Documentation/devicetree/bindings/arm/pmu.txt
> > @@ -24,12 +24,114 @@ Required properties:
> >
> > Optional properties:
> >
> > +- interrupts-affinity : A list of phandles to topology nodes (see topology.txt) describing
> > + the set of CPUs associated with the interrupt at the same index.
>
> Are there cases beyond PMUs we need to handle? I would think so, so we
> should document this generically.
That was what I tried way back when I first tried to upstream all of
this, but in the mean time I've not encountered other devices which are
really CPU-affine which use SPIs and hence need a CPU<->IRQ relationship
described.
That said, I'm happy to document whatever approach for referring to a
set of CPUs that we settle on, if that seems more general than PMU IRQ
mapping.
> > -Example:
> > +Example 1 (A single CPU):
>
> Isn't this a single cluster of 2 cpus?
Yes, it is. My bad.
> > pmu {
> > compatible = "arm,cortex-a9-pmu";
> > interrupts = <100 101>;
> > };
> > +
> > +Example 2 (Multiple clusters with single interrupts):
>
> The meaning of single could be made a bit more clear especially if you
> consider Will's case. But I haven't really thought of better
> wording...
How about "A cluster of homogeneous CPUs"?
> > +
> > +cpus {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + CPU0: cpu at 0 {
> > + reg = <0x0>;
> > + compatible = "arm,cortex-a15-pmu";
> > + };
> > +
> > + CPU1: cpu at 1 {
> > + reg = <0x1>;
> > + compatible = "arm,cotex-a15-pmu";
> > + };
> > +
> > + CPU100: cpu at 100 {
> > + reg = <0x100>;
> > + compatible = "arm,cortex-a7-pmu";
> > + };
> > +
> > + cpu-map {
> > + cluster0 {
> > + CORE_0_0: core0 {
> > + cpu = <&CPU0>;
> > + };
> > + CORE_0_1: core1 {
> > + cpu = <&CPU1>;
> > + };
> > + };
> > + cluster1 {
> > + CORE_1_0: core0 {
> > + cpu = <&CPU100>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +pmu_a15 {
> > + compatible = "arm,cortex-a15-pmu";
> > + interrupts = <100>, <101>;
> > + interrupts-affinity = <&CORE0>, <&CORE1>;
>
> The phandle names are wrong here.
Whoops. I've fixed that up locally now.
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Rob Herring <robherring2@gmail.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 07/11] arm: perf: document PMU affinity binding
Date: Mon, 17 Nov 2014 15:01:46 +0000 [thread overview]
Message-ID: <20141117150145.GA25416@leverpostej> (raw)
In-Reply-To: <CAL_Jsq+u9--tP-pYBut0V6oAnRDbwqpaJ9UMyW55AhCNFV10sA@mail.gmail.com>
Hi Rob,
I appear to have typo'd your address when posting this. Sorry about
that; I'll make sure it doesn't happen again.
On Mon, Nov 17, 2014 at 02:32:57PM +0000, Rob Herring wrote:
> On Fri, Nov 7, 2014 at 10:25 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > To describe the various ways CPU PMU interrupts might be wired up, we
> > can refer to the topology information in the device tree.
> >
> > This patch adds a new property to the PMU binding, interrupts-affinity,
> > which describes the relationship between CPUs and interrupts. This
> > information is necessary to handle systems with heterogeneous PMU
> > implementations (e.g. big.LITTLE). Documentation is added describing the
> > use of said property.
> >
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/pmu.txt | 104 +++++++++++++++++++++++++-
> > 1 file changed, 103 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
> > index 75ef91d..23a0675 100644
> > --- a/Documentation/devicetree/bindings/arm/pmu.txt
> > +++ b/Documentation/devicetree/bindings/arm/pmu.txt
> > @@ -24,12 +24,114 @@ Required properties:
> >
> > Optional properties:
> >
> > +- interrupts-affinity : A list of phandles to topology nodes (see topology.txt) describing
> > + the set of CPUs associated with the interrupt at the same index.
>
> Are there cases beyond PMUs we need to handle? I would think so, so we
> should document this generically.
That was what I tried way back when I first tried to upstream all of
this, but in the mean time I've not encountered other devices which are
really CPU-affine which use SPIs and hence need a CPU<->IRQ relationship
described.
That said, I'm happy to document whatever approach for referring to a
set of CPUs that we settle on, if that seems more general than PMU IRQ
mapping.
> > -Example:
> > +Example 1 (A single CPU):
>
> Isn't this a single cluster of 2 cpus?
Yes, it is. My bad.
> > pmu {
> > compatible = "arm,cortex-a9-pmu";
> > interrupts = <100 101>;
> > };
> > +
> > +Example 2 (Multiple clusters with single interrupts):
>
> The meaning of single could be made a bit more clear especially if you
> consider Will's case. But I haven't really thought of better
> wording...
How about "A cluster of homogeneous CPUs"?
> > +
> > +cpus {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + CPU0: cpu@0 {
> > + reg = <0x0>;
> > + compatible = "arm,cortex-a15-pmu";
> > + };
> > +
> > + CPU1: cpu@1 {
> > + reg = <0x1>;
> > + compatible = "arm,cotex-a15-pmu";
> > + };
> > +
> > + CPU100: cpu@100 {
> > + reg = <0x100>;
> > + compatible = "arm,cortex-a7-pmu";
> > + };
> > +
> > + cpu-map {
> > + cluster0 {
> > + CORE_0_0: core0 {
> > + cpu = <&CPU0>;
> > + };
> > + CORE_0_1: core1 {
> > + cpu = <&CPU1>;
> > + };
> > + };
> > + cluster1 {
> > + CORE_1_0: core0 {
> > + cpu = <&CPU100>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +pmu_a15 {
> > + compatible = "arm,cortex-a15-pmu";
> > + interrupts = <100>, <101>;
> > + interrupts-affinity = <&CORE0>, <&CORE1>;
>
> The phandle names are wrong here.
Whoops. I've fixed that up locally now.
Thanks,
Mark.
next prev parent reply other threads:[~2014-11-17 15:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 16:25 [PATCH 00/11] arm: perf: add support for heterogeneous PMUs Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 01/11] of: Add empty of_get_next_parent stub Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 02/11] perf: allow for PMU-specific event filtering Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 03/11] arm: perf: treat PMUs as CPU affine Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 04/11] arm: perf: filter unschedulable events Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 05/11] arm: perf: reject multi-pmu groups Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 06/11] arm: perf: probe number of counters on affine CPUs Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 07/11] arm: perf: document PMU affinity binding Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-17 11:14 ` Will Deacon
2014-11-17 11:14 ` Will Deacon
2014-11-17 14:32 ` Rob Herring
2014-11-17 14:32 ` Rob Herring
2014-11-17 15:01 ` Mark Rutland [this message]
2014-11-17 15:01 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 08/11] arm: perf: add functions to parse affinity from dt Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-17 11:16 ` Will Deacon
2014-11-17 11:16 ` Will Deacon
2014-11-17 15:02 ` Mark Rutland
2014-11-17 15:02 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 09/11] arm: perf: parse cpu " Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-17 11:20 ` Will Deacon
2014-11-17 11:20 ` Will Deacon
2014-11-17 15:08 ` Mark Rutland
2014-11-17 15:08 ` Mark Rutland
2014-11-18 10:40 ` Will Deacon
2014-11-18 10:40 ` Will Deacon
2014-11-07 16:25 ` [PATCH 10/11] arm: perf: remove singleton PMU restriction Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-07 16:25 ` [PATCH 11/11] arm: dts: vexpress: describe all PMUs in TC2 dts Mark Rutland
2014-11-07 16:25 ` Mark Rutland
2014-11-17 11:24 ` [PATCH 00/11] arm: perf: add support for heterogeneous PMUs Will Deacon
2014-11-17 11:24 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141117150145.GA25416@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.