From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE
Date: Mon, 16 Jan 2017 10:59:04 +0000 [thread overview]
Message-ID: <20170116105904.GB1510@arm.com> (raw)
In-Reply-To: <20170113184352.GE2472@leverpostej>
On Fri, Jan 13, 2017 at 06:43:52PM +0000, Mark Rutland wrote:
> On Fri, Jan 13, 2017 at 04:03:49PM +0000, Will Deacon wrote:
> > This patch documents the devicetree binding in use for ARM SPE.
> >
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Rob Herring <robh@kernel.org>
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
> > ---
> > Documentation/devicetree/bindings/arm/spe-pmu.txt | 20 ++++++++++++++++++++
> > 1 file changed, 20 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/spe-pmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/arm/spe-pmu.txt b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > new file mode 100644
> > index 000000000000..d6540b491af4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/spe-pmu.txt
> > @@ -0,0 +1,20 @@
> > +* ARMv8.2 Statistical Profiling Extension (SPE) Performance Monitor Units (PMU)
> > +
> > +ARMv8.2 introduces the optional Statistical Profiling Extension for collecting
> > +performance sample data using an in-memory trace buffer.
> > +
> > +** SPE Required properties:
> > +
> > +- compatible : should be one of:
> > + "arm,arm-spe-pmu-v1"
>
> The second "arm" here doesn't seem to add much. Should that be "armv8.2"
> instead?
I don't think armv8.2 is particularly helpful, because that effectively ties
together the SPE version and the architecture version, which I don't think
is strictly required. The reason I added it was so that you could describe
a partner implementation as something like:
acme,arm-spe-pmu-v1
and know that it was acme's implementation of an ARM architectural feature.
If I drop the second "arm", I was worried that it might conflict with other
namespaces (e.g. acme's signal-processing-element's power-management-unit).
What do you reckon?
Will
next prev parent reply other threads:[~2017-01-16 10:59 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-13 16:03 [RFC PATCH v2 00/10] Add support for the ARMv8.2 Statistical Profiling Extension Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 01/10] arm64: cpufeature: allow for version discrepancy in PMU implementations Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 02/10] arm64: cpufeature: Don't enforce system-wide SPE capability Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 03/10] arm64: KVM: Save/restore the host SPE state when entering/leaving a VM Will Deacon
2017-01-16 11:25 ` Marc Zyngier
2017-01-18 15:24 ` Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 04/10] arm64: head.S: Enable EL1 (host) access to SPE when entered at EL2 Will Deacon
2017-01-13 19:21 ` Marc Zyngier
2017-01-13 16:03 ` [RFC PATCH v2 05/10] genirq: export irq_get_percpu_devid_partition to modules Will Deacon
2017-01-13 19:04 ` Marc Zyngier
2017-01-16 9:06 ` Thomas Gleixner
2017-01-13 16:03 ` [RFC PATCH v2 06/10] perf/core: Export AUX buffer helpers " Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 07/10] perf: Directly pass PERF_AUX_* flags to perf_aux_output_end Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 08/10] perf/core: Add PERF_AUX_FLAG_COLLISION to report colliding samples Will Deacon
2017-01-13 16:03 ` [RFC PATCH v2 09/10] drivers/perf: Add support for ARMv8.2 Statistical Profiling Extension Will Deacon
2017-01-13 16:40 ` Kim Phillips
2017-01-13 17:03 ` Will Deacon
2017-01-13 18:17 ` Kim Phillips
2017-01-13 16:03 ` [RFC PATCH v2 10/10] dt-bindings: Document devicetree binding for ARM SPE Will Deacon
2017-01-13 18:43 ` Mark Rutland
2017-01-16 10:59 ` Will Deacon [this message]
2017-01-17 16:31 ` Kim Phillips
2017-01-17 16:50 ` Mark Rutland
2017-01-17 16:45 ` Mark Rutland
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=20170116105904.GB1510@arm.com \
--to=will.deacon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).