- May 30, 2018
-
-
Sebastian Andrzej Siewior authored
Use the static SRCU initializer for `cpufreq_transition_notifier_list'. This avoids the init_cpufreq_transition_notifier_list() initcall. Its only purpose is to initialize the SRCU notifier once during boot and set another variable which is used as an indicator whether the init was perfromed before cpufreq_register_notifier() was used. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Tao Wang authored
If the policy limits are updated via cpufreq_update_policy() and subsequently via sysfs, the limits stored in user_policy may be set incorrectly. For example, if both min and max are set via sysfs to the maximum available frequency, user_policy.min and user_policy.max will also be the maximum. If a policy notifier triggered by cpufreq_update_policy() lowers both the min and the max at this point, that change is not reflected by the user_policy limits, so if the max is updated again via sysfs to the same lower value, then user_policy.max will be lower than user_policy.min which shouldn't happen. In particular, if one of the policy CPUs is then taken offline and back online, cpufreq_set_policy() will fail for it due to a failing limits check. To prevent that from happening, initialize the min and max fields of the new_policy object to the ones stored in user_policy that were previously set via sysfs. Signed-off-by:
Kevin Wangtao <kevin.wangtao@hisilicon.com> Acked-by:
-
- May 21, 2018
-
-
Dmitry Osipenko authored
Currently tegra20-cpufreq kernel module isn't getting autoloaded because there is no device associated with the module, this is one of two patches that resolves the module autoloading. This patch adds a module alias that will associate the tegra20-cpufreq kernel module with the platform device, other patch will instantiate the actual platform device. And now it makes sense to wrap cpufreq driver into a platform driver for consistency. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
-
Dmitry Osipenko authored
Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to be built as a non-builtin kernel module. Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Dmitry Osipenko authored
Don't even try to request the clocks during of module initialization on non-Tegra20 machines (this is the case for a multi-platform kernel) for consistency. Signed-off-by:
-
Dmitry Osipenko authored
Remove unneeded variable initialization solely for consistency. Signed-off-by:
-
Dmitry Osipenko authored
Remove unnecessary parentheses as suggested by the checkpatch script. Signed-off-by:
-
Dmitry Osipenko authored
Remove checking of the CPU number for consistency as it won't ever fail unless there is a severe bug in the cpufreq core. Signed-off-by:
-
Dmitry Osipenko authored
Properly put requested clocks in the module init/exit code. Signed-off-by:
-
Dmitry Osipenko authored
The EMC driver has been gone 4 years ago, since the commit a7cbe92c ("ARM: tegra: remove tegra EMC scaling driver"). Remove the EMC clock usage as it does nothing. We may consider re-implementing the EMC scaling later, probably using PM Memory Bandwidth QoS API. Signed-off-by:
-
Dmitry Osipenko authored
Remove unused/unneeded headers and sort them in the alphabet order. Signed-off-by:
-
Dmitry Osipenko authored
Remove unneeded blank line and replace whitespaces with a tab in the code for consistency. Signed-off-by:
-
Dmitry Osipenko authored
Change module description to be in line with the other Tegra drivers, just for consistency. Signed-off-by:
-
- May 15, 2018
-
-
Simon Horman authored
This reverts commit 034def59. This is no longer needed since the following commit and to the best of my knowledge is not relied on by any upstream DTS: edeec420 (cpufreq: dt-platdev: Automatically create cpufreq device with OPP v2) Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Acked-by:
-
Simon Horman authored
This reverts commit bea2ebca. This is no longer needed since the following commit and to the best of my knowledge is not relied on by any upstream DTS: edeec420 (cpufreq: dt-platdev: Automatically create cpufreq device with OPP v2) Signed-off-by:
-
- May 14, 2018
-
-
Doug Smythies authored
Allow use of the trace_pstate_sample trace function when the intel_pstate driver is in passive mode. Since the core_busy and scaled_busy fields are not used, and it might be desirable to know which path through the driver was used, either intel_cpufreq_target or intel_cpufreq_fast_switch, re-task the core_busy field as a flag indicator. The user can then use the intel_pstate_tracer.py utility to summarize and plot the trace. Note: The core_busy feild still goes by that name in include/trace/events/power.h and within the intel_pstate_tracer.py script and csv file headers, but it is graphed as "performance", and called core_avg_perf now in the intel_pstate driver. Sometimes, in passive mode, the driver is not called for many tens or even hundreds of seconds. The user needs to understand, and not be confused by, this limitation. Signed-off-by:
Doug Smythies <dsmythies@telus.net> Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Miquel Raynal authored
Armada-37xx driver registers a cpufreq-dt driver. Not having CONFIG_CPUFREQ_DT selected leads to a silent abort during the probe. Prevent that situation by having the former depending on the latter. Fixes: 92ce45fb (cpufreq: Add DVFS support for Armada 37xx) Cc: 4.16+ <stable@vger.kernel.org> # 4.16+ Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
-
- May 13, 2018
-
-
Viresh Kumar authored
cpufreq_notify_transition() calls __cpufreq_notify_transition() for each CPU of a policy. There is a lot of code in __cpufreq_notify_transition() though which isn't required to be executed for each CPU, like checking about disabled cpufreq or irqs, adjusting jiffies, updating cpufreq stats and some debug print messages. This commit merges __cpufreq_notify_transition() into cpufreq_notify_transition() and modifies cpufreq_notify_transition() to execute minimum amount of code for each CPU. Also fix the kerneldoc for cpufreq_notify_transition() while at it. Signed-off-by:
-
- May 10, 2018
-
-
Colin Ian King authored
Trivial fix to spelling mistake in s3c_freq_dbg debug message text. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Luc Van Oostenryck authored
speedstep_detect_processor() is declared as returing an 'enum speedstep_processor' but use an 'int' in its definition. Fix this by using 'enum speedstep_processor' in its definition too. Signed-off-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Acked-by:
-
Miquel Raynal authored
Add suspend/resume hooks in Armada 37xx DVFS driver to handle S2RAM operations. As there is currently no 'driver' structure, create one to store both the regmap and the register values during suspend operation. Signed-off-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Viresh Kumar authored
The resources weren't freed on failures, free them properly. Signed-off-by:
-
Viresh Kumar authored
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:
-
- Apr 30, 2018
-
-
Prashanth Prakash authored
Add support to specify platform specific transition_delay_us instead of using the transition delay derived from PCC. With commit 3d41386d (cpufreq: CPPC: Use transition_delay_us depending transition_latency) we are setting transition_delay_us directly and not applying the LATENCY_MULTIPLIER. Because of that, on Qualcomm Centriq we can end up with a very high rate of frequency change requests when using the schedutil governor (default rate_limit_us=10 compared to an earlier value of 10000). The PCC subspace describes the rate at which the platform can accept commands on the CPPC's PCC channel. This includes read and write command on the PCC channel that can be used for reasons other than frequency transitions. Moreover the same PCC subspace can be used by multiple freq domains and deriving transition_delay_us from it as we do now can be sub-optimal. Moreover if a platform does not use PCC for desired_perf register then there is no way to compute the transition latency or the delay_us. CPPC does not have a standard defined mechanism to get the transition rate or the latency at the moment. Given the above limitations, it is simpler to have a platform specific transition_delay_us and rely on PCC derived value only if a platform specific value is not available. Signed-off-by:
Prashanth Prakash <pprakash@codeaurora.org> Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ Fixes: 3d41386d (cpufreq: CPPC: Use transition_delay_us depending transition_latency) Signed-off-by:
-
- Apr 27, 2018
-
-
Shilpasri G Bhat authored
gpstate_timer_handler() uses synchronous smp_call to set the pstate on the requested core. This causes the below hard lockup: smp_call_function_single+0x110/0x180 (unreliable) smp_call_function_any+0x180/0x250 gpstate_timer_handler+0x1e8/0x580 call_timer_fn+0x50/0x1c0 expire_timers+0x138/0x1f0 run_timer_softirq+0x1e8/0x270 __do_softirq+0x158/0x3e4 irq_exit+0xe8/0x120 timer_interrupt+0x9c/0xe0 decrementer_common+0x114/0x120 -- interrupt: 901 at doorbell_global_ipi+0x34/0x50 LR = arch_send_call_function_ipi_mask+0x120/0x130 arch_send_call_function_ipi_mask+0x4c/0x130 smp_call_function_many+0x340/0x450 pmdp_invalidate+0x98/0xe0 change_huge_pmd+0xe0/0x270 change_protection_range+0xb88/0xe40 mprotect_fixup+0x140/0x340 SyS_mprotect+0x1b4/0x350 system_call+0x58/0x6c One way to avoid this is removing the smp-call. We can ensure that the timer always runs on one of the policy-cpus. If the timer gets migrated to a cpu outside the policy then re-queue it back on the policy->cpus. This way we can get rid of the smp-call which was being used to set the pstate on the policy->cpus. Fixes: 7bc54b65 ("timers, cpufreq/powernv: Initialize the gpstate timer as pinned") Cc: stable@vger.kernel.org # v4.8+ Reported-by:
Nicholas Piggin <npiggin@gmail.com> Reported-by:
Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> Signed-off-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Acked-by:
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
- Apr 24, 2018
-
-
Markus Mayer authored
This debug code was helpful while developing the driver, but it isn't being used for anything anymore. Signed-off-by:
Markus Mayer <mmayer@broadcom.com> Acked-by:
-
- Apr 10, 2018
-
-
Viresh Kumar authored
This isn't used anymore. Remove the helper and update documentation accordingly. Signed-off-by:
-
Viresh Kumar authored
The cpufreq core is already validating the CPU frequency table after calling the ->init() callback of the cpufreq drivers and the drivers don't need to do the same anymore. Though they need to set the policy->freq_table field directly from the ->init() callback now. Stop validating the frequency table from SCMI driver. Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Shunyong Yang authored
When multiple CPUs are related in one cpufreq policy, the first online CPU will be chosen by default to handle cpufreq operations. Let's take cpu0 and cpu1 as an example. When cpu0 is offline, policy->cpu will be shifted to cpu1. cpu1's perf capabilities should be initialized. Otherwise, perf capabilities are 0s and speed change can not take effect. This patch copies perf capabilities of the first online CPU to other shared CPUs when policy shared type is CPUFREQ_SHARED_TYPE_ANY. Acked-by:
Shunyong Yang <shunyong.yang@hxt-semitech.com> Signed-off-by:
-
Gregory CLEMENT authored
There was no clk_put() balancing the clk_get(). This commit fixes it. Fixes: 92ce45fb (cpufreq: Add DVFS support for Armada 37xx) Cc: 4.16+ <stable@vger.kernel.org> # 4.16+ Reported-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by:
-
Viresh Kumar authored
Now that the driver has started to set transition_delay_us directly, there is no need to set transition_latency along with it, as it is not used by the cpufreq core. Signed-off-by:
-
Viresh Kumar authored
This driver can not be built as a module and there is no need of the platform driver unregister part. Use builtin_platform_driver() instead of module_platform_driver(). Signed-off-by:
-
Rafael J. Wysocki authored
The intel_pstate driver doesn't use debugfs any more, so drop linux/debugfs.h from the list of included headers in it. Signed-off-by:
-
- Mar 30, 2018
-
-
George Cherian authored
With commit e948bc8f (cpufreq: Cap the default transition delay value to 10 ms) the cpufreq was not honouring the delay passed via ACPI (PCCT). Due to which on ARM based platforms using CPPC the cpufreq governor tries to change the frequency of CPUs faster than expected. This leads to continuous error messages like the following. " ACPI CPPC: PCC check channel failed. Status=0 " Earlier (without above commit) the default transition delay was taken form the value passed from PCCT. Use the same value provided by PCCT to set the transition_delay_us. Fixes: e948bc8f (cpufreq: Cap the default transition delay value to 10 ms) Signed-off-by:
George Cherian <george.cherian@cavium.com> Cc: 4.14+ <stable@vger.kernel.org> # 4.14+ Signed-off-by:
-
- Mar 26, 2018
-
-
Arnd Bergmann authored
The cris architecture is getting removed, including the artpec3 and etraxfs SoCs, so these cpufreq drivers are now unused. Acked-by:
Rafael J. Wysocki <rafael@kernel.org> Acked-by:
Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
The blackfin architecture is getting removed, so this driver is now obsolete. Acked-by:
Aaron Wu <aaron.wu@analog.com> Signed-off-by:
-
- Mar 20, 2018
-
-
Viresh Kumar authored
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 tegra186 driver. Signed-off-by:
-
Viresh Kumar authored
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 speedstep driver. Signed-off-by:
-
Viresh Kumar authored
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 sparc driver. Signed-off-by:
-
Viresh Kumar authored
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 sh-cpufreq driver. The driver though prints the min/max frequency values and the same is done from the ->ready() callback now to keep the behavior unchanged. Signed-off-by:
-
