Re: [PATCH v6 0/3] RISC-V: Create unique identification for SoC PMU

From: Palmer Dabbelt
Date: Mon Oct 03 2022 - 22:55:01 EST

On Mon, 15 Aug 2022 06:22:37 PDT (-0700), nikita.shubin@xxxxxxxxxxx wrote:
From: Nikita Shubin <n.shubin@xxxxxxxxx>

This series aims to provide matching vendor SoC with corresponded JSON bindings.

The ID string is proposed to be in form of MVENDORID-MARCHID-MIMPID, for example
for Sifive Unmatched the corresponding string will be:


Where MIMPID can vary as all impl supported the same number of events, this might not
be true for all future SoC however.

Also added SBI firmware events pretty names, as any firmware that supports SBI PMU
should also support firmare events [1].

Series depends on patch by Anup Patel, exposing mvendor, marchid and mimpid
to "/proc/cpuinfo" [2].


Link to previous version:

See original cover letter by João Mário Domingos:

Tested with the following OpenSBI device tree bindings:

pmu {
compatible = "riscv,pmu";
riscv,event-to-mhpmcounters =
<0x03 0x06 0x18
0x10001 0x10002 0x18
0x10009 0x10009 0x18
0x10011 0x10011 0x18
0x10019 0x10019 0x18
0x10021 0x10021 0x18>;
riscv,event-to-mhpmevent =
<0x03 0x00000000 0x1801
0x04 0x00000000 0x0302
0x05 0x00000000 0x4000
0x06 0x00000000 0x6001
0x10001 0x00000000 0x0202
0x10002 0x00000000 0x0402
0x10009 0x00000000 0x0102
0x10011 0x00000000 0x2002
0x10019 0x00000000 0x1002
0x10021 0x00000000 0x0802>;
riscv,raw-event-to-mhpmcounters =
<0x00000000 0x03ffff00 0x0 0x0 0x18
0x00000000 0x0007ff01 0x0 0x1 0x18
0x00000000 0x00003f02 0x0 0x2 0x18>;
Will Deacon:
- dropped first patch from v5 series it has been merged into master
Mayuresh Chitale:
- fixed FW_SFENCE_VMA_SENT event code

- added Tested-by tags

Nikita Shubin (3):
perf arch events: riscv sbi firmware std event files
perf vendor events riscv: add Sifive U74 JSON file
RISC-V: Added Syntacore SCR7 PMU events

tools/perf/pmu-events/arch/riscv/mapfile.csv | 18 +++
.../arch/riscv/riscv-sbi-firmware.json | 134 ++++++++++++++++++
.../arch/riscv/sifive/u74/firmware.json | 68 +++++++++
.../arch/riscv/sifive/u74/instructions.json | 92 ++++++++++++
.../arch/riscv/sifive/u74/memory.json | 32 +++++
.../arch/riscv/sifive/u74/microarch.json | 57 ++++++++
.../arch/riscv/syntacore/scr7/L1D_cache.json | 102 +++++++++++++
.../arch/riscv/syntacore/scr7/L1I_cache.json | 67 +++++++++
.../arch/riscv/syntacore/scr7/exceptions.json | 67 +++++++++
.../arch/riscv/syntacore/scr7/execution.json | 97 +++++++++++++
.../arch/riscv/syntacore/scr7/firmware.json | 68 +++++++++
.../arch/riscv/syntacore/scr7/general.json | 47 ++++++
.../arch/riscv/syntacore/scr7/interrupts.json | 32 +++++
.../arch/riscv/syntacore/scr7/prediction.json | 52 +++++++
14 files changed, 933 insertions(+)
create mode 100644 tools/perf/pmu-events/arch/riscv/mapfile.csv
create mode 100644 tools/perf/pmu-events/arch/riscv/riscv-sbi-firmware.json
create mode 100644 tools/perf/pmu-events/arch/riscv/sifive/u74/firmware.json
create mode 100644 tools/perf/pmu-events/arch/riscv/sifive/u74/instructions.json
create mode 100644 tools/perf/pmu-events/arch/riscv/sifive/u74/memory.json
create mode 100644 tools/perf/pmu-events/arch/riscv/sifive/u74/microarch.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/L1D_cache.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/L1I_cache.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/exceptions.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/execution.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/firmware.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/general.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/interrupts.json
create mode 100644 tools/perf/pmu-events/arch/riscv/syntacore/scr7/prediction.json

Acked-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>

not sure if you're looking for this via the RISC-V tree, it looks like usually these get merged via a perf tree? That's OK with me, but I'm also OK taking them through the RISC-V tree. Note that cpuinfo dependency seems to be triggering kasan failures, so we'll at least need to sort that out.