Re: [RFC PATCH] firmware: scmi: Make SCMI arch independent

On Fri, Jul 10, 2026 at 09:42:09AM +0200, Michal Simek wrote:
> 
> 
> On 7/10/26 09:35, Sudeep Holla wrote:
> > On Fri, Jul 10, 2026 at 09:03:32AM +0200, Michal Simek wrote:
> > > 
> > > 
> > > On 7/9/26 17:56, Cristian Marussi wrote:
> > > > On Thu, Jul 09, 2026 at 03:27:00PM +0200, Michal Simek wrote:
> > > > > On heterogenious systems like AMD/Xilinx FPGA there is a need to talk to
> > > > > SCMI server from different architectures than ARM that's why remove
> > > > > ARM/ARM64 Kconfig dependency with also remove ARM from description and
> > > > > rename folder to reflect it.
> > > > 
> > > > While I understand dropping the dependency on ARM (I always wanted to do
> > > > that and test if it worked at all on some otehr archs with QEMU), I am
> > > > not sure about the whole renaming party ? why is needed just for
> > > > cosmetic reasons ? it is at the end an arm originated protocol so I dont
> > > > see it as a being wrong to be named as such even though used by other
> > > > archs...I have not really strong opinion on this...
> > > 
> > > I have been in CC on U-Boot RPMI patches which got to my attention because
> > > I don't want to have another interface for MB-V(riscv-) running in
> > > programmable logic and have another server in the system doing the same
> > > thing.
> > > 
> > 
> > Ah that's interesting. I wasn't aware of that. I still agree with the move
> > in principle, but how does that align with these:
> > 
> > drivers/clk/clk-rpmi.c
> > drivers/irqchip/irq-riscv-rpmi-sysmsi.c
> > include/linux/mailbox/riscv-rpmi-message.h
> > drivers/mailbox/riscv-sbi-mpxy-mbox.c(Should be fine as it is just transport)
> 
> I am having separate discussion on u-boot mailing list about RPMI and it's
> usage on non riscv architectures because one raised argument was that it is
> community driver spec compare to SCMI which is owned by ARM. But IMHO only
> for riscv.
> 

IIRC in LPC 2024, we did discuss opening up SCMI so that RISCV could use it as
is instead of copying quite a lot from SCMI for RPMI in some closed groups.

Here is the summary we got from couple of RISC-V vendors at the time:
"
RPMI is comparable to Arm SCMI, but it includes RISC-V-specific services such
as HART State Management, CPPC, Management Mode, and RAS Agent. The SBI MPXY
extension enables secure and non-secure system partitions to exchange RPMI
messages, allows an M-mode RPMI transport to be shared with S-mode, and lets
hypervisors virtualize RPMI for guests or VMs.

RPMI development is already well advanced, with much of the client-driver work
implemented in OpenSBI. Supervisor software can access selected RPMI services
through SBI MPXY. A permissively licensed reference implementation, librpmi,
is also available for platform vendors.

RPMI was created after evaluating Arm SCMI, mainly to support RISC-V-specific
requirements.
"

I didn't pursue it any further following some of these followup discussions
post LPC 2024.

> > 
> > Now I feel we need some alignment before making $subject move.
> > 
> > > Based on that we had discussed about it with Vincent and Souvik (we missed
> > > you there) about using SCMI on non ARM platform and both of them didn't see
> > > the concern to be marked as ARM only protocol.
> > > Truth is that some of protocols have ARM in description, file names, etc but
> > > some of them not. That's why I think it is good time to sync it up and
> > > enable
> > > running this protocol on other SOCs.
> > > 
> > > > ... my concern really is ... wont this full scale rename simply generate
> > > > a lot of un-needed churn for future fixes and/or backporting ?
> > > I don't think it is going to be a big problem because it is just git mv
> > > which git is able to gracefully handle.
> > > 
> > 
> > Otherwise it may end up being unnecessary churn though I completely agree
> > with the git/backporting aspects. Just don't want to churn things up until
> > we have some plan and further changes/users of this move.
> 
> As I wrote above AMD/Xilinx platform with SCMI server where ARM RPU/APUs
> (with multiple VMs) and Microblaze-V in programmable logic acting as
> separate agents is going to be the first user. And for being able to run
> SCMI on Linux running on Microblaze-V I need enable SCMI on non ARM
> architecture.
> 

Ah OK, if the plan is to just use SCMI as is and having "ARM/arm" name is
a blocker, then sure we can get that done. Hope you are aware of and already
considered some of the RISC-V specifics listed above and ruled out any of
those as concerns to use SCMI on RISC-V platforms.

-- 
Regards,
Sudeep