Re: [PATCH RFC 01/10] firmware: arm_scmi: Add SCMI QCOM Generic Extension Protocol documentation
From: Sibi Sankar
Date: Wed Aug 19 2026 - 16:00:13 EST
On 8/13/2026 12:48 PM, Sudeep Holla wrote:
On Tue, Aug 04, 2026 at 02:07:28AM +0530, Sibi Sankar wrote:
On 7/24/2026 2:43 PM, Sudeep Holla wrote:While noted, this does not impact the code quality or review process for an
On Fri, Jul 24, 2026 at 12:48:06PM +0530, Pragnesh Papaniya wrote:Hey Sudeep,
Add System Control Management Interface (SCMI) Qualcomm Generic Extension
Protocol documentation. It consists of a small set of generic SET/GET/
START/STOP commands, which is used to turn on/off and configure Qualcomm
SoC specific algorithms that run on the SCP.
It currently only supports MEMLAT (memory latency governor) algorithm.
The immutable pairing of the MEMLAT algorithm string with the supported
param_ids associated with it are documented here.
Co-developed-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
Signed-off-by: Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@xxxxxxxxxxxxxxxx>
---
.../arm_scmi/vendors/qcom/qcom_generic.rst | 954 +++++++++++++++++++++
1 file changed, 954 insertions(+)
diff --git a/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst
new file mode 100644
index 000000000000..42e327d53841
--- /dev/null
+++ b/drivers/firmware/arm_scmi/vendors/qcom/qcom_generic.rst
@@ -0,0 +1,954 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: <isonum.txt>
+
+==================================================================================
+System Control and Management Interface (SCMI) Qualcomm Generic Extension Protocol
+==================================================================================
+
+:Copyright: |copy| Qualcomm Technologies, Inc. and/or its subsidiaries.
+
+:Authors:
+ - Sibi Sankar <sibi.sankar@xxxxxxxxxxxxxxxx>
+ - Pragnesh Papaniya <pragnesh.papaniya@xxxxxxxxxxxxxxxx>
+
+System Control and Management Interface Qualcomm Generic Extension Vendor Protocol
+==================================================================================
+
+System Control Management Interface (SCMI) Qualcomm Generic Extension Protocol
+consists of a small set of generic SET/GET/START/STOP commands, which is used to
+turn on/off and configure Qualcomm SoC specific algorithms that run on the SCP.
+Each algorithm is identified through an algorithm string and has an immutable list
+of param_ids. All supported algorithms (currently just MEMLAT) have their own
+dedicated section and are listed after the generic commands.
+
Will set some context here, this version of the vendor protocol is currently
running in the wild on 5 SoCs (Hamoa, Purwa, Glymur, Mahua, Kaanapali).
entirely new feature. That context would be relevant for a localized fix or
system quirk, but it is not applicable here.
The ABI/Specification that this vendor protocol uses can't be changed inThe current rationale isn't entirely clear to me. Windows historically favors
any way since other Os'es like Windows/Android expect it to behave as
described in this document and will break userspace.
ACPI over native SCMI, meaning that supporting a proprietary vendor protocol
would require non-native workarounds potentially hidden within interfaces like
PEP. I am skeptical of this architectural direction. Since Android leverages
In an ideal world maybe but transition for all SoC capabilities to ACPI is rarely that
smooth and they do use the PEP interface.
the Linux kernel and already manages this through vendor modules, maintaining
those as modules seems like the optimal path until we agree on the interface
that can be merged.
series is meant for the devfreq portion (since it introduces a new devfreqGiven that this patch series has been under discussion for nearly two years,
governor) and is not for the vendor protocol. We certainly can take design
improvements for future revisions but making changes to this major/minor
version of the firmware isn't possible.
please provide a summary of the feedback that has already been incorporated
to address these concerns just for sake of argument and in your defence.
To clarify, the vendor protocol space is strictly intended for
platform-specific functionalities that cannot be standardized; it should not
be used to bypass standardization for convenience. It appears no evaluation
was done to determine if or why the standard performance protocol was
insufficient. Had that assessment occurred, I would expect the proposed
interface to align much more closely with the standard definitions as I
previously mentioned.
The design might seem contrived at the moment but it was still largely shaped
by the SCMI specification. There is a literally a 6-7 year window between SCMI
landing in mainline and the first mention of the vendor protocol identifiers
being re-useable between SoC vendors [1]. This largely shaped how Qualcomm
used vendor protocol. The first instance of vendor protocol was a straight
forward vendor protcol implementing just MEMLAT [2] but the sudden rise in
the number of protocol eating up vendor protocol space made them club
together the class of devfreq algorithms into a singular generic extension
protocol.
"deliberated attempt to circumvent the standard SCMI protocol template"
"expectation of immediate acceptance without modification"
I gather that ^^ are the major objections to the current series landing but
sadly none of these were raised during this 2 year period and this protocol
even had a "Reviewed-by" from the only other reviewer listed [3]. We promised
to fix all the concerns raised [4] in the next major/minor version upgrade [5].
The current version works as is on Hamoa/Purwa/Glymur/Mahua/Kaanapali
maintaining the same ABI (that should count for something) and it would only
need a major/minor version update when a new algorithm string gets added
or a new param-ids gets added. Both of these are yet to happen.
Given that we put out the pseudo code of what the MEMLAT algorithm does
and spent the past several revisions trying to explain why generic perf nor
mpam would work for us we keep getting hit with the blanket "It appears
no evaluation was done to determine if or why the standard performance
protocol was insufficient". The only recommendation I see from your side
is move MEMLAT to it's own protocol. With the documentation/code
available to you can please let us know how current perf protocol or MPAM
can be used as a standin replacement?
[1] - https://lore.kernel.org/lkml/Zag5L9j8-oCebKFm@pluto/
[2] - https://lore.kernel.org/lkml/1667451512-9655-1-git-send-email-quic_sibis@xxxxxxxxxxx/#t
[3] - https://lore.kernel.org/lkml/Zo14-rQ1Jaxh5Idi@pluto/
[4] - https://lore.kernel.org/lkml/Z1GfGk0yQAVQKEVL@pluto/
[5] - https://lore.kernel.org/lkml/55fd0c34-c52c-95c5-5cd0-16fd66a4baa2@xxxxxxxxxxx/
Plenty of folks running linux on these SoCs would benefit a great deal fromThe core issue here is that the proposed vendor protocol interface has been
this series landing, so please have a bit of patience, take a look at the
documentation/series as a whole. I still feel we should be able to land this
series in a form that is acceptable to you. However, if you still feel you
have
to NAK this series regardless of its usefulness to the users, please do list
the
reasons and we'll try our best to convince you otherwise.
presented as a finished product without open discussion or a willingness to
iterate based on upstream feedback. This approach bypasses standard
development processes.
It would be way easier for us to re-design this but it would mean that we are
abandoning the current users stuck with this firmware version and that's the
only reason for trying to land this in a form that is maintainable. Either way
please do take the call to decisively NAK the series (even if it's coming 9
revisions late and at the cost of 2 years). That way we can give up on this
and go about upstreaming using the standard development process.
That said please do consider expanding your reviewer/maintainer count
in a way that gives you the capability to review series from all SoC vendors.
IMO these vendor protocol interfaces must be debated on the mailing list prior
to finalization, similar to the 'code-first' prototyping model used for new
ACPI specifications or SCMI early prototyping. If an interface is developed
in isolation and then submitted with an expectation of immediate acceptance
without modification, we cannot approve it. I recommend we pivot to an open
review of the interface design itself.
This is precisely why I previously suggested defining MEMLAT as its ownThis multiplexer 'N' random algorithn into one single custom SCMI protocol IDOnly the strings documented are allowed by the vendor protocol while the
(0x80) seems to go against the general SCMI design principle and this seems
rest are filtered out, so we clearly don't have to worry about this. Also
grouping a class of devfreq algorithms into a single vendor protocol should
be treated as a SoC vendor design choice.
distinct protocol. Doing so maintains architectural consistency and adheres to
core SCMI principles.
^^^ as mentioned abovelike a deliberated attempt to circumvent the standard SCMI protocol template.
Standard SCMI expects distinct features to occupy their own vendor protocol
IDs and utilize standard protocol discovery.