mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Joshua Yeong <joshua.yeong@starfivetech.com>
To: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	pjw@kernel.org, palmer@dabbelt.com, aou@eecs.berkeley.edu,
	rafael@kernel.org, viresh.kumar@linaro.org, ulfh@kernel.org,
	rahul@summations.net, anup@brainfault.org, lftan.linux@gmail.com
Cc: alex@ghiti.fr, joshua.yeong@starfivetech.com,
	linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/7] Add RISC-V RPMI performance service support
Date: Thu,  8 Oct 2026 17:10:24 +0800	[thread overview]
Message-ID: <20261008091032.2832333-1-joshua.yeong@starfivetech.com> (raw)

The RISC-V Platform Management Interface (RPMI) specification defines a
modular and extensible messaging protocol between the supervisor software
and a platform microcontroller (PuC). Among the service groups it defines
is the performance service group (service group ID 0x0000A), which allows
the supervisor to enumerate the performance domains managed by the PuC,
query their attributes and supported levels, and get/set their
performance level and limits, optionally through fast channels in shared
memory.

The specification says the service group is primarily meant for devices
such as GPUs and accelerators, though it can also be used for application
processors. This series adds supervisor-side support for both:

 - DT bindings for the performance domain controller exposed to the
   supervisor ("riscv,rpmi-performance") and for the SBI MPXY channel
   that the SBI implementation uses to expose the service group to the
   supervisor ("riscv,rpmi-mpxy-performance"). A CPU names its domain
   through "performance-domains", documented for RISC-V CPUs. Any other
   device names it through "power-domains": the controller is also a
   power domain provider, with one power domain per performance domain
   and the levels of the domain as the performance states of that power
   domain.

 - A core for the service group, drivers/firmware/riscv/
   riscv-rpmi-performance.c, which owns the mailbox channel, since the
   channel cannot be shared between drivers. At probe it checks the
   RPMI and service group versions, queries PERF_GET_NUM_DOMAINS, then
   for each domain PERF_GET_ATTRIBUTES and PERF_GET_SUPPORTED_LEVELS, and
   sets up the level fast channels from PERF_GET_FAST_CHANNEL_REGION and
   PERF_GET_FAST_CHANNEL_ATTRIBUTES. It exports an interface to read and
   set the levels and limits of a domain, and creates the devices the
   front-ends below bind to.

 - A cpufreq driver, drivers/cpufreq/riscv-rpmi-cpufreq.c. CPUs that
   name the same domain share a policy, the levels of the domain become
   its frequency table, and the level is set through the domain's fast
   channel when it has one, so that the governor can switch frequency
   from the scheduler. An energy model is registered from the power cost
   of each level.

 - A power domain driver, drivers/pmdomain/riscv/riscv-rpmi-perf-domain.c,
   which registers each performance domain as a generic power domain
   with performance states. A device that attaches is handed an
   operating point per level of the domain, and its driver drives the
   domain through the OPP library, with devfreq on top if it wants a
   governor. Several devices can share a domain, and genpd runs it at the
   highest level any of them asks for. Performance state N is RPMI level
   index N - 1, since genpd keeps state 0 for "no request". A device
   that names a domain the CPUs use is refused, so that cpufreq and genpd
   never both set the level of one domain.

 - A MAINTAINERS update adding the drivers and their bindings to the
   RPMI device power entry, renamed "RISC-V RPMI DEVICE POWER AND
   PERFORMANCE DRIVERS".

The series has a prerequisite: the RPMI device power series ("Add
RISC-V RPMI device power service support"), which has been applied for
next:

  https://lists.infradead.org/pipermail/linux-riscv/2026-September/099498.html

Changes in v2:
 - Split the driver. The RPMI protocol, the mailbox channel and the
   domain enumeration move into a core for the service group under
   drivers/firmware/riscv/, and the cpufreq driver becomes a front-end
   over it.
 - Add the power domain front-end, so that devices other than CPUs can
   use a performance domain. CPUs changes the performance through
   "performance-domains" and other devices through "power-domains".

v1: https://lore.kernel.org/r/20260106092117.3727152-1-joshua.yeong@starfivetech.com

Testing
=======

The series was tested under QEMU with the RPMI performance service
implemented in firmware.

Components:

 - OpenSBI: v1.9
   https://github.com/riscv-software-src/opensbi

 - QEMU: the RPMI-enabled tree at
   https://github.com/yeongjoshua/qemu/tree/rpmi-v11.1.0

Kernel config: enable CONFIG_RISCV_RPMI_PERFORMANCE,
CONFIG_RISCV_RPMI_CPUFREQ and CONFIG_RISCV_RPMI_PERF_DOMAIN (all default
y on RISC-V when MAILBOX is enabled) along with the SBI MPXY mailbox
driver.

Run with:

  qemu-system-riscv64 \
      -M virt -m 2G -smp 4 \
      -bios fw_dynamic.bin \
      -kernel Image \
      -M rpmi=true \
      -nographic \
      -initrd rootfs-busybox.cpio \
      -append "root=/dev/ram rw console=ttyS0,115200 no_console_suspend mem=2048M earlycon=uart8250,mmio,0x10000000"

The emulated PuC advertises seven performance domains. With -smp 4, cpu0
and cpu1 share one domain and one cpufreq policy, cpu2 has a domain of
its own, and cpu3 has none. A test device names one of the remaining
domains through "power-domains". Each policy's frequency table matches
the levels of its domain, and frequencies set through the userspace
governor read back from the PuC, with the level set through the fast
channel and its doorbell. A consumer test driver, kept out of this
series, attached the test device to its power domain, drove it through
the OPP library with devfreq on top, set every operating point and read
the level behind each one back from the PuC, checked that a level the
domain never advertised is refused, and ran alongside cpufreq without
either disturbing the other's domain. A device naming a CPU's domain was
refused, and so was a CPU naming another provider. With failures
simulated in the core (a domain that fails enumeration, a level table
returned in reverse order, a fast-channel region too small for its
channels), the affected domain or fast channel was left out or fell
back to the mailbox, as intended. All checks passed. The series also
builds for arm64 with COMPILE_TEST.

Joshua Yeong (7):
  dt-bindings: dvfs: Add RPMI performance service message proxy bindings
  dt-bindings: dvfs: Add RPMI performance service bindings
  dt-bindings: riscv: cpus: document performance-domains property
  firmware: riscv: Add RPMI performance service
  cpufreq: Add RISC-V RPMI cpufreq driver
  pmdomain: riscv: Add RPMI performance domains as power domains
  MAINTAINERS: Add RISC-V RPMI performance driver

 .../dvfs/riscv,rpmi-mpxy-performance.yaml     |   65 +
 .../bindings/dvfs/riscv,rpmi-performance.yaml |   88 ++
 .../devicetree/bindings/riscv/cpus.yaml       |    3 +
 MAINTAINERS                                   |    7 +-
 drivers/cpufreq/Kconfig                       |   16 +
 drivers/cpufreq/Makefile                      |    4 +
 drivers/cpufreq/riscv-rpmi-cpufreq.c          |  294 ++++
 drivers/firmware/Kconfig                      |    1 +
 drivers/firmware/Makefile                     |    1 +
 drivers/firmware/riscv/Kconfig                |   17 +
 drivers/firmware/riscv/Makefile               |    3 +
 .../firmware/riscv/riscv-rpmi-performance.c   | 1186 +++++++++++++++++
 drivers/pmdomain/riscv/Kconfig                |   16 +
 drivers/pmdomain/riscv/Makefile               |    1 +
 .../pmdomain/riscv/riscv-rpmi-perf-domain.c   |  265 ++++
 .../firmware/riscv/riscv-rpmi-performance.h   |  148 ++
 include/linux/mailbox/riscv-rpmi-message.h    |   16 +
 17 files changed, 2130 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/dvfs/riscv,rpmi-mpxy-performance.yaml
 create mode 100644 Documentation/devicetree/bindings/dvfs/riscv,rpmi-performance.yaml
 create mode 100644 drivers/cpufreq/riscv-rpmi-cpufreq.c
 create mode 100644 drivers/firmware/riscv/Kconfig
 create mode 100644 drivers/firmware/riscv/Makefile
 create mode 100644 drivers/firmware/riscv/riscv-rpmi-performance.c
 create mode 100644 drivers/pmdomain/riscv/riscv-rpmi-perf-domain.c
 create mode 100644 include/linux/firmware/riscv/riscv-rpmi-performance.h


base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
prerequisite-patch-id: 907ffadca74a65c93ad38f428e002d2b34341067
prerequisite-patch-id: 5a4df94e66de2f63697891a0f1382fabd9df7b6f
prerequisite-patch-id: 0827a7050d08fea7deaab8e82f2dd16acdca507d
--
2.43.0

             reply	other threads:[~2026-10-08  9:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  9:10 Joshua Yeong [this message]
2026-10-08  9:10 ` [PATCH v2 1/7] dt-bindings: dvfs: Add RPMI performance service message proxy bindings Joshua Yeong
2026-10-08  9:10 ` [PATCH v2 2/7] dt-bindings: dvfs: Add RPMI performance service bindings Joshua Yeong
2026-10-08 10:41   ` Conor Dooley
2026-10-08  9:10 ` [PATCH v2 3/7] dt-bindings: riscv: cpus: document performance-domains property Joshua Yeong
2026-10-08  9:10 ` [PATCH v2 4/7] firmware: riscv: Add RPMI performance service Joshua Yeong
2026-10-08  9:10 ` [PATCH v2 5/7] cpufreq: Add RISC-V RPMI cpufreq driver Joshua Yeong
2026-10-08  9:10 ` [PATCH v2 6/7] pmdomain: riscv: Add RPMI performance domains as power domains Joshua Yeong
2026-10-08  9:10 ` [PATCH v2 7/7] MAINTAINERS: Add RISC-V RPMI performance driver Joshua Yeong

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=20261008091032.2832333-1-joshua.yeong@starfivetech.com \
    --to=joshua.yeong@starfivetech.com \
    --cc=alex@ghiti.fr \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=lftan.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rafael@kernel.org \
    --cc=rahul@summations.net \
    --cc=robh@kernel.org \
    --cc=ulfh@kernel.org \
    --cc=viresh.kumar@linaro.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

all inboxes | Powered by JetHome®