Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions

[Sudeep Holla]

On Thu, Jun 25, 2026 at 10:57:40AM +0530, Pragnesh Papaniya wrote:
> 
> 
> On 23-Jun-26 2:17 PM, Sudeep Holla wrote:
> > On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote:
> >>
> >> On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
> >>
> >>> Not sure if it was discussed in the previous versions or not, it would be
> >>> good if you can capture why some of bus scaling doesn't work with the existing
> >>> SCMI performance protocol and the monitors don't fit the MPAM mode.
> >>>
> >>> Please capture them in 1/9 as a motivation for this vendor protocol. It will
> >>> then help to understand it better as I am still struggling to. Sorry for that.
> >>
> >> Thanks for the input!
> >>
> >> SCMI perf protocol exports perf domains to kernel where kernel can set
> >> the frequency but here the scaling governor runs on the SCP while kernel
> >> just observes frequency changes made by remote governor.
> > 
> > OK if it is sort of read-only w.r.t kernel, why not perf domain notifications
> > work to consume the change done by the SCMI platform.
> > 
> > And why do you have set operations in the vendor protocol being proposed then.
> > It all looks like something just cooked up to make things work. I need
> > detailed reasoning as why the existing perf protocol can't work considering
> > all the existing notifications in place.
> 
> Please do take another look at the documentation and driver changes to see
> how it all comes together, since it's apparent that we use SET operation for
> a ton of things. Taking another stab at explaining how the MEMLAT uses all
> the ops exposed by the vendor protocol.
> 

Sure I will have a look at the documentation again and sorry if I missed
anything. But in general I would expect the document to be self-explanatory
and not having to look at the driver on how it is used to understand the
firmware interface. Please make sure of that if not already.

> We use the SET operation to pass on various tuneables (IPM CEIL, stall floors,
> write-back filter, freq-scale params, adaptive low/high freq, sample ms),
> the core-freq -> mem-freq map, and min/max clamps) required to run the
> MEMLAT algorithm on the SCP. You might ask why can't we have these values
> stored somewhere on the SCP itself?

Exactly, thanks for saving a round trip.

> We would like to but all of these are tuneable values, that can change for
> various boards for the same SoC.
> 

Sure and where do these boards get these values from ? I assume device tree ?
If so, are the fixed and can be done once at boot ?

> The START/STOP operations are meant to start/stop the algorithm, in this case
> the bus scaling algorithm.
> 

Yes you need to add more details on that algorithm. Can firmware take random
strings as input. I guess not. Please list the valid strings and explain them.
Filter invalid strings in the driver if only handful of values are valid.

> We use the GET operation to get the current frequency of memory that we
> are trying to scale. It can be also used to read back all the parameters
> that we are trying to set. Another thing to note is that exposing the current
> frequency to the userspace was something that the community wanted.
> 

More fun, user ABI involved, so the firmware interface needs to be as clear
as possible.

> With all of ^^ in mind, re-using the perf protocol becomes impossible.
> 
> https://lore.kernel.org/lkml/k4lpzxtrq3x6riyv6etxiobn7nbpczf2bp3m4oc752nhjknlit@uo53kbppzim7/
> https://lore.kernel.org/lkml/20241115003809epcms1p518df149458f3023d33ec6d87a315e8f6@epcms1p5/
> 

It is good to capture summary of these old discussions if they are relevant.

> We'll add more call flow diagrams as part of the documentation for the next
> re-spin to make reviews a bit more easier.
> 

Anything that improves and helps in understanding this is always welcome.

-- 
Regards,
Sudeep