Documentation/ABI/testing/sysfs-class-devfreq | 8 + .../devicetree/bindings/firmware/arm,scmi.yaml | 1 + .../bindings/firmware/qcom,generic-scmi.yaml | 27 + arch/arm64/boot/dts/qcom/glymur.dtsi | 41 ++ arch/arm64/boot/dts/qcom/hamoa.dtsi | 4 + drivers/devfreq/Kconfig | 21 + drivers/devfreq/Makefile | 2 + drivers/devfreq/devfreq.c | 27 + drivers/devfreq/governor_passive.c | 1 + drivers/devfreq/governor_performance.c | 1 + drivers/devfreq/governor_powersave.c | 1 + drivers/devfreq/governor_remote.c | 73 +++ drivers/devfreq/governor_simpleondemand.c | 1 + drivers/devfreq/governor_userspace.c | 1 + drivers/devfreq/hisi_uncore_freq.c | 1 + drivers/devfreq/scmi-qcom-memlat-cfg.h | 573 ++++++++++++++++++ drivers/devfreq/scmi-qcom-memlat-devfreq.c | 616 ++++++++++++++++++++ drivers/devfreq/tegra30-devfreq.c | 3 +- drivers/firmware/arm_scmi/Kconfig | 1 + drivers/firmware/arm_scmi/Makefile | 1 + drivers/firmware/arm_scmi/vendors/qcom/Kconfig | 15 + drivers/firmware/arm_scmi/vendors/qcom/Makefile | 2 + .../arm_scmi/vendors/qcom/qcom-generic-ext.c | 153 +++++ .../arm_scmi/vendors/qcom/qcom_generic.rst | 647 +++++++++++++++++++++ include/linux/devfreq-governor.h | 8 + include/linux/devfreq.h | 1 + include/linux/scmi_qcom_protocol.h | 37 ++ 27 files changed, 2266 insertions(+), 1 deletion(-)
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 the QCOM SCMI Generic Extension Protocol to detect
memory latency workloads and control frequency/level of the various memory
buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices
using the remote devfreq governor. This provides basic insight into device
operation via trans_stat and lets userspace further tweak the parameters of
the remote governor.
trans_stat data for DDR/LLCC/DDR_QOS is now available with this series:
From : To
315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 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:
A lot of the vendor protocol numbers used internally were for
debug/internal development purposes that were either highly SoC-specific
or had to be disabled because some features were fused out during
production. This led to a large number of vendor protocol numbers being
quickly consumed and never released. Using a single generic vendor
protocol with functionality abstracted behind algorithm strings gives us
the flexibility of letting such functionality exist during initial
development/debugging while still being able to expose mature features
(like MEMLAT) once they have stabilised. The param_ids are expected to
act as ABI for algorithm strings like MEMLAT.
Thanks in advance for taking time to review the series.
Changes in v7:
- Minor bug fixes and documentation improvements based on review feedback.
- Significantly expand the QCOM Generic Vendor Protocol documentation
with a dedicated MEMLAT section covering all param_ids, payloads and
return values [Sudeep, Cristian].
- Move per-SoC event IDs and hardware type identifiers from the driver
into the platform configuration header.
- Poll devfreq at twice the CPUCP sampling rate so every firmware voting
cycle is reliably observed [Lukasz].
- Add a devicetree binding schema for the Qualcomm SCMI vendor
protocol@80 node.
- Link to v6: https://lore.kernel.org/r/20260507062237.78051-1-sibi.sankar@oss.qualcomm.com
Changes in v6:
- Combining vendor protocol and the client and moving it
back into RFC mode.
- Introduce target_freq attr flag and TRACK_REMOTE devfreq
governor flag.
- Add basic remote devfreq governor to give users data like
transtat [Dmitry]
- Drop the current design that relies on manual parsing of
device tree data and move those into SoC specific structs
- Add Glymur/Mahua/Hamoa/Purwa support in the same series.
- Link to v5: https://lore.kernel.org/lkml/20241115011515.1313447-1-quic_sibis@quicinc.com/
Changes in v5:
- Splitting the series into vendor protocol and memlat client.
- Also the move the memlat client implementation back to RFC
due to multiple opens.
- Use common xfer helper to avoid code duplication [Dmitry]
- Update enum documentation without duplicate enum info [Dmitry]
- Update the protol attributes doc with more information. [Cristian]
- Link to v4: https://lore.kernel.org/lkml/20241007061023.1978380-1-quic_sibis@quicinc.com/
Changes in v4:
- Restructure the bindings to mimic IMX [Christian]
- Add documentation for the qcom generic vendor protocol [Christian/Sudeep]
- Pick up Rb tag and fixup/re-order elements of the vendor ops [Christian]
- Follow naming convention and folder structure used by IMX
- Add missing enum in the vendor protocol and fix documentation [Konrad]
- Add missing enum in the scmi memlat driver and fix documentation [Konrad]
- Add checks for max memory and monitor [Shivnandan]
- Fix typo from START_TIMER -> STOP_TIMER [Shivnandan]
- Make populate_physical_mask func to void [Shivnandan]
- Remove unecessary zero set [Shivnandan]
- Use __free(device node) in init_cpufreq-memfreqmap [Christian/Konrad]
- Use sdev->dev.of_node directly [Christian]
- use return dev_err_probe in multiple places [Christian]
- Link to v3: https://lore.kernel.org/lkml/20240702191440.2161623-1-quic_sibis@quicinc.com/
Changes in v3:
- Drop container dvfs memlat container node. [Rob]
- Move scmi-memlat.yaml to protocol level given that a lot of vendors might end up
- using the same protocol number. [Rob]
- Replace qcom,cpulist with the standard "cpus" property. [Rob]
- Fix up compute-type/ipm-ceil required. [Rob]
- Make driver changes to the accommodate bindings changes. [Rob]
- Minor fixups in subjects/coverletter.
- Minor style fixes in dts.
- Link to v2: https://lore.kernel.org/lkml/20240612183031.219906-1-quic_sibis@quicinc.com/
Changes in v2:
- Add missing bindings for the protocol. [Konrad/Dmitry]
- Use alternate bindings. [Dmitry/Konrad]
- Rebase on top of Cristian's "SCMI multiple vendor protocol support" series. [Cristian]
- Add more documentation wherever possible. [Sudeep]
- Replace pr_err/info with it's dev equivalents.
- Mixed tabs and initialization cleanups in the memlat driver. [Konrad]
- Commit message update for the memlat driver. [Dmitry]
- Cleanups/Fixes suggested for the client driver. [Dmitry/Konrad/Cristian]
- Use opp-tables instead of memfreq-tbl. [Dmitry/Konrad]
- Detect physical cpu to deal with variants with reduced cpu count.
- Add support for DDR_QOS mem_type.
- Link to v1: https://lore.kernel.org/lkml/20240117173458.2312669-1-quic_sibis@quicinc.com/
Signed-off-by: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
---
Pragnesh Papaniya (1):
dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
Sibi Sankar (8):
firmware: arm_scmi: Add QCOM Generic Vendor Protocol documentation
firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
PM / devfreq: Add new target_freq attribute flag for governors
PM / devfreq: Add new track_remote flag for governors
PM / devfreq: Add a governor for tracking remote device frequencies
PM / devfreq: Introduce the QCOM SCMI Memlat devfreq driver
arm64: dts: qcom: glymur: Enable LLCC/DDR/DDR_QOS DVFS
arm64: dts: qcom: hamoa: Enable LLCC/DDR/DDR_QOS DVFS
Documentation/ABI/testing/sysfs-class-devfreq | 8 +
.../devicetree/bindings/firmware/arm,scmi.yaml | 1 +
.../bindings/firmware/qcom,generic-scmi.yaml | 27 +
arch/arm64/boot/dts/qcom/glymur.dtsi | 41 ++
arch/arm64/boot/dts/qcom/hamoa.dtsi | 4 +
drivers/devfreq/Kconfig | 21 +
drivers/devfreq/Makefile | 2 +
drivers/devfreq/devfreq.c | 27 +
drivers/devfreq/governor_passive.c | 1 +
drivers/devfreq/governor_performance.c | 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_remote.c | 73 +++
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
drivers/devfreq/hisi_uncore_freq.c | 1 +
drivers/devfreq/scmi-qcom-memlat-cfg.h | 573 ++++++++++++++++++
drivers/devfreq/scmi-qcom-memlat-devfreq.c | 616 ++++++++++++++++++++
drivers/devfreq/tegra30-devfreq.c | 3 +-
drivers/firmware/arm_scmi/Kconfig | 1 +
drivers/firmware/arm_scmi/Makefile | 1 +
drivers/firmware/arm_scmi/vendors/qcom/Kconfig | 15 +
drivers/firmware/arm_scmi/vendors/qcom/Makefile | 2 +
.../arm_scmi/vendors/qcom/qcom-generic-ext.c | 153 +++++
.../arm_scmi/vendors/qcom/qcom_generic.rst | 647 +++++++++++++++++++++
include/linux/devfreq-governor.h | 8 +
include/linux/devfreq.h | 1 +
include/linux/scmi_qcom_protocol.h | 37 ++
27 files changed, 2266 insertions(+), 1 deletion(-)
---
base-commit: 49e02880ec0a8c378e811bc9d85da188d7c6204c
change-id: 20260610-rfc_v7_scmi_memlat-3d3d0c0896d4
Best regards,
--
Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 02:21:27PM +0530, Pragnesh Papaniya 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 the QCOM SCMI Generic Extension Protocol to detect > memory latency workloads and control frequency/level of the various memory > buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices > using the remote devfreq governor. This provides basic insight into device > operation via trans_stat and lets userspace further tweak the parameters of > the remote governor. > > trans_stat data for DDR/LLCC/DDR_QOS is now available with this series: > > From : To > 315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 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: > A lot of the vendor protocol numbers used internally were for > debug/internal development purposes that were either highly SoC-specific > or had to be disabled because some features were fused out during > production. This led to a large number of vendor protocol numbers being > quickly consumed and never released. Using a single generic vendor > protocol with functionality abstracted behind algorithm strings gives us > the flexibility of letting such functionality exist during initial > development/debugging while still being able to expose mature features > (like MEMLAT) once they have stabilised. The param_ids are expected to > act as ABI for algorithm strings like MEMLAT. > 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. -- Regards, Sudeep
On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
> On Wed, Jun 10, 2026 at 02:21:27PM +0530, Pragnesh Papaniya 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 the QCOM SCMI Generic Extension Protocol to detect
>> memory latency workloads and control frequency/level of the various memory
>> buses (DDR/LLCC/DDR_QOS). DDR/LLCC/DDR_QOS are modelled as devfreq devices
>> using the remote devfreq governor. This provides basic insight into device
>> operation via trans_stat and lets userspace further tweak the parameters of
>> the remote governor.
>>
>> trans_stat data for DDR/LLCC/DDR_QOS is now available with this series:
>>
>> From : To
>> 315000000 479000000 545000000 725000000 840000000 959000000 1090000000 1211000000 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:
>> A lot of the vendor protocol numbers used internally were for
>> debug/internal development purposes that were either highly SoC-specific
>> or had to be disabled because some features were fused out during
>> production. This led to a large number of vendor protocol numbers being
>> quickly consumed and never released. Using a single generic vendor
>> protocol with functionality abstracted behind algorithm strings gives us
>> the flexibility of letting such functionality exist during initial
>> development/debugging while still being able to expose mature features
>> (like MEMLAT) once they have stabilised. The param_ids are expected to
>> act as ABI for algorithm strings like MEMLAT.
>>
>
> 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. While MPAM is
not enabled/supported on all hardware (Hamoa). Here's the pseudo-code
for remote governor on CPUCP to help you understand more:
Barebone Memlat Pseudocode:
Every sample window, get snapshot of latest AMU counters from each CPU and scale all the memory according to the map_table:
For each CPU
// Calculate IPM ( Instruction retired / cache miss count (L2 cache refills for LLCC voting and CPU RD miss counter for DDR))
If (IPM < IPM_CEIL)
Use CPU cycle counter to determine CPU frequency in the past N milliseconds
LLCC_freq = lookup_llcc_freq(cpu_freq_max)
DDR_freq = lookup_ddr_freq(cpu_freq_max)
DDR_QOS_freq = lookup_ddr_qos_freq(cpu_freq_max)
// Scale all memories
Scale_freq(Memory); // LLCC/DDR/DDR_QOS
>
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. > While MPAM is not enabled/supported on all hardware (Hamoa). Fair enough but I still don't fully understand to rule that out yet. -- Regards, Sudeep
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. 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? We would like to but all of these are tuneable values, that can change for various boards for the same SoC. The START/STOP operations are meant to start/stop the algorithm, in this case the bus scaling algorithm. 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. 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/ We'll add more call flow diagrams as part of the documentation for the next re-spin to make reviews a bit more easier. -Pragnesh > >> While MPAM is not enabled/supported on all hardware (Hamoa). > > Fair enough but I still don't fully understand to rule that out yet. >
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
On 27-Jun-26 7:43 PM, Sudeep Holla wrote: > 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 ? There are no memlat tunables in DT (We tried to have in device tree in the earlier revisions but they introduced unnecessary complexity). They are in kernel structs (see 7/9), fixed per SoC/board variant and pushed to the SCP exactly once at probe. The driver walks the selected config, sends the event maps, freq maps, tuneables and min/max clamps via SET, and then issues START. Any further SET traffic is limited to a sub-set of tuneables like changing sample_ms, limiting max_freq that the devfreq framework supports. > >> 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. Thanks, will add a filter that just accepts valid strings in the next re-spin. > >> 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. Ack Thanks, Pragnesh > >> 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. >
© 2016 - 2026 Red Hat, Inc.