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

On Fri, Jul 10, 2026 at 10:46:15AM +0200, Michal Simek wrote:
> 
> 
> On 7/10/26 10:38, Sudeep Holla wrote:
> > 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.
> 
> interesting. It looks like that they even didn't try to ARM about it.
> 
> > 
> > > > 
> > > > 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.
> 
> I know that we can't maintain SCMI and RPMI servers running on the same chip
> doing the same things. We don't have space for it and make no sense to
> duplicate testing on it too.
> 

That is very valid and compelling reason to re-use and agree with your
assessment. If you can make it work, go for it 😉.

-- 
Regards,
Sudeep