All of lore.kernel.org
 help / color / mirror / Atom feed
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: EDAC driver for ARMv8 L1/L2 cache
Date: Fri, 12 Jan 2018 18:00:48 +0000	[thread overview]
Message-ID: <20180112180048.srniseo2ft7ytqve@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <VI1PR04MB20780EF853A0822A6EFCFE449A170@VI1PR04MB2078.eurprd04.prod.outlook.com>

On Fri, Jan 12, 2018 at 05:44:56PM +0000, York Sun wrote:
> On 01/12/2018 09:38 AM, Mark Rutland wrote:
> > On Fri, Jan 12, 2018 at 05:17:54PM +0000, York Sun wrote:
> >> On 01/12/2018 09:13 AM, Borislav Petkov wrote:
> >>> On Fri, Jan 12, 2018 at 04:48:05PM +0000, York Sun wrote:
> >>>> I see Stratix10 has A53 core. I am concerned on reading the
> >>>> CPUMERRSR_EL1 and L2MERRSR_EL1. The are IMPLEMENTATION DEFINED
> >>>> registers. They may not be available on all SoCs, or all time.
> >>>
> >>> Is there something like CPUID on x86, on ARM64 which denotes presence of
> >>> a certain feature?
> >>>
> >>> Or is that thing devicetree?
> >>
> >> This feature is available on the SoC I am working on (NXP LS1046A). It
> >> seems always there. I don't know if there is any register denoting the
> >> existence of such feature.
> > 
> > There is no architectural register describing this.
> > 
> > Judging by the Cortex-A53 TRM, there is no IMP DEF / auxilliary register
> > describing this.
> > 
> > Regardless, a DT binding is necessary due to potential interactions with
> > FW, hypervisors, etc.
> > 
> >> I guess we can use device tree if this feature exists. Not sure if
> >> big.LITTLE is a concern here.
> > 
> > There are big.LITTLE systems with Cortex-A53, so we definitely care
> > about big.LITTLE here.
> > 
> 
> For a given system, for example A72-A53 big.LITTLE configuration, the
> feature is known and can be described in DT. We have to detect which
> core is running to determine if this feature is available. Does this
> sound right?

The binding will need to explicitly describe the set of CPUs the feature
is usable on.

On a big.LITTLE system, I'd expect multiple nodes in the DT, similar to
what we have for PMUs. Even if all CPUs have some EDAC functionality, it
will differ across microarchitectures.

e.g. we'd have something like:

edac-a72 {
	compatible = "arm,cortex-a72-edac";
	cpus = <&cpu0>, <&cpu 1>;
	...
};

edac-a53 {
	compatible = "arm,cortex-a53-edac";
	cpus = <&cpu2>, <&cpu 3>;
	...
};

... and it may get more complicated from there on. There may be other
users like FW or Secure OSs that we have to interact with, this might
get arbitrarily reset across idle, etc.

The Cortex-A53 TRM doesn't use the term EDAC at all, and refers
separately to "CPU Memory Error" functionality an "L2 Memory Error"
functionality. I don't know if those are expected to be used separately.

Thanks,
Mark.

  reply	other threads:[~2018-01-12 18:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <VI1PR04MB2078DBC9381EA574CE5DA4B09A100@VI1PR04MB2078.eurprd04.prod.outlook.com>
2018-01-09 21:43 ` EDAC driver for ARMv8 L1/L2 cache Borislav Petkov
2018-01-09 21:51   ` York Sun
2018-01-09 22:00     ` Borislav Petkov
2018-01-12 16:38     ` Thor Thayer
2018-01-12 16:48       ` York Sun
2018-01-12 17:12         ` Borislav Petkov
2018-01-12 17:17           ` York Sun
2018-01-12 17:38             ` Mark Rutland
2018-01-12 17:44               ` York Sun
2018-01-12 18:00                 ` Mark Rutland [this message]
2018-01-12 18:16                   ` York Sun
2018-01-13 11:31                     ` Borislav Petkov
2018-01-15 14:21                       ` Mark Rutland
2018-01-15 14:32                         ` Borislav Petkov
2018-01-15 14:49                           ` Mark Rutland
2018-01-15 16:19                           ` York Sun
2018-01-15 23:23                             ` Borislav Petkov
2018-01-15 23:28                               ` York Sun
2018-01-15 23:52                                 ` Borislav Petkov
2018-01-16  0:16                                   ` York Sun
2018-02-01 20:56                                   ` York Sun
2018-02-08 15:31                                     ` James Morse
2018-02-08 15:53                                       ` York Sun
2018-01-12 17:23           ` Mark Rutland
2018-01-12 17:39         ` Thor Thayer

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=20180112180048.srniseo2ft7ytqve@lakrids.cambridge.arm.com \
    --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.