#
a8e949d4 |
|
12-Mar-2024 |
Sibi Sankar <quic_sibis@quicinc.com> |
cpufreq: scmi: Enable boost support Certain platforms host a number of higher OPPs that are exclusive to CPUs within specific CPUfreq policies and not all CPUs within that CPUfreq policy are able to achieve those higher OPPs due to power constraints. These OPPs are marked as turbo in the freq_table and in the presence of such OPPs, let's enable boost by default. Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
ad2a9108 |
|
22-Feb-2024 |
Pierre Gondois <pierre.gondois@arm.com> |
cpufreq: scmi: Set transition_delay_us Make use of the newly added callbacks: - rate_limit_get() - fast_switch_rate_limit() to populate policies's `transition_delay_us`, defined as the 'Preferred average time interval between consecutive invocations of the driver to set the frequency for this policy.' Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
c4a5118a |
|
05-Dec-2023 |
Alexandra Diupina <adiupina@astralinux.ru> |
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider() devm_of_clk_add_hw_provider() may return an errno, so add a return value check Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider") Signed-off-by: Alexandra Diupina <adiupina@astralinux.ru> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
92b2028b |
|
25-Aug-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
cpufreq: scmi: Add support to parse domain-id using #power-domain-cells The performance domain-id can be described in DT using the power-domains property or the clock property. The latter is already supported, so let's add support for the power-domains too. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-12-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
4f1f0bc8 |
|
25-Aug-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
cpufreq: scmi: Avoid one OF parsing in scmi_get_sharing_cpus() The domain-id for the cpu_dev has already been parsed at the point when scmi_get_sharing_cpus() is getting called. Let's pass it as an in-parameter to avoid the unnecessary OF parsing. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-7-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
39dfa5b9 |
|
25-Aug-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
firmware: arm_scmi: Align perf ops to use domain-id as in-parameter Most scmi_perf_proto_ops are already using an "u32 domain" as an in-parameter to indicate what performance domain we shall operate upon. However, some of the ops are using a "struct device *dev", which means that an additional OF parsing is needed each time the perf ops gets called, to find the corresponding domain-id. To avoid the above, but also to make the code more consistent, let's replace the in-parameter "struct device *dev" with an "u32 domain". Note that, this requires us to make some corresponding changes to the scmi cpufreq driver, so let's do that too. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-5-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
e336baa4 |
|
25-Aug-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
cpufreq: scmi: Prepare to move OF parsing of domain-id to cpufreq The OF parsing of the clock domain specifier seems to better belong in the scmi cpufreq driver, rather than being implemented behind the generic ->device_domain_id() perf protocol ops. To prepare to remove the ->device_domain_id() ops, let's implement the OF parsing in the scmi cpufreq driver instead. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20230825112633.236607-4-ulf.hansson@linaro.org Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
b8f3a396 |
|
10-Mar-2023 |
Rob Herring <robh@kernel.org> |
cpufreq: Use of_property_present() for testing DT property presence It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
f3ac888f |
|
07-Jul-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
cpufreq: scmi: Support the power scale in micro-Watts in SCMI v3.1 The SCMI v3.1 adds support for power values in micro-Watts. They are not always in milli-Watts anymore (ignoring the bogo-Watts). Thus, the power must be converted conditionally before sending to Energy Model. Add the logic which handles the needed checks and conversions. Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
ae6ccaa6 |
|
07-Jul-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
PM: EM: convert power field to micro-Watts precision and align drivers The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen. Update all EM users which access 'power' field and assume the value is in milli-Watts. Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher. Example calculation which shows the rounding error and impact: power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18 power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21 max_freq = 2000MHz cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000 cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203 The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue. Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
75a3a99a |
|
21-Mar-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
PM: EM: Change the order of arguments in the .active_power() callback The .active_power() callback passes the device pointer when it's called. Aligned with a convetion present in other subsystems and pass the 'dev' as a first argument. It looks more cleaner. Adjust all affected drivers which implement that API callback. Suggested-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
b48cd0d1 |
|
23-Jan-2022 |
Yury Norov <yury.norov@gmail.com> |
cpufreq: replace cpumask_weight with cpumask_empty where appropriate drivers/cpufreq calls cpumask_weight() to check if any bit of a given cpumask is set. We can do it more efficiently with cpumask_empty() because cpumask_empty() stops traversing the cpumask as soon as it finds first set bit, while cpumask_weight() counts all bits unconditionally. Signed-off-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> (for SCMI cpufreq driver) Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
37f18831 |
|
09-Aug-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: scmi: Use .register_em() to register with energy model Set the newly added .register_em() callback to register with the EM after the cpufreq policy is properly initialized. Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
f7d63588 |
|
03-Aug-2021 |
Lukasz Luba <lukasz.luba@arm.com> |
cpufreq: arm_scmi: Fix error path when allocation failed Stop the initialization when cpumask allocation failed and return an error. Fixes: 80a064dbd556 ("scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
b791c7f9 |
|
06-May-2021 |
Christophe JAILLET <christophe.jaillet@wanadoo.fr> |
cpufreq: scmi: Fix an error message 'ret' is known to be 0 here. The last error code is stored in 'nr_opp', so use it in the error message. Fixes: 71a37cd6a59d ("scmi-cpufreq: Remove deferred probe") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
eb1d35c6 |
|
15-Mar-2021 |
Cristian Marussi <cristian.marussi@arm.com> |
cpufreq: scmi: Port driver to the new scmi_perf_proto_ops interface Port driver to the new SCMI perf interface based on protocol handles and common devm_get_ops(). Link: https://lore.kernel.org/r/20210316124903.35011-13-cristian.marussi@arm.com Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
80a064db |
|
18-Feb-2021 |
Nicola Mazzucato <nicola.mazzucato@arm.com> |
scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM By design, SCMI performance domains define the granularity of performance controls, they do not describe any underlying hardware dependencies (although they may match in many cases). It is therefore possible to have some platforms where hardware may have the ability to control CPU performance at different granularity and choose to describe fine-grained performance control through SCMI. In such situations, the energy model would be provided with inaccurate information based on controls, while it still needs to know the performance boundaries. To restore correct functionality, retrieve information of CPUs under the same performance domain from operating-points-v2 in DT, and pass it on to EM. Link: https://lore.kernel.org/r/20210218222326.15788-3-nicola.mazzucato@arm.com Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
71a37cd6 |
|
18-Feb-2021 |
Nicola Mazzucato <nicola.mazzucato@arm.com> |
scmi-cpufreq: Remove deferred probe The current implementation of the scmi_cpufreq_init() function returns -EPROBE_DEFER when the OPP table is not populated. In practice the cpufreq core cannot handle this error code. Therefore, fix the return value and clarify the error message. Link: https://lore.kernel.org/r/20210218222326.15788-2-nicola.mazzucato@arm.com Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
5ae4a4b4 |
|
01-Feb-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: Remove CPUFREQ_STICKY flag During cpufreq driver's registration, if the ->init() callback for all the CPUs fail then there is not much point in keeping the driver around as it will only account for more of unnecessary noise, for example cpufreq core will try to suspend/resume the driver which never got registered properly. The removal of such a driver is avoided if the driver carries the CPUFREQ_STICKY flag. This was added way back [1] in 2004 and perhaps no one should ever need it now. A lot of drivers do set this flag, probably because they just copied it from other drivers. This was added earlier for some platforms [2] because their cpufreq drivers were getting registered before the CPUs were registered with subsys framework. And hence they used to fail. The same isn't true anymore though. The current code flow in the kernel is: start_kernel() -> kernel_init() -> kernel_init_freeable() -> do_basic_setup() -> driver_init() -> cpu_dev_init() -> subsys_system_register() //For CPUs -> do_initcalls() -> cpufreq_register_driver() Clearly, the CPUs will always get registered with subsys framework before any cpufreq driver can get probed. Remove the flag and update the relevant drivers. Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/include/linux/cpufreq.h?id=7cc9f0d9a1ab04cedc60d64fd8dcf7df224a3b4d # [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/arm/mach-sa1100/cpu-sa1100.c?id=f59d3bbe35f6268d729f51be82af8325d62f20f5 # [2] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
f9b0498d |
|
24-Nov-2020 |
Lukasz Luba <lukasz.luba@arm.com> |
cpufreq: arm_scmi: Discover the power scale in performance protocol Add mechanism to discover the power scale present in the performance protocol for all domains. Provide this information to Energy Model, which then can be checked in other frameworks, e.g. thermal. Suggested-by: Morten Rasmussen <morten.rasmussen@arm.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
f943849f |
|
20-Nov-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: scmi: Fix build for !CONFIG_COMMON_CLK Commit 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider") registers a dummy clock provider using devm_of_clk_add_hw_provider. These *_hw_provider functions are defined only when CONFIG_COMMON_CLK=y. One possible fix is to add the Kconfig dependency, but since we plan to move away from the clock dependency for scmi cpufreq, it is preferrable to avoid that. Let us just conditionally compile out the offending call to devm_of_clk_add_hw_provider. It also uses the variable 'dev' outside of the #ifdef block to avoid build warning. Fixes: 8410e7f3b31e ("cpufreq: scmi: Fix OPP addition failure with a dummy clock provider") Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
8410e7f3 |
|
10-Nov-2020 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: scmi: Fix OPP addition failure with a dummy clock provider Commit dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER") handles -EPROBE_DEFER for the clock/interconnects within _allocate_opp_table() which is called from dev_pm_opp_add and it now propagates the error back to the caller. SCMI performance domain re-used clock bindings to keep it simple. However with the above mentioned change, if clock property is present in a device node, opps fails to get added with below errors until clk_get succeeds. cpu0: failed to add opp 450000000Hz cpu0: failed to add opps to the device ....(errors on cpu1-cpu4) cpu5: failed to add opp 450000000Hz cpu5: failed to add opps to the device So, in order to fix the issue, we need to register dummy clock provider. With the dummy clock provider, clk_get returns NULL(no errors!), then opp core proceeds to add OPPs for the CPUs. Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Fixes: dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
c250d50f |
|
04-Nov-2020 |
Lukasz Luba <lukasz.luba@arm.com> |
PM: EM: Add a flag indicating units of power values in Energy Model There are different platforms and devices which might use different scale for the power values. Kernel sub-systems might need to check if all Energy Model (EM) devices are using the same scale. Address that issue and store the information inside EM for each device. Thanks to that they can be easily compared and proper action triggered. Suggested-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Quentin Perret <qperret@google.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1a0419b0 |
|
01-Sep-2020 |
Ionela Voinescu <ionela.voinescu@arm.com> |
cpufreq: move invariance setter calls in cpufreq core To properly scale its per-entity load-tracking signals, the task scheduler needs to be given a frequency scale factor, i.e. some image of the current frequency the CPU is running at. Currently, this scale can be computed either by using counters (APERF/MPERF on x86, AMU on arm64), or by piggy-backing on the frequency selection done by cpufreq. For the latter, drivers have to explicitly set the scale factor themselves, despite it being purely boiler-plate code: the required information depends entirely on the kind of frequency switch callback implemented by the driver, i.e. either of: target_index(), target(), fast_switch() and setpolicy(). The fitness of those callbacks with regard to driving the Frequency Invariance Engine (FIE) is studied below: target_index() ============== Documentation states that the chosen frequency "must be determined by freq_table[index].frequency". It isn't clear if it *has* to be that frequency, or if it can use that frequency value to do some computation that ultimately leads to a different frequency selection. All drivers go for the former, while the vexpress-spc-cpufreq has an atypical implementation which is handled separately. Therefore, the hook works on the assumption the core can use freq_table[index].frequency. target() ======= This has been flagged as deprecated since: commit 9c0ebcf78fde ("cpufreq: Implement light weight ->target_index() routine") It also doesn't have that many users: gx-suspmod.c:439: .target = cpufreq_gx_target, s3c24xx-cpufreq.c:428: .target = s3c_cpufreq_target, intel_pstate.c:2528: .target = intel_cpufreq_target, cppc_cpufreq.c:401: .target = cppc_cpufreq_set_target, cpufreq-nforce2.c:371: .target = nforce2_target, sh-cpufreq.c:163: .target = sh_cpufreq_target, pcc-cpufreq.c:573: .target = pcc_cpufreq_target, Similarly to the path taken for target_index() calls in the cpufreq core during a frequency change, all of the drivers above will mark the end of a frequency change by a call to cpufreq_freq_transition_end(). Therefore, cpufreq_freq_transition_end() can be used as the location for the arch_set_freq_scale() call to potentially inform the scheduler of the frequency change. This change maintains the previous functionality for the drivers that implement the target_index() callback, while also adding support for the few drivers that implement the deprecated target() callback. fast_switch() ============= This callback *has* to return the frequency that was selected. setpolicy() =========== This callback does not have any designated way of informing what was the end choice. But there are only two drivers using setpolicy(), and none of them have current FIE support: drivers/cpufreq/longrun.c:281: .setpolicy = longrun_set_policy, drivers/cpufreq/intel_pstate.c:2215: .setpolicy = intel_pstate_set_policy, The intel_pstate is known to use counter-driven frequency invariance. Conclusion ========== Given that the significant majority of current FIE enabled drivers use callbacks that lend themselves to triggering the setting of the FIE scale factor in a generic way, move the invariance setter calls to cpufreq core. As a result of setting the frequency scale factor in cpufreq core, after callbacks that lend themselves to trigger it, remove this functionality from the driver side. To be noted that despite marking a successful frequency change, many cpufreq drivers will consider the new frequency as the requested frequency, although this is might not be the one granted by the hardware. Therefore, the call to arch_set_freq_scale() is a "best effort" one, and it is up to the architecture if the new frequency is used in the new frequency scale factor setting (determined by the implementation of arch_set_freq_scale()) or eventually used by the scheduler (determined by the implementation of arch_scale_freq_capacity()). The architecture is in a better position to decide if it has better methods to obtain more accurate information regarding the current frequency and use that information instead (for example, the use of counters). Also, the implementation to arch_set_freq_scale() will now have to handle error conditions (current frequency == 0) in order to prevent the overhead in cpufreq core when the default arch_set_freq_scale() implementation is used. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Suggested-by: Valentin Schneider <valentin.schneider@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
69ecb323 |
|
06-Sep-2020 |
Rikard Falkeborn <rikard.falkeborn@gmail.com> |
cpufreq: arm_scmi: Constify scmi_perf_ops pointers The perf_ops are not modified through this pointer. Make them const to indicate that. This is in preparation to make the scmi-ops pointers in scmi_handle const. Link: https://lore.kernel.org/r/20200906230452.33410-2-rikard.falkeborn@gmail.com Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
fb357127 |
|
17-Jun-2020 |
Nicola Mazzucato <nicola.mazzucato@arm.com> |
cpufreq: arm_scmi: Set fast_switch_possible conditionally Currently the fast_switch_possible flag is set unconditionally to true. Based on this, schedutil does not create a thread for frequency switching and would always use the fast switch path. However, if the platform does not support SCMI fast channel, we use polling mode for SCMI message transfer. This may be possible only if there is dedicated channel for DVFS and all operations are in polling mode. Update this by retrieving the fast_switch capability based on the presence of fast channels in SCMI platform firmware. Link: https://lore.kernel.org/r/20200617094332.8391-2-nicola.mazzucato@arm.com Suggested-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d0351cc3 |
|
27-May-2020 |
Lukasz Luba <lukasz.luba@arm.com> |
PM / EM: update callback structure and add device pointer The Energy Model framework is going to support devices other that CPUs. In order to make this happen change the callback function and add pointer to a device as an argument. Update the related users to use new function and new callback from the Energy Model. Acked-by: Quentin Perret <qperret@google.com> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
12b76626 |
|
06-Nov-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: scmi: Match scmi device by both name and protocol id The scmi bus now has support to match the driver with devices not only based on their protocol id but also based on their device name if one is available. This was added to cater the need to support multiple devices and drivers for the same protocol. Let us add the name "cpufreq" to scmi_device_id table in the driver so that in matches only with device with the same name and protocol id SCMI_PROTOCOL_PERF. This will help to add "devfreq" device/driver. Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
8cbd468b |
|
16-Feb-2019 |
Yangtao Li <tiny.windzz@gmail.com> |
cpufreq: scmi: Fix use-after-free in scmi_cpufreq_exit() This issue was detected with the help of Coccinelle. So change the order of function calls to fix it. Fixes: 1690d8bb91e37 (cpufreq: scpi/scmi: Fix freeing of dynamic OPPs) Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
3c429851 |
|
04-Feb-2019 |
Quentin Perret <qperret@qperret.net> |
cpufreq: scmi: Register an Energy Model The Energy Model (EM) framework provides an API to register the active power of CPUs. Call this API from the scmi-cpufreq driver by using the power costs obtained from firmware. This is done to ensure interested subsystems (the task scheduler, for example) can make use of the EM when available. Signed-off-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
|
#
5da7af9a |
|
28-Jan-2019 |
Amit Kucheria <amit.kucheria@linaro.org> |
cpufreq: scmi: Use auto-registration of thermal cooling device Use the CPUFREQ_IS_COOLING_DEV flag to allow cpufreq core to automatically register as a thermal cooling device. This allows removal of boiler plate code from the driver. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
0e141d1c |
|
09-Jan-2019 |
Quentin Perret <qperret@qperret.net> |
cpufreq: scmi: Fix frequency invariance in slow path The scmi-cpufreq driver calls the arch_set_freq_scale() callback on frequency changes to provide scale-invariant load-tracking signals to the scheduler. However, in the slow path, it does so while specifying the current and max frequencies in different units, hence resulting in a broken freq_scale factor. Fix this by passing all frequencies in KHz, as stored in the CPUFreq frequency table. Fixes: 99d6bdf33877 (cpufreq: add support for CPU DVFS based on SCMI message protocol) Signed-off-by: Quentin Perret <quentin.perret@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Cc: 4.17+ <stable@vger.kernel.org> # v4.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
1690d8bb |
|
04-Jan-2019 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: scpi/scmi: Fix freeing of dynamic OPPs Since the commit 2a4eb7358aba "OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()", dynamically created OPP aren't automatically removed anymore by dev_pm_opp_cpumask_remove_table(). This affects the scpi and scmi cpufreq drivers which no longer free OPPs on failures or on invocations of the policy->exit() callback. Create a generic OPP helper dev_pm_opp_remove_all_dynamic() which can be called from these drivers instead of dev_pm_opp_cpumask_remove_table(). In dev_pm_opp_remove_all_dynamic(), we need to make sure that the opp_list isn't getting accessed simultaneously from other parts of the OPP core while the helper is freeing dynamic OPPs, i.e. we can't drop the opp_table->lock while traversing through the OPP list. And to accomplish that, this patch also creates _opp_kref_release_unlocked() which can be called from this new helper with the opp_table lock already held. Cc: 4.20 <stable@vger.kernel.org> # v4.20 Reported-by: Valentin Schneider <valentin.schneider@arm.com> Fixes: 2a4eb7358aba "OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()" Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Valentin Schneider <valentin.schneider@arm.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
7859e08c |
|
09-May-2018 |
Sudeep Holla <sudeep.holla@arm.com> |
firmware: arm_scmi: rename get_transition_latency and add_opps_to_device Most of the scmi code follows the suggestion from Greg KH on a totally different thread[0] to have the subsystem name first, followed by the noun and finally the verb with couple of these exceptions. This patch fixes them so that all the functions names are aligned to that practice. [0] https://www.spinics.net/lists/arm-kernel/msg583673.html Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
d983af98 |
|
03-Apr-2018 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: SCMI: Don't validate the frequency table twice The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from SCMI driver. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
#
02f208c5 |
|
20-Jul-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: scmi: add support for fast frequency switching The cpufreq core provides option for drivers to implement fast_switch callback which is invoked for frequency switching from interrupt context. This patch adds support for fast_switch callback in SCMI cpufreq driver by making use of polling based SCMI transfer. It also sets the flag fast_switch_possible. Cc: linux-pm@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|
#
99d6bdf3 |
|
18-Jun-2017 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: add support for CPU DVFS based on SCMI message protocol On some ARM based systems, a separate Cortex-M based System Control Processor(SCP) provides the overall power, clock, reset and system control including CPU DVFS. SCMI Message Protocol is used to communicate with the SCP. This patch adds a cpufreq driver for such systems using SCMI interface to drive CPU DVFS. Cc: linux-pm@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
|