From: jnair@caviumnetworks.com (Jayachandran C)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
Date: Mon, 24 Apr 2017 16:40:09 +0000 [thread overview]
Message-ID: <20170424164008.GA4657@localhost> (raw)
In-Reply-To: <20170424140348.GB5767@leverpostej>
On Mon, Apr 24, 2017 at 03:03:48PM +0100, Mark Rutland wrote:
> On Mon, Apr 24, 2017 at 01:39:30PM +0000, Jayachandran C wrote:
> > The v8.1 supplement is quite clear on the field definition:
> >
> > PMUVer, bits [11:8]
> > ....
> > Defined values are:
> > 0000 Performance Monitors extension System registers not implemented.
> > 0001 Performance Monitors extension System registers implemented, PMUv3.
> > 0100 Performance Monitors extension System registers implemented, PMUv3, with a 16-bit
> > evtCount field, and if EL2 is implemented, the addition of the MDCR_EL2.HPMD bit.
> > 1111 IMPLEMENTATION DEFINED form of performance monitors supported, PMUv3 not
> > supported.
> > All other values are reserved.
> > In ARMv8-A the permitted values are 0b0000, 0b0001 and 0b1111.
> > In ARMv8.1 the permitted values are 0b0000, 0b0100 and 0b1111.
> >
> > I changed the code to strictly do this. We have to exclude 0xf, since that is not PMUv3.
> > And we cannot predict what the reserved values will represent, so it is best to skip them
> > until they are defined to be PMUv3 compatible.
>
> My understanding is that ID_AA64DFR0.PMUVer is intended to be covered by
> the usual ID register principles, and thus at least 0x2-0x7 are reserved
> for architected backwards compatible extensions to PMUv3.
>
> See ARM DDI 0487B.a, D7.1.4, "Principles of the ID scheme for fields in
> ID registers". It is explicitly stated that the scheme applies to
> ID_AA64DFR0.
>
> Per those rules, we should check >= the minimum PMUv3 implemented value,
> i.e. val >= 1. Due to both 0x0 and 0xF meaning PMUv3 isn't implemented,
> it's not clear if the fields should be treated as if it were signed or
> unsigned, and I'm awaiting clarification on this.
Thanks for the reference. Since 0xf means that there is a PMU (but it is
not PMUv3), this looks like an unsigned ID with a special case.
> Either way, I believe that 0x1-0x7 must all be compatible with baseline
> PMUv3 per the ID scheme principles.
In case you don't get authoritative information on this, can you please
merge a version which does either 'if (pmuver < 1 || pmuver == 0xf)' or
'if (pmuver < 1 || pmuver > 7)' to the patchset?
Thanks,
JC.
next prev parent reply other threads:[~2017-04-24 16:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-24 11:31 [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension Jayachandran C
2017-04-24 12:57 ` Mark Rutland
2017-04-24 13:39 ` Jayachandran C
2017-04-24 14:03 ` Mark Rutland
2017-04-24 16:40 ` Jayachandran C [this message]
2017-04-24 16:45 ` Mark Rutland
2017-04-24 17:45 ` Jayachandran C
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=20170424164008.GA4657@localhost \
--to=jnair@caviumnetworks.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).