Qcom 6.18.y SCMI - #1002
Conversation
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 <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Bjorn Andersson <[email protected]> Acked-by: MyungJoo Ham <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Link: https://patchwork.kernel.org/project/linux-pm/patch/[email protected]/ Signed-off-by: Xin Liu <[email protected]>
…ntation Add QCOM System Control Management Interface (SCMI) Generic Vendor Extensions Protocol documentation. Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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 <[email protected]> Signed-off-by: Shivnandan Kumar <[email protected]> Co-developed-by: Ramakrishna Gottimukkula <[email protected]> Signed-off-by: Ramakrishna Gottimukkula <[email protected]> Co-developed-by: Amir Vajid <[email protected]> Signed-off-by: Amir Vajid <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
…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/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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 <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Lukasz Luba <[email protected]> Tested-by: AngeloGioacchino Del Regno <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Rob Herring (Arm) <[email protected]>
4bfebe3 to
0c23099
Compare
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 <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Link: https://patch.msgid.link/14e1c03d443b1a5f210609ec3a1ebbaeab8fb3d9.1772468323.git.geert+renesas@glider.be
Signed-off-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Xin Liu <[email protected]>
Use the of_machine_get_match() helper instead of open-coding the same operation. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Viresh Kumar <[email protected]> Link: https://patch.msgid.link/83ed49314b94dab7781e1d74236af72dd5c349c6.1772468323.git.geert+renesas@glider.be Signed-off-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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 <[email protected]> Signed-off-by: Shivnandan Kumar <[email protected]> Co-developed-by: Ramakrishna Gottimukkula <[email protected]> Signed-off-by: Ramakrishna Gottimukkula <[email protected]> Co-developed-by: Amir Vajid <[email protected]> Signed-off-by: Amir Vajid <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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/[email protected]/ Signed-off-by: Sibi Sankar <[email protected]> Signed-off-by: Xin Liu <[email protected]>
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 <[email protected]>
0c23099 to
c98079e
Compare
PR #1002 — validate-patchPR: #1002
Final Summary
|
PR #1002 — checker-log-analyzerPR: #1002
Detailed report: Full report
|
PR #1002 — validate-patchPR: #1002
Final Summary
|
PR #1002 — checker-log-analyzerPR: #1002
Detailed report: Full report
|
PR #1002 — validate-patchPR: #1002
Final Summary
|
PR #1002 — checker-log-analyzerPR: #1002
Detailed report: Full report
|
The application of SCMI patch on Hamoa, as well as some prerequisite code required for applying SCMI driver
CRs-Fixed: 4559569
Rebase from #652