Qcom 6.18.y SCMI #652
Conversation
|
Merge Check Failed: CR Not Eligible for Merge CR 4559569 is not eligible for merge. The parent software image for kernel.qli.2.0 is not development complete. Entity: Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations. |
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>
…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>
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>
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>
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>
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>
…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>
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> Signed-off-by: Xin Liu <xin.liu@oss.qualcomm.com>
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>
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>
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>
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>
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. Link: https://lore.kernel.org/lkml/20260507062237.78051-1-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>
PR #652 — validate-patchPR: #652
Final Summary
|
PR #652 — checker-log-analyzerPR: #652
Detailed report: Full report
|
Test Matrix
|
The application of SCMI patch on Hamoa, as well as some prerequisite code required for applying SCMI driver
CRs-Fixed: 4559569