arm_scmi: vendors: Qualcomm Generic Vendor Extensions#1081
Open
ppapaniy wants to merge 6 commits intoqualcomm-linux:tech/bsp/devfreqfrom
Open
arm_scmi: vendors: Qualcomm Generic Vendor Extensions#1081ppapaniy wants to merge 6 commits intoqualcomm-linux:tech/bsp/devfreqfrom
ppapaniy wants to merge 6 commits intoqualcomm-linux:tech/bsp/devfreqfrom
Conversation
…ntation Add QCOM System Control Management Interface (SCMI) Generic Vendor Extensions Protocol documentation. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-2-sibi.sankar@oss.qualcomm.com/
The QCOM SCMI Generic Extensions 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. Co-developed-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com> Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com> Co-developed-by: Amir Vajid <avajid@quicinc.com> Signed-off-by: Amir Vajid <avajid@quicinc.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-3-sibi.sankar@oss.qualcomm.com/
Introduce the target_freq attribute flag as a pre-cursor to adding support for devfreq governors who do not explicitly allow for a method to get/set target frequency. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-4-sibi.sankar@oss.qualcomm.com/
Add a new track_remote flag for devfreq governors as a pre-curor to adding the devfreq governors that is responsible for tracking frequency changes on remote devices. This new governor flag provides for a way track the remote device's frequency and keep the trans_stat data updated and skip the frequency update sequency for the device. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-5-sibi.sankar@oss.qualcomm.com/
…quencies On SoCs, where the governor and the mechanism to control the frequency for devices like caches is hosted on the System Control Processor (SCP), there exists a need track the frequency changes in a reliable way and provide ways to tweaking parameters on the remote governor. To address this introduce the new remote devfreq governor that provides for a way to track the frequency changes on remote devices. It uses the newly introduced target_freq attribute flag and track_remote flag to achieve this. Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-6-sibi.sankar@oss.qualcomm.com/
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. Introduce 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. Co-developed-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Signed-off-by: Shivnandan Kumar <quic_kshivnan@quicinc.com> Co-developed-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com> Signed-off-by: Ramakrishna Gottimukkula <quic_rgottimu@quicinc.com> Co-developed-by: Amir Vajid <avajid@quicinc.com> Signed-off-by: Amir Vajid <avajid@quicinc.com> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260507062237.78051-7-sibi.sankar@oss.qualcomm.com/
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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 : To
315000000 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.
Link: https://lore.kernel.org/lkml/20260507062237.78051-2-sibi.sankar@oss.qualcomm.com/