Skip to content

Qcom 6.18.y SCMI - #1002

Open
LXQUALCOMM wants to merge 13 commits into
qualcomm-linux:qcom-6.18.yfrom
LXQUALCOMM:qcom-6.18.y
Open

Qcom 6.18.y SCMI#1002
LXQUALCOMM wants to merge 13 commits into
qualcomm-linux:qcom-6.18.yfrom
LXQUALCOMM:qcom-6.18.y

Conversation

@LXQUALCOMM

@LXQUALCOMM LXQUALCOMM commented Aug 24, 2026 •
edited
Loading

Copy link
Copy Markdown

The application of SCMI patch on Hamoa, as well as some prerequisite code required for applying SCMI driver

CRs-Fixed: 4559569

Rebase from #652

Dmitry Baryshkov (lumag) and others added 8 commits August 24, 2026 14:09
@lumag @LXQUALCOMM
FROMGIT: PM / devfreq: Move governor.h to a public header location
6df46fd 
Some device drivers (and out-of-tree modules) might want to define
device-specific device governors. Rather than restricting all of them to
be a part of drivers/devfreq/ (which is not possible for out-of-tree
drivers anyway) move governor.h to include/linux/devfreq-governor.h and
update all drivers to use it.

The devfreq_cpu_data is only used internally, by the passive governor,
so it is moved to the driver source rather than being a part of the
public interface.

Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Link: https://patchwork.kernel.org/project/linux-pm/patch/20251030-governor-public-v2-1-432a11a9975a@oss.qualcomm.com/
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: firmware: arm_scmi: Add QCOM Generic Vendor Protocol docume…
61aa22d 
…ntation

Add QCOM System Control Management Interface (SCMI) Generic Vendor
Extensions Protocol documentation.

Link: https://lore.kernel.org/lkml/20260507062237.78051-2-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@cris-ma @LXQUALCOMM
FROMGIT: firmware: arm_scmi: Rework protocol version negotiation logic
e8c6561 
Protocol version negotiation can be used by an agent to request the server
to downgrade the version effectively utilized by a specific protocol
during the current session, if the latest version used by the server is
newer than the latest version known to the client.

In order for the negotiation process to be fully effective at preventing
any possible version incompatibility, it must happen early on, well before
the specific protocol initialization phase takes place.

Delegate protocol version querying to the core SCMI stack and rework the
protocol negotiation logic in order to execute the needed negotiation
exchanges upfront, right before the initialization phase takes place.

Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20251227164132.1311988-2-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: firmware: arm_scmi: vendors: Add QCOM SCMI Generic Extensions
79844e5 
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>
Link: https://lore.kernel.org/lkml/20260507062237.78051-3-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: PM / devfreq: Add new target_freq attribute flag for governors
8778df9 
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.

Link: https://lore.kernel.org/lkml/20260507062237.78051-4-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: PM / devfreq: Add new track_remote flag for governors
6f442d4 
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.

Link: https://lore.kernel.org/lkml/20260507062237.78051-5-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: PM / devfreq: Add a governor for tracking remote device fre…
24d9007 
…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.

Link: https://lore.kernel.org/lkml/20260507062237.78051-6-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@krzk @LXQUALCOMM
UPSTREAM: of: Add wrappers to match root node with OF device ID tables
813b17a 
Several drivers duplicate same code for getting reference to the root
node, matching it against 'struct of_device_id' table and getting out
the match data from the table entry.

There is a of_machine_compatible_match() wrapper but it takes array of
strings, which is not suitable for many drivers since they want the
driver data associated with each compatible.

Add two wrappers, similar to existing of_device_get_match_data():
1. of_machine_device_match() doing only matching against 'struct
   of_device_id' and returning bool.
2. of_machine_get_match_data() doing the matching and returning
   associated driver data for found compatible.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-1-d46b72003fd6@linaro.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
@LXQUALCOMM
LXQUALCOMM force-pushed the qcom-6.18.y branch 3 times, most recently from 4bfebe3 to 0c23099 Compare August 24, 2026 08:48
@geertu @LXQUALCOMM
UPSTREAM: of: Add of_machine_get_match() helper
863c237 
Currently, there are two helpers to match the root compatible value
against an of_device_id array:
  - of_machine_device_match() returns true if a match is found,
  - of_machine_get_match_data() returns the match data if a match is
    found.
However, there is no helper that returns the actual of_device_id
structure corresponding to the match, leading to code duplication in
various drivers.

Fix this by reworking of_machine_device_match() to return the actual
match structure, and renaming it to of_machine_get_match().
Retain the old of_machine_device_match() functionality using a cheap
static inline wrapper around the new of_machine_get_match() helper.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/14e1c03d443b1a5f210609ec3a1ebbaeab8fb3d9.1772468323.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@geertu @LXQUALCOMM
FROMGIT: of: Convert to of_machine_get_match()
98bf838 
Use the of_machine_get_match() helper instead of open-coding the same
operation.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://patch.msgid.link/83ed49314b94dab7781e1d74236af72dd5c349c6.1772468323.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: PM / devfreq: Introduce the QCOM SCMI Memlat devfreq device
ebce65a 
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>
Link: https://lore.kernel.org/lkml/20260507062237.78051-7-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@QuinAsura @LXQUALCOMM
FROMLIST: arm64: dts: qcom: hamoa: Enable LLCC/DDR/DDR_QOS dvfs
49ba4fb 
On Qualcomm Hamoa SoCs, the memlat governor and the mechanism
to control the LLCC and DDR/DDR_QOS is hosted on the CPU Control
Processor (CPUCP). Enable the nodes required to get QCOM SCMI
Generic Extension protocol to probe on Hamoa and Purwa SoCs.

Link: https://lore.kernel.org/lkml/20260507062237.78051-9-sibi.sankar@oss.qualcomm.com/
Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
@LXQUALCOMM
QCLINUX: qcom.config: Enable QCOM SCMI memlat bus scaling
c98079e 
Enable the QCOM SCMI Generic Vendor Extension protocol (=y),
the remote devfreq governor (=y), and the QCOM SCMI memlat devfreq
device driver (=m) for LLCC/DDR/DDR_QOS bus scaling on Glymur
and Hamoa SoCs. SCMI_QCOM_MEMLAT_DEVFREQ follows QCOM_CPUCP_MBOX
at =m since it depends on that mailbox transport.

Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@idlethread Amit Kucheria (idlethread) Awaiting requested review from idlethread idlethread was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@Komal-Bajaj Komal Bajaj (Komal-Bajaj) Awaiting requested review from Komal-Bajaj Komal-Bajaj was automatically assigned from qualcomm-linux/qualcomm-kernel-maint
@mukeshojha-linux Mukesh Ojha (mukeshojha-linux) Awaiting requested review from mukeshojha-linux mukeshojha-linux was automatically assigned from qualcomm-linux/qualcomm-kernel-maint

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@LXQUALCOMM @lumag @QuinAsura @cris-ma @krzk @geertu