public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: pmuv3: Support v8.1 PMUv3 extension
Date: Mon, 24 Apr 2017 15:03:48 +0100	[thread overview]
Message-ID: <20170424140348.GB5767@leverpostej> (raw)
In-Reply-To: <20170424133929.GA4952@localhost>

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.

Either way, I believe that 0x1-0x7 must all be compatible with baseline
PMUv3 per the ID scheme principles.

Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2017-04-24 14:03 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 [this message]
2017-04-24 16:40       ` Jayachandran C
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=20170424140348.GB5767@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox