Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5 |
|
#
5dd08ac0 |
| 05-Dec-2023 |
Alexandra Diupina <adiupina@astralinux.ru> |
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
[ Upstream commit c4a5118a3ae1eadc687d84eef9431f9e13eb015c ]
devm_of_clk_add_hw_provider() may return an errno, so add a return va
cpufreq: scmi: process the result of devm_of_clk_add_hw_provider()
[ Upstream commit c4a5118a3ae1eadc687d84eef9431f9e13eb015c ]
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> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17 |
|
#
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_prope
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>
show more ...
|
Revision tags: v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53 |
|
#
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). T
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31 |
|
#
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 an
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>
show more ...
|
Revision tags: v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17 |
|
#
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_
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>
show more ...
|
Revision tags: v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
37f18831 |
| 10-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: Sudee
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>
show more ...
|
#
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
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>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35 |
|
#
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
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>
show more ...
|
Revision tags: v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
eb1d35c6 |
| 16-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/2
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>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18 |
|
#
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 (al
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>
show more ...
|
#
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 hand
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>
show more ...
|
Revision tags: v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
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 acc
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>
show more ...
|
Revision tags: v5.10 |
|
#
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
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>
show more ...
|
#
c250d50f |
| 05-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 c
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>
show more ...
|
#
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_
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>
show more ...
|
#
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/intercon
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>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62 |
|
#
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 cu
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>
show more ...
|
#
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_
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>
show more ...
|
Revision tags: v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47 |
|
#
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 swit
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>
show more ...
|
Revision tags: v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
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 po
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>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10 |
|
#
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
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>
show more ...
|
Revision tags: v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24 |
|
#
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/sc
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>
show more ...
|
Revision tags: v4.19.23, v4.19.22, v4.19.21, v4.19.20 |
|
#
3c429851 |
| 04-Feb-2019 |
Quentin Perret <quentin.perret@arm.com> |
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 obta
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>
show more ...
|
Revision tags: v4.19.19 |
|
#
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 o
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>
show more ...
|