#
68090fda |
| 23-Apr-2024 |
Javier Carrasco <javier.carrasco.cruz@gmail.com> |
cpufreq: dt: eliminate uses of of_node_put()
Make use of the __free() cleanup handler to automatically free nodes when they get out of scope.
Only find_supply_name() is affected, and the new mechan
cpufreq: dt: eliminate uses of of_node_put()
Make use of the __free() cleanup handler to automatically free nodes when they get out of scope.
Only find_supply_name() is affected, and the new mechanism removes the need for a 'goto' and the 'name' local variable.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
d2399501 |
| 14-Mar-2024 |
Marek Szyprowski <m.szyprowski@samsung.com> |
cpufreq: dt: always allocate zeroed cpumask
Commit 0499a78369ad ("ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512") changed the handling of cpumasks on ARM 64bit, what result
cpufreq: dt: always allocate zeroed cpumask
Commit 0499a78369ad ("ARM64: Dynamically allocate cpumasks and increase supported CPUs to 512") changed the handling of cpumasks on ARM 64bit, what resulted in the strange issues and warnings during cpufreq-dt initialization on some big.LITTLE platforms.
This was caused by mixing OPPs between big and LITTLE cores, because OPP-sharing information between big and LITTLE cores is computed on cpumask, which in turn was not zeroed on allocation. Fix this by switching to zalloc_cpumask_var() call.
Fixes: dc279ac6e5b4 ("cpufreq: dt: Refactor initialization to handle probe deferral properly") CC: stable@vger.kernel.org # v5.10+ Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Christoph Lameter (Ampere) <cl@linux.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
18da4176 |
| 12-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
cpufreq: dt: 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 h
cpufreq: dt: 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> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
2a808b9f |
| 27-Sep-2022 |
Yang Yingliang <yangyingliang@huawei.com> |
cpufreq: dt: Switch to use dev_err_probe() helper
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also
cpufreq: dt: Switch to use dev_err_probe() helper
In the probe path, dev_err() can be replaced with dev_err_probe() which will check if error code is -EPROBE_DEFER and prints the error name. It also sets the defer probe reason which can be checked later through debugfs. It's more simple in error path.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
b0ec0942 |
| 04-Jul-2022 |
Viresh Kumar <viresh.kumar@linaro.org> |
OPP: Migrate set-regulators API to use set-config helpers
Now that we have a central API to handle all OPP table configurations, migrate the set-regulators family of helpers to use the new infrastru
OPP: Migrate set-regulators API to use set-config helpers
Now that we have a central API to handle all OPP table configurations, migrate the set-regulators family of helpers to use the new infrastructure.
The return type and parameter to the APIs change a bit due to this, update the current users as well in the same commit in order to avoid breaking builds.
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
87686cc8 |
| 04-Jul-2022 |
Viresh Kumar <viresh.kumar@linaro.org> |
OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names instead of making the callers keep the two parameters in syn
OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list
Make dev_pm_opp_set_regulators() accept a NULL terminated list of names instead of making the callers keep the two parameters in sync, which creates an opportunity for bugs to get in.
Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Steven Price <steven.price@arm.com> # panfrost Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
94ab4c3c |
| 10-Aug-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: 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.
Signed-off-by: Viresh Kum
cpufreq: dt: 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.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
c3135d28 |
| 25-Mar-2021 |
Quanyang Wang <quanyang.wang@windriver.com> |
cpufreq: dt: dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER
The function dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER, which needs to be propagated to the caller to try pro
cpufreq: dt: dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER
The function dev_pm_opp_of_cpumask_add_table() may return -EPROBE_DEFER, which needs to be propagated to the caller to try probing the driver later on.
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> [ Viresh: Massage changelog/subject, improve code. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
5ae4a4b4 |
| 02-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 ...
|
#
5f6ffb8d |
| 06-Nov-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so there is no need for us to carry the extra checks. Drop them.
cpufreq: dt: dev_pm_opp_put_regulators() accepts NULL argument
The dev_pm_opp_put_*() APIs now accepts a NULL opp_table pointer and so there is no need for us to carry the extra checks. Drop them.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
873c9851 |
| 06-Nov-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: Don't (ab)use dev_pm_opp_get_opp_table() to create OPP table
Initially, the helper dev_pm_opp_get_opp_table() was supposed to be used only for the OPP core's internal use (it tries to f
cpufreq: dt: Don't (ab)use dev_pm_opp_get_opp_table() to create OPP table
Initially, the helper dev_pm_opp_get_opp_table() was supposed to be used only for the OPP core's internal use (it tries to find an existing OPP table and if it doesn't find one, then it allocates the OPP table).
Sometime back, the cpufreq-dt driver started using it to make sure all the relevant resources required by the OPP core are available earlier during initialization process to properly propagate -EPROBE_DEFER.
It worked but it also abused the API to create an OPP table, which should be created with the help of other helpers provided by the OPP core.
The OPP core will be updated in a later commit to limit the scope of dev_pm_opp_get_opp_table() to only finding an existing OPP table and not create one. This commit updates the cpufreq-dt driver before that happens.
Now the cpufreq-dt driver creates the OPP and cpufreq tables for all the CPUs from driver's init callback itself.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
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 ...
|
#
dc279ac6 |
| 27-Jul-2020 |
Stephan Gerhold <stephan@gerhold.net> |
cpufreq: dt: Refactor initialization to handle probe deferral properly
cpufreq-dt is currently unable to handle -EPROBE_DEFER properly because the error code is not propagated for the cpufreq_driver
cpufreq: dt: Refactor initialization to handle probe deferral properly
cpufreq-dt is currently unable to handle -EPROBE_DEFER properly because the error code is not propagated for the cpufreq_driver->init() callback. Instead, it attempts to avoid the situation by temporarily requesting all resources within resources_available() and releasing them again immediately after. This has several disadvantages:
- Whenever we add something like interconnect handling to the OPP core we need to patch cpufreq-dt to request these resources early.
- resources_available() is only run for CPU0, but other clusters may eventually depend on other resources that are not available yet. (See FIXME comment removed by this commit...)
- All resources need to be looked up several times.
Now that the OPP core can propagate -EPROBE_DEFER during initialization, it would be nice to avoid all that trouble and just propagate its error code when necessary.
This commit refactors the cpufreq-dt driver to initialize private_data before registering the cpufreq driver. We do this by iterating over all possible CPUs and ensure that all resources are initialized:
1. dev_pm_opp_get_opp_table() ensures the OPP table is allocated and initialized with clock and interconnects.
2. dev_pm_opp_set_regulators() requests the regulators and assigns them to the OPP table.
3. We call dev_pm_opp_of_get_sharing_cpus() early so that we only initialize the OPP table once for each shared policy.
With these changes, we actually end up saving a few lines of code, the resources are no longer looked up multiple times and everything should be much more robust.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net> [ Viresh: Use list_head structure for maintaining the list and minor changes ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
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 ...
|
#
8b17f17a |
| 12-May-2020 |
Georgi Djakov <georgi.djakov@linaro.org> |
cpufreq: dt: Add support for interconnect bandwidth scaling
In addition to clocks and regulators, some devices can scale the bandwidth of their on-chip interconnect - for example between CPU and DDR
cpufreq: dt: Add support for interconnect bandwidth scaling
In addition to clocks and regulators, some devices can scale the bandwidth of their on-chip interconnect - for example between CPU and DDR memory. Add support for that, so that platforms which support it can make use of it.
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org> [ Viresh: Reused dev_pm_opp_of_find_icc_paths(). Also drop the depends on from Kconfig. ] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
fixup! cpufreq: dt: Add support for interconnect bandwidth scaling
show more ...
|
#
0c868627 |
| 19-Feb-2020 |
Peng Fan <peng.fan@nxp.com> |
cpufreq: dt: Allow platform specific intermediate callbacks
Platforms may need to implement platform specific get_intermediate and target_intermediate hooks.
Update cpufreq-dt driver's platform dat
cpufreq: dt: Allow platform specific intermediate callbacks
Platforms may need to implement platform specific get_intermediate and target_intermediate hooks.
Update cpufreq-dt driver's platform data to contain those for such platforms.
Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
d2912cb1 |
| 04-Jun-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
263abfe7 |
| 12-Feb-2019 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: Implement online/offline() callbacks
Implement the light-weight tear down and bring up helpers to reduce the amount of work to do on CPU offline/online operation.
Signed-off-by: Viresh
cpufreq: dt: Implement online/offline() callbacks
Implement the light-weight tear down and bring up helpers to reduce the amount of work to do on CPU offline/online operation.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
76d004bf |
| 04-Feb-2019 |
Quentin Perret <quentin.perret@arm.com> |
cpufreq: dt: Register an Energy Model
Now that PM_OPP provides a helper function to estimate the power consumed by CPUs, make sure to try and register an Energy Model (EM) from cpufreq-dt, hence ens
cpufreq: dt: Register an Energy Model
Now that PM_OPP provides a helper function to estimate the power consumed by CPUs, make sure to try and register an Energy Model (EM) from cpufreq-dt, hence ensuring interested subsystems (the task scheduler, for example) can make use of that information when available.
Signed-off-by: Quentin Perret <quentin.perret@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
e248d8d3 |
| 29-Jan-2019 |
Amit Kucheria <amit.kucheria@linaro.org> |
cpufreq: cpufreq-dt: 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 rem
cpufreq: cpufreq-dt: 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: 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 ...
|
#
51c99dd2 |
| 03-Oct-2018 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: Try freeing static OPPs only if we have added them
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore since the latest OPP core updates as that uses reference counting
cpufreq: dt: Try freeing static OPPs only if we have added them
We can not call dev_pm_opp_of_cpumask_remove_table() freely anymore since the latest OPP core updates as that uses reference counting to free resources. There are cases where no static OPPs are added (using DT) for a platform and trying to remove the OPP table may end up decrementing refcount which is already zero and hence generating warnings.
Lets track if we were able to add static OPPs or not and then only remove the table based on that. Some reshuffling of code is also done to do that.
Reported-by: Niklas Cassel <niklas.cassel@linaro.org> Tested-by: Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
67782701 |
| 24-Apr-2018 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: dt: Allow platform specific suspend/resume callbacks
Platforms may need to implement platform specific suspend/resume hooks. Update cpufreq-dt driver's platform data to contain those for su
cpufreq: dt: Allow platform specific suspend/resume callbacks
Platforms may need to implement platform specific suspend/resume hooks. Update cpufreq-dt driver's platform data to contain those for such platforms.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
29aa18a7 |
| 26-Feb-2018 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpufreq: cpufreq-dt: 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 driver
cpufreq: cpufreq-dt: 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 cpufreq-dt driver.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
3ebb62ff |
| 05-Dec-2017 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpu_cooling: Keep only one of_cpufreq*cooling_register() helper
of_cpufreq_cooling_register() isn't used by anyone and so can be removed, but then we would be left with two routines: cpufreq_cooling
cpu_cooling: Keep only one of_cpufreq*cooling_register() helper
of_cpufreq_cooling_register() isn't used by anyone and so can be removed, but then we would be left with two routines: cpufreq_cooling_register() and of_cpufreq_power_cooling_register() that would look odd.
Remove current implementation of of_cpufreq_cooling_register() and rename of_cpufreq_power_cooling_register() as of_cpufreq_cooling_register(). This simplifies lots of stuff.
Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
f5f263fe |
| 05-Dec-2017 |
Viresh Kumar <viresh.kumar@linaro.org> |
cpu_cooling: Make of_cpufreq_power_cooling_register() parse DT
All the callers of of_cpufreq_power_cooling_register() have almost identical code and it makes more sense to move that code into the he
cpu_cooling: Make of_cpufreq_power_cooling_register() parse DT
All the callers of of_cpufreq_power_cooling_register() have almost identical code and it makes more sense to move that code into the helper as its all about reading DT properties.
This got rid of lot of redundant code.
Acked-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|