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

[Michal Simek <michal.simek@amd.com>]

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.

Thanks,
Michal