From: Joshua Yeong <joshua.yeong@starfivetech.com>
To: broonie@kernel.org, lgirdwood@gmail.com, rahul@summations.net,
anup@brainfault.org, lftan.linux@gmail.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu
Cc: alex@ghiti.fr, joshua.yeong@starfivetech.com,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH v4 0/3] Add RISC-V RPMI voltage service support
Date: Wed, 7 Oct 2026 18:00:17 +0800 [thread overview]
Message-ID: <20261007100022.2512187-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 voltage service group (service group ID 0x00007), which allows the
supervisor to enumerate the voltage domains managed by the PuC, query
their attributes and supported levels, switch them on and off, and
get/set their voltage level.
This series adds supervisor-side support for that service group:
- DT bindings for the regulator controller exposed to the supervisor
("riscv,rpmi-voltage") and for the SBI MPXY channel that the SBI
implementation uses to expose the service group to the supervisor
("riscv,rpmi-mpxy-voltage"). The name, level format, supported
levels and always-on capability of each domain are discovered at
runtime, so none of them is described in DT. A consumer names a
domain through a "<name>-supply" phandle to a child of the optional
"regulators" container, whose "reg" is the RPMI DOMAIN_ID. A child
may also give the board's regulator-min-microvolt and
regulator-max-microvolt, which the PuC has no way to express.
- A regulator driver, drivers/regulator/riscv-rpmi-regulator.c, which
talks to the PuC over an SBI MPXY mailbox channel. At probe it
checks the RPMI and service group versions, queries
VOLT_GET_NUM_DOMAINS, then for each domain VOLT_GET_ATTRIBUTES and
VOLT_GET_SUPPORTED_LEVELS and registers it as a regulator. Both
level formats the specification defines are supported: discrete
levels become a voltage table and linear (min, max, step) ranges
become linear ranges. The constraints are built from the discovered
levels and the always-on flag, with the transition latency as the
settling time, and a DT child can only narrow them. Enable and
disable go through VOLT_SET_CONFIG and voltage selection through
VOLT_SET_LEVEL and VOLT_GET_LEVEL.
- A MAINTAINERS update adding the driver and its bindings to the RPMI
device power entry, renamed "RISC-V RPMI DEVICE POWER AND VOLTAGE
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
Patch 2 needs it for include/linux/mailbox/riscv-rpmi-message.h, where
the voltage service group definitions are added next to the device
power ones that series introduces. Patch 3 also extends the MAINTAINERS
entry it adds. The base-commit and prerequisite-patch-id lines below
identify the tree the series applies to.
Changes in v4:
- Serialise the RPMI transactions on the mailbox channel with a mutex.
All the regulators of one controller share the channel, and the
client does not block on transmit, so two regulator operations
running at once could queue the second message behind the first and
return, freeing the on-stack message, before it was sent. Reported
by the Sashiko review of v3.
- The other point in that review, that mpxy_reg_set_voltage_sel()
rejects a 0 uV level, is left as is: the regulator core reads 0 uV
from list_voltage() as a selector that cannot be used, and rejects
voltage constraints whose minimum is 0 uV.
The bindings and the MAINTAINERS patch are unchanged from v3.
v1: https://lore.kernel.org/r/20260922161156.1088153-1-joshua.yeong@starfivetech.com
v2: https://lore.kernel.org/r/20260923070014.1340761-1-joshua.yeong@starfivetech.com
v3: https://lore.kernel.org/r/20261006083259.2206001-1-joshua.yeong@starfivetech.com
Testing
=======
The series was tested under QEMU with the RPMI voltage 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_REGULATOR_RISCV_RPMI (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 eight voltage domains, covering both level
formats, always-on and switchable domains, and domains the board
constrains in DT. They show up under /sys/class/regulator/ and in
/sys/kernel/debug/regulator/regulator_summary. Consumer test drivers,
kept out of this series, walked each domain to its highest and lowest
level, switched the switchable ones off and back on, and checked board
ranges and requests from several consumers sharing a rail, each naming
it through "<name>-supply", including requests carried by an OPP table.
All checks passed.
Joshua Yeong (3):
dt-bindings: regulator: Add RPMI voltage service bindings
regulator: Add RPMI voltage service
MAINTAINERS: Add RISC-V RPMI voltage driver
.../regulator/riscv,rpmi-mpxy-voltage.yaml | 65 ++
.../regulator/riscv,rpmi-voltage.yaml | 130 +++
MAINTAINERS | 5 +-
drivers/regulator/Kconfig | 14 +
drivers/regulator/Makefile | 1 +
drivers/regulator/riscv-rpmi-regulator.c | 908 ++++++++++++++++++
include/linux/mailbox/riscv-rpmi-message.h | 14 +
7 files changed, 1136 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/regulator/riscv,rpmi-mpxy-voltage.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/riscv,rpmi-voltage.yaml
create mode 100644 drivers/regulator/riscv-rpmi-regulator.c
base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
prerequisite-patch-id: 907ffadca74a65c93ad38f428e002d2b34341067
prerequisite-patch-id: 5a4df94e66de2f63697891a0f1382fabd9df7b6f
prerequisite-patch-id: 0827a7050d08fea7deaab8e82f2dd16acdca507d
--
2.43.0
next reply other threads:[~2026-10-07 10:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 10:00 Joshua Yeong [this message]
2026-10-07 10:00 ` [PATCH v4 1/3] dt-bindings: regulator: Add RPMI voltage service bindings Joshua Yeong
2026-10-07 14:47 ` Conor Dooley
2026-10-07 10:00 ` [PATCH v4 2/3] regulator: Add RPMI voltage service Joshua Yeong
2026-10-07 10:14 ` sashiko-bot
2026-10-07 10:00 ` [PATCH v4 3/3] MAINTAINERS: Add RISC-V RPMI voltage 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=20261007100022.2512187-1-joshua.yeong@starfivetech.com \
--to=joshua.yeong@starfivetech.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lftan.linux@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rahul@summations.net \
--cc=robh@kernel.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