public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  reply	other threads:[~2014-11-17 15:02 UTC|newest]

Thread overview: 21+ 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 ` [PATCH 01/11] of: Add empty of_get_next_parent stub Mark Rutland
2014-11-07 16:25 ` [PATCH 02/11] perf: allow for PMU-specific event filtering Mark Rutland
2014-11-07 16:25 ` [PATCH 03/11] arm: perf: treat PMUs as CPU affine Mark Rutland
2014-11-07 16:25 ` [PATCH 04/11] arm: perf: filter unschedulable events Mark Rutland
2014-11-07 16:25 ` [PATCH 05/11] arm: perf: reject multi-pmu groups 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 ` [PATCH 07/11] arm: perf: document PMU affinity binding Mark Rutland
2014-11-17 11:14   ` Will Deacon
2014-11-17 14:32   ` Rob Herring
2014-11-17 15:01     ` Mark Rutland [this message]
2014-11-07 16:25 ` [PATCH 08/11] arm: perf: add functions to parse affinity from dt Mark Rutland
2014-11-17 11:16   ` Will Deacon
2014-11-17 15:02     ` Mark Rutland
2014-11-07 16:25 ` [PATCH 09/11] arm: perf: parse cpu " Mark Rutland
2014-11-17 11:20   ` Will Deacon
2014-11-17 15:08     ` Mark Rutland
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 ` [PATCH 11/11] arm: dts: vexpress: describe all PMUs in TC2 dts Mark Rutland
2014-11-17 11:24 ` [PATCH 00/11] arm: perf: add support for heterogeneous PMUs 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=Will.Deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robherring2@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox