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, 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 |
|
#
9ffb053d |
| 12-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
cpufreq: vexpress: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do e
cpufreq: vexpress: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
a70eb93a |
| 14-Jul-2023 |
Rob Herring <robh@kernel.org> |
cpufreq: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that
cpufreq: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
Revision tags: 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, 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, 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, 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, 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 |
|
#
45b2bb66 |
| 09-Sep-2021 |
Guenter Roeck <linux@roeck-us.net> |
cpufreq: vexpress: Drop unused variable
arm:allmodconfig fails to build with the following error.
drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster'
Remove th
cpufreq: vexpress: Drop unused variable
arm:allmodconfig fails to build with the following error.
drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster'
Remove the unused variable.
Fixes: bb8c26d9387f ("cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag") Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
b60cee5b |
| 09-Sep-2021 |
Guenter Roeck <linux@roeck-us.net> |
cpufreq: vexpress: Drop unused variable
arm:allmodconfig fails to build with the following error.
drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster'
Remove
cpufreq: vexpress: Drop unused variable
arm:allmodconfig fails to build with the following error.
drivers/cpufreq/vexpress-spc-cpufreq.c:454:13: error: unused variable 'cur_cluster'
Remove the unused variable.
Fixes: bb8c26d9387f ("cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag") Cc: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60 |
|
#
3fd23111 |
| 10-Aug-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: vexpress: Use .register_em() to register with energy model
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core.
Acked-by: Sudeep Ho
cpufreq: vexpress: Use .register_em() to register with energy model
Set the newly added .register_em() callback with cpufreq_register_em_with_opp() to register with the EM core.
Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
bb8c26d9 |
| 10-Aug-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag
Reuse the cpufreq core's registration of cooling device by setting the CPUFREQ_IS_COOLING_DEV flag. Set this only if bL switcher isn't enabled.
Si
cpufreq: vexpress: Set CPUFREQ_IS_COOLING_DEV flag
Reuse the cpufreq core's registration of cooling device by setting the CPUFREQ_IS_COOLING_DEV flag. Set this only if bL switcher isn't enabled.
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, 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, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, 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 |
|
#
d1518399 |
| 03-Nov-2020 |
Pali Rohár <pali@kernel.org> |
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module.
Signed-off-by: Pali Rohá
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module.
Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 47ac9aa165540 ("cpufreq: arm_big_little: add vexpress SPC interface driver") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
d62b3d14 |
| 03-Nov-2020 |
Pali Rohár <pali@kernel.org> |
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
[ Upstream commit d15183991c2d53d7cecf27a1555c91b702cef1ea ]
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when i
cpufreq: vexpress-spc: Add missing MODULE_ALIAS
[ Upstream commit d15183991c2d53d7cecf27a1555c91b702cef1ea ]
This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module.
Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 47ac9aa165540 ("cpufreq: arm_big_little: add vexpress SPC interface driver") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.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 ...
|
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, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
0e0ffa85 |
| 27-May-2020 |
Lukasz Luba <lukasz.luba@arm.com> |
OPP: refactor dev_pm_opp_of_register_em() and update related drivers
The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add
OPP: refactor dev_pm_opp_of_register_em() and update related drivers
The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem.
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> 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 |
|
#
c9385887 |
| 27-Nov-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: Switch cpumask from topology core to OPP sharing
Since commit ca74b316df96 ("arm: Use common cpu_topology structure and functions.") the core cpumask has to be modified during
cpufreq: vexpress-spc: Switch cpumask from topology core to OPP sharing
Since commit ca74b316df96 ("arm: Use common cpu_topology structure and functions.") the core cpumask has to be modified during cpu hotplug operations. So using them to set up cpufreq policy cpumask may be incorrect as it may contain only cpus that are online at that instance.
Instead, we can use the cpumask setup by OPP library that contains all the cpus sharing OPP table using dev_pm_opp_get_sharing_cpus.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
show more ...
|
Revision tags: v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8 |
|
#
e32beb06 |
| 23-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: find and skip duplicates when merging frequencies
Currently the cpufreq core aborts the validation and return error immediately when it encounter duplicate frequency table ent
cpufreq: vexpress-spc: find and skip duplicates when merging frequencies
Currently the cpufreq core aborts the validation and return error immediately when it encounter duplicate frequency table entries. This change was introduced long back since commit da0c6dc00c69 ("cpufreq: Handle sorted frequency tables more efficiently").
However, this missed the testing with modified firmware for long time. Inorder to make it work with default settings, we need to ensure the merged table for bL switcher contains no duplicates. Find the duplicates and skip them when merging the frequenct tables of A15 and A7 clusters.
Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
4a6e1352 |
| 23-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: use macros instead of hardcoded values for cluster ids
A15 and A7 cluster identifiers are fixed to 0 and 1 respectively. There are macros for the same and used in most of the
cpufreq: vexpress-spc: use macros instead of hardcoded values for cluster ids
A15 and A7 cluster identifiers are fixed to 0 and 1 respectively. There are macros for the same and used in most of the places except this instance.
Lets use macros instead of hardcoded values for cluster ids even here.
Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
e318d2c8 |
| 18-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: fix some coding style issues
Fix the following checkpatch checks/warnings:
CHECK: Unnecessary parentheses around the code CHECK: Alignment should match open parenthesis CHECK
cpufreq: vexpress-spc: fix some coding style issues
Fix the following checkpatch checks/warnings:
CHECK: Unnecessary parentheses around the code CHECK: Alignment should match open parenthesis CHECK: Prefer kernel type 'u32' over 'uint32_t' WARNING: Missing a blank line after declarations
Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
09402d57 |
| 18-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: remove lots of debug messages
This driver have been used and tested for year now and the extensive debug/log messages in the driver are not really required anymore. Get rid of
cpufreq: vexpress-spc: remove lots of debug messages
This driver have been used and tested for year now and the extensive debug/log messages in the driver are not really required anymore. Get rid of those unnecessary log messages.
Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
1f1b4650 |
| 18-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: vexpress-spc: drop unnessary cpufreq_arm_bL_ops abstraction
cpufreq_arm_bL_ops is no longer needed after merging the generic arm_big_little and vexpress-spc driver. Remove it along with the
cpufreq: vexpress-spc: drop unnessary cpufreq_arm_bL_ops abstraction
cpufreq_arm_bL_ops is no longer needed after merging the generic arm_big_little and vexpress-spc driver. Remove it along with the unused bL_cpufreq_{,un}register routines and rename some bL_* functions to ve_spc_*.
Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
a0f950d3 |
| 21-Oct-2019 |
Sudeep Holla <sudeep.holla@arm.com> |
cpufreq: merge arm_big_little and vexpress-spc
arm_big_little cpufreq driver was designed as a generic big little driver that could be used by any platform and make use of bL switcher. Over years al
cpufreq: merge arm_big_little and vexpress-spc
arm_big_little cpufreq driver was designed as a generic big little driver that could be used by any platform and make use of bL switcher. Over years alternate solutions have been designed and merged to deal with bL/HMP systems like EAS.
Also since no other driver made use of generic arm_big_little cpufreq driver except Vexpress SPC, we can merge them together as vexpress-spc driver used only on Vexpress TC2(CA15_CA7) platform.
Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
Revision tags: 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, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14 |
|
#
0011c6da |
| 19-Oct-2017 |
Bhumika Goyal <bhumirks@gmail.com> |
cpufreq: arm_big_little: make cpufreq_arm_bL_ops structures const
Make these const as they are only getting passed to the functions bL_cpufreq_{register/unregister} having the arguments as const.
S
cpufreq: arm_big_little: make cpufreq_arm_bL_ops structures const
Make these const as they are only getting passed to the functions bL_cpufreq_{register/unregister} having the arguments as const.
Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9 |
|
#
d9975b0b |
| 03-May-2016 |
Sudeep Holla <Sudeep.Holla@arm.com> |
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R) on systems using arm_big_little cpufreq driver, w
cpufreq: arm_big_little: use generic OPP functions for {init, free}_opp_table
Currently when performing random CPU hot-plugs and suspend-to-ram(S2R) on systems using arm_big_little cpufreq driver, we get warnings similar to something like below:
cpu cpu1: _opp_add: duplicate OPPs detected. Existing: freq: 600000000, volt: 800000, enabled: 1. New: freq: 600000000, volt: 800000, enabled: 1
This is mainly because the OPPs for the shared cpus are not set. We can just use dev_pm_opp_of_cpumask_add_table in case the OPPs are obtained from DT(arm_big_little_dt.c) or use dev_pm_opp_set_sharing_cpus if the OPPs are obtained by other means like firmware(e.g. scpi-cpufreq.c)
Also now that the generic dev_pm_opp{,_of}_cpumask_remove_table can handle removal of opp table and entries for all associated CPUs, we can re-use dev_pm_opp{,_of}_cpumask_remove_table as free_opp_table in cpufreq_arm_bL_ops.
This patch makes necessary changes to reuse the generic OPP functions for {init,free}_opp_table and thereby eliminating the warnings.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2 |
|
#
30f51f24 |
| 20-Oct-2014 |
Wolfram Sang <wsa@the-dreams.de> |
cpufreq: drop owner assignment from platform_drivers
A platform_driver does not need to set an owner, it will be populated by the driver core.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
|
Revision tags: v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12 |
|
#
47ac9aa1 |
| 29-Oct-2013 |
Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> |
cpufreq: arm_big_little: add vexpress SPC interface driver
The TC2(i.e. CA15_A7) Versatile Express has external Cortex M3 based power controller which is responsible for CPU DVFS and SPC provides th
cpufreq: arm_big_little: add vexpress SPC interface driver
The TC2(i.e. CA15_A7) Versatile Express has external Cortex M3 based power controller which is responsible for CPU DVFS and SPC provides the interface for the same.
This patch adds a tiny interface driver to check if OPPs are initialised by SPC platform code and register the arm_big_little cpufreq driver.
Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
d62b3d14 |
| 03-Nov-2020 |
Pali Rohár <pali@kernel.org> |
cpufreq: vexpress-spc: Add missing MODULE_ALIAS [ Upstream commit d15183991c2d53d7cecf27a1555c91b702cef1ea ] This patch adds missing MODULE_ALIAS for automatic loading of this cpufr
cpufreq: vexpress-spc: Add missing MODULE_ALIAS [ Upstream commit d15183991c2d53d7cecf27a1555c91b702cef1ea ] This patch adds missing MODULE_ALIAS for automatic loading of this cpufreq driver when it is compiled as an external module. Signed-off-by: Pali Rohár <pali@kernel.org> Fixes: 47ac9aa165540 ("cpufreq: arm_big_little: add vexpress SPC interface driver") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.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 ima
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 ...
|
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, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
0e0ffa85 |
| 27-May-2020 |
Lukasz Luba <lukasz.luba@arm.com> |
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct
OPP: refactor dev_pm_opp_of_register_em() and update related drivers The Energy Model framework supports not only CPU devices. Drop the CPU specific interface with cpumask and add struct device. Add also a return value, user might use it. This new interface provides easy way to create a simple Energy Model, which then might be used by e.g. thermal subsystem. Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|