Re: [RFC V6 0/8] arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Sibi Sankar
Date: Thu May 14 2026 - 07:42:01 EST
On 5/13/2026 10:30 PM, Lukasz Luba wrote:
On 5/7/26 07:22, Sibi Sankar wrote:
The QCOM SCMI vendor protocol provides a generic way of exposing a number of
Qualcomm SoC specific features (like memory bus scaling) through a mixture of
pre-determined algorithm strings and param_id pairs hosted on the SCMI
controller. On Qualcomm Glymur and Hamoa SoCs, the memlat governor and the
mechanism to control the various caches and ram is hosted on the CPU Control
Processor (CPUCP) and the method to tweak and start the governor is exposed
through the QCOM SCMI Generic Extension Protocol.
This series introduces the devfreq scmi client driver that uses the memlat
algorithm string hosted on QCOM SCMI Generic Extension Protocol to detect
memory latency workloads and control frequency/level of the various memory
buses (DDR/LLCC/DDR_QOS). The DDR/LLCC/DDR_QOS are modelled as devfreq
devices, with the governor set to remote devfreq governor. This serves as
a way to get a basic insight into the device operation through trans_stat
and provides for ways to further tweak the parameters of the remote
governor.
Transtat data for DDR/LLCC/DDR_QOS is now available in this series:
#cat llcc/trans_stat
From : To315000000 479000000 545000000 725000000 840000000 95900000010900000001211000000 time(ms)
315000000: 0 3 6 6 6 7 0 30 143956
479000000: 2 0 7 1 1 1 0 3 356
545000000: 7 6 0 5 5 0 0 10 1200
725000000: 3 0 5 0 6 1 0 6 2172
840000000: 8 2 3 2 0 4 0 12 1188
959000000: 3 0 1 2 2 0 0 13 272
1090000000: 0 0 0 0 0 0 0 0 0
1211000000: 35 4 11 5 11 8 0 0 21684
Total transition : 253
QCOM SCMI Generic Vendor protocol background:
It was found that a lot of the vendor protocol used internally was
for debug/internal development purposes that would either be super
SoC specific or had to be disabled because of some features being
fused out during production. This lead to a large number of vendor
protocol numbers being quickly consumed and were never released
either. Using a generic vendor protocol with functionality abstracted
behind algorithm strings gave us the flexibility of allowing such
functionality exist during initial development/debugging while
still being able to expose functionality like memlat once they have
matured enough. The param-ids are certainly expected to act as ABI
for algorithms strings like MEMLAT.
Thanks in advance for taking time to review the series.
Hey Lukasz,
Thanks for taking time to review the series!
Based on this description I have a few questions:
1. Why we don't use SCMI notifications for this purpose?
This is an attempt to retrofit firmware, that is already out in the wild running
on X1E laptops and Glymur which continues to use the same firmware, into
generic linux frameworks, so that it provides some useful information to user
rather than it being a complete black box. We already have a ton of firmware
changes suggested by Sudeep/Cristian that will be taken into account for the
next generation of SoCs, will make sure this is accounted for as well :)
2. Is it safe to assume that there was no extra frequency change
during that polling sampling period?
Yup, there is expected to be at most one transition of DDR/LLCC/DDR-QOS
per polling cycle.
3. Shouldn't we sample 2x faster than the changes that we try to
observe?
Yup, that makes sense. Will fix this in the next re-spin.
4. IIRC there was some extension in the SCMI protocol for performance
domains which allows to expose the stats like the one above but in
the shared memory. Why we couldn't use this? It would be more robust.
Same answer as the first point, since the current firmware provides to no
such provisions :(
-Sibi