On Mon, Oct 12, 2026 at 11:47:51AM +0200, Michal Simek wrote: > Hi, +Paul
Hello Michal, > > first of all do not use mailing list on denx.de. Ok, I sent this series at around the time U-Boot changed to [email protected]. Sorry for that. > > On 9/2/26 16:17, Charles Perry wrote: > > Hello, > > > > This series adds support for RISC-V Platform Management Interface (RPMI) to > > U-Boot. RPMI is an OS-agnostic protocol for communication between an > > Application Processor (AP) and a Platform Microcontroller (PuC) [1]. The > > goals and purpose of RPMI are similar to ARM's SCMI. > I have raised my concern at riscv minisummit at LPC and also talked to Paul > (riscv kernel maintainer) that this is not the right way to go. We already > have SCMI and there is no reason to introduce RPMI when it is said it is > serving the same purpose. Cool! Thanks for bringing this topic to LPC! That being said, I don't understand why we can't have both SCMI and RPMI. For sure its more code to maintain, but there are other things at play than just the functionnality. We discussed this in v2 [1], the points of contention were: * Anup said that the main blocker for him is that the SCMI spec is not community driven while RPMI is. * Conor mentionned that for SCMI to be usable on Risc-V, OpenSBI needs to accept SCMI related patches. * I pointed out that SCP-firmware doesn't receive any upstream contribution [2] while librpmi does. Features of newer SCMI specs like reparenting clocks are not available in upstream SCP-firmware * It was also mentionned that there is already a clock driver available in upstream Linux [3] and a power-domain driver has approved recently [4]. So RPMI already has some traction. > > R is for risc-v. It means it is not cpu neutral platform management > interface as was positioned. It has less features then scmi. We have risc-v > in programmable logic and scmi server for platform management which service > ARM cores too. There is only SMC transport layer which is ARM specific. The > rest is completely soc neutral. I understand that you are building heterogenous systems and that having only one protocol to support will solve lots of problems for you, but that doesn't mean we have to roll back all the progress that was made so far for RPMI. My suggestion is that we stick to what we have in RPMI for the protocols that overlaps with SCMI and have a ratified spec as of now which are: * clocks * power domains * voltages * performance domains * system shutdown/suspend There's however protocols in SCMI that have no RPMI counterpart ratified. Those are: * Reset domain * Pin control (There's an open PR for this [5]) * Sensor management * Telemetry (A PR was closed for this last month [6]) And for these protocols, you should be able to make suggestions and steer the RPMI spec so that it looks more like SCMI so that we can reuse existing drivers in Linux, U-Boot, zephyr, etc. [1]: https://lore.kernel.org/all/[email protected]/ [2]: https://gitlab.arm.com/firmware/SCP-firmware/-/commit/f76402dfefc7557b97aac6226c0b1302e2dc5e12 [3]: https://elixir.bootlin.com/linux/v7.2.9/source/drivers/clk/clk-rpmi.c [4]: https://lore.kernel.org/all/[email protected]/ [5]: https://github.com/riscv-non-isa/riscv-rpmi/pull/163 [6]: https://github.com/riscv-non-isa/riscv-rpmi/pull/162 Thanks, Charles > > I don't know history around it but make no sense to me to introduce it at all. > > Thanks, > Michal
