- 25 Apr, 2016 10 commits
-
-
Viresh Kumar authored
The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. Note that the complete routine imx27_dt_init() is removed as of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); has same effect as a NULL .init_machine machine callback pointer. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Acked-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Viresh Kumar authored
The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. Signed-off-by:
Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by:
-
Viresh Kumar authored
The machines array in cpufreq-dt-platdev is used only once at boot time and so should be marked with __initconst, so that kernel can free up memory used for it, if required. Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Jia Hongtao authored
Cooling device is registered by ready callback. It's also invoked while system resuming from sleep (Enabling non-boot cpus). Thus cooling device may be multiple registered. Matchable unregistration is added to exit callback to fix this issue. Signed-off-by:
Jia Hongtao <hongtao.jia@nxp.com> Signed-off-by:
-
Jia Hongtao authored
.exit callback (qoriq_cpufreq_cpu_exit()) is also used during suspend. So __exit macro should be removed or the function will be discarded. Signed-off-by:
-
Jia Hongtao authored
When THERMAL_OF is undefined the cooling device messages should not be shown. -ENOSYS is returned from of_cpufreq_cooling_register() when THERMAL_OF is undefined. Signed-off-by:
-
Ashwin Chaugule authored
Add a function to cleanup at module exit and export appropriate GPL string to enable moduler support for the cppc_cpufreq driver. Reported-by:
Srinivas Pandruvada <srinivas.pandruvada@intel.com> Signed-off-by:
Ashwin Chaugule <ashwin.chaugule@linaro.org> Signed-off-by:
-
Philippe Longepe authored
The result returned by pid_calc() is subtracted from current_pstate (which is the P-State requested during the last period) in order to obtain the target P-State for the current iteration. However, current_pstate may not reflect the real current P-State of the CPU. In particular, that P-State may be higher because of the frequency sharing per module. The theory is: - The load is the percentage of time spent in C0 and is related to the average P-State during the same period. - The last requested P-State can be completely different than the average P-State (because of frequency sharing or throttling). - The P-State shift computed by the pid_calc is based on the load computed at average P-State, so the shift must be relative to this average P-State. Using the average P-State instead of current P-State improves power without significant performance penalty in cases when a task migrates from one core to other core sharing frequency and voltage. Performance and power comparison with this patch on Cherry Trail platform using Android: Benchmark ?Perf ?Power FishTank 10.45% 3.1% SmartBench-Gaming -0.1% -10.4% SmartBench-Productivity -0.8% -10.4% CandyCrush n/a -17.4% AngryBirds n/a -5.9% videoPlayback n/a -13.9% audioPlayback n/a -4.9% IcyRocks-20-50 0.0% -38.4% iozone RR -0.16% -1.3% iozone RW 0.74% -1.3% Signed-off-by:
Philippe Longepe <philippe.longepe@linux.intel.com> Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
-
Rafael J. Wysocki authored
Revert commit 0df35026 (cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC) that introduced a regression by causing the ondemand cpufreq governor to misbehave for CONFIG_TICK_CPU_ACCOUNTING unset (the frequency goes up to the max at one point and stays there indefinitely). The revert takes subsequent modifications of the code in question into account. Fixes: 0df35026 (cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC) Link: https://bugzilla.kernel.org/show_bug.cgi?id=115261Reported-and-tested-by:
Timo Valtoaho <timo.valtoaho@gmail.com> Cc: 4.5+ <stable@vger.kernel.org> # 4.5+ Signed-off-by:
-
- 18 Apr, 2016 1 commit
-
-
Rafael J. Wysocki authored
Since governor operations are generally skipped if cpufreq_suspended is set, cpufreq_start_governor() should do nothing in that case. That function is called in the cpufreq_online() path, and may also be called from cpufreq_offline() in some cases, which are invoked by the nonboot CPUs disabing/enabling code during system suspend to RAM and resume. That happens when all devices have been suspended, so if the cpufreq driver relies on things like I2C to get the current frequency, it may not be ready to do that then. To prevent problems from happening for this reason, make cpufreq_update_current_freq(), which is the only function invoked by cpufreq_start_governor() that doesn't check cpufreq_suspended already, return 0 upfront if cpufreq_suspended is set. Fixes: 3bbf8fe3 (cpufreq: Always update current frequency before startig governor) Signed-off-by:
-
- 10 Apr, 2016 1 commit
-
-
Rafael J. Wysocki authored
Jörg Otte reports that commit a4675fbc (cpufreq: intel_pstate: Replace timers with utilization update callbacks) caused the CPUs in his Haswell-based system to stay in the very high frequency region even if the system is completely idle. That turns out to be an existing problem in the intel_pstate driver's P-state selection algorithm for Core processors. Namely, all decisions made by that algorithm are based on the average frequency of the CPU between sampling events and on the P-state requested on the last invocation, so it may get stuck at a very hight frequency even if the utilization of the CPU is very low (in fact, it may get stuck in a inadequate P-state regardless of the CPU utilization). The only way to kick it out of that limbo is a sufficiently long idle period (3 times longer than the prescribed sampling interval), but if that doesn't happen often enough (eg. due to a timing change like after the above commit), the P-state of the CPU may be inadequate pretty much all the time. To address the most egregious manifestations of that issue, reset the core_busy value used to determine the next P-state to request if the utilization of the CPU, determined with the help of the MPERF feedback register and the TSC, is below 1%. Link: https://bugzilla.kernel.org/show_bug.cgi?id=115771Reported-and-tested-by:
Jörg Otte <jrg.otte@gmail.com> Signed-off-by:
-
- 08 Apr, 2016 17 commits
-
-
Viresh Kumar authored
The freq-table is stored in struct cpufreq_policy also and there is absolutely no need of keeping a copy of its reference in struct acpi_cpufreq_data. Drop it. Also policy->freq_table can't be NULL in the target() callback, remove the useless check as well. Signed-off-by:
-
Viresh Kumar authored
Its always set by ->init() and so it will always be there in ->exit(). There is no need to have a special check for just that. Signed-off-by:
-
Rafael J. Wysocki authored
Reorganize the code in cpufreq_add_dev() to avoid using the ret variable and reduce the indentation level in it. No functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
Merge two switch entries that do the same thing in cpufreq_cpu_callback(). No functional changes. Signed-off-by:
-
Joe Perches authored
Use the more common kernel style adding a define for pr_fmt. Miscellanea: o Remove now unused PFX defines Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
-
Joe Perches authored
Use the more common logging style. Miscellanea: o Coalesce formats o Realign arguments o Add a missing space between a coalesced format Signed-off-by:
-
Joe Perches authored
Prefix the output using the more common kernel style. Signed-off-by:
-
Geliang Tang authored
Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by:
Geliang Tang <geliangtang@163.com> Acked-by:
-
Rafael J. Wysocki authored
There are multiple places in intel_pstate where int_tofp() is applied to both arguments of div_fp(), but this is pointless, because int_tofp() simply shifts its argument to the left by FRAC_BITS which mathematically is equivalent to multuplication by 2^FRAC_BITS, so if this is done to both arguments of a division, the extra factors will cancel each other during that operation anyway. Drop the pointless int_tofp() applied to div_fp() arguments throughout the driver. Signed-off-by: -
Viresh Kumar authored
The cpufreq-dt-platdev driver supports creation of cpufreq-dt platform device now, reuse that and remove similar code from platform code. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Viresh Kumar authored
The driver is removed long back and we don't support this device anymore. Stop adding it. Signed-off-by:
-
Viresh Kumar authored
Multiple platforms are using the generic cpufreq-dt driver now, and all of them are required to create a platform device with name "cpufreq-dt", in order to get the cpufreq-dt probed. Many of them do it from platform code, others have special drivers just to do that. It would be more sensible to do this at a generic place, where all such platform can mark their entries. This patch adds a separate file to get this device created. Currently the compat list of platforms that we support is empty, and will be filled in as and when we move platforms to use it. It always compiles as part of the kernel and so doesn't need a module-exit operation. Signed-off-by:
-
Viresh Kumar authored
cpufreq-dt.h uses 'bool' data type but doesn't include types.h. It works fine for now as the files that include cpufreq-dt.h, also include types.h directly or indirectly. But, when a file includes cpufreq-dt.h without including types.h, we get a build error. Avoid such errors by including types.h in cpufreq-dt itself. Signed-off-by:
-
Viresh Kumar authored
All CPUs on Tegra platform share clock/voltage lines and there is absolutely no need of setting platform data for 'cpufreq-dt' platform device, as that's the default case. Stop setting platform data for cpufreq-dt device. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Paul Gortmaker authored
The Kconfig for this driver is currently: config CPU_FREQ_CBE_PMI bool "CBE frequency scaling using PMI interface" ...meaning that it currently is not being built as a module by anyone. Lets remove the modular and unused code here, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Signed-off-by:Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
-
Rafael J. Wysocki authored
-
Rafael J. Wysocki authored
Due to differences in the cpufreq core's handling of runtime CPU offline and nonboot CPUs disabling during system suspend-to-RAM, fast frequency switching gets disabled after a suspend-to-RAM and resume cycle on all of the nonboot CPUs. To prevent that from happening, move the invocation of cpufreq_disable_fast_switch() from cpufreq_exit_governor() to sugov_exit(), as the schedutil governor is the only user of fast frequency switching today anyway. That simply prevents cpufreq_disable_fast_switch() from being called without invoking the ->governor callback for the CPUFREQ_GOV_POLICY_EXIT event (which happens during system suspend now). Fixes: b7898fda (cpufreq: Support for fast frequency switching) Signed-off-by:
-
- 05 Apr, 2016 3 commits
-
-
Viresh Kumar authored
The comment in file header doesn't hold true anymore, drop it. Signed-off-by:
-
Srinivas Pandruvada authored
No code change. Only added kernel doc style comments for structures. Signed-off-by:
-
Srinivas Pandruvada authored
When user sets performance policy using cpufreq interface, it is possible that because of policy->max limits, the actual performance is still limited. But the current implementation will silently switch the policy to powersave and start using powersave limits. If user modifies any limits using intel_pstate sysfs, this is actually changing powersave limits. The current implementation tracks limits under powersave and performance policy using two different variables. When policy->max is less than policy->cpuinfo.max_freq, only powersave limit variable is used. This fix causes the performance limits variable to be used always when the policy is performance. Signed-off-by:
-
- 01 Apr, 2016 8 commits
-
-
Rafael J. Wysocki authored
Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c555 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org>
-
Rafael J. Wysocki authored
Modify the ACPI cpufreq driver to provide a method for switching CPU frequencies from interrupt context and update the cpufreq core to support that method if available. Introduce a new cpufreq driver callback, ->fast_switch, to be invoked for frequency switching from interrupt context by (future) governors supporting that feature via (new) helper function cpufreq_driver_fast_switch(). Add two new policy flags, fast_switch_possible, to be set by the cpufreq driver if fast frequency switching can be used for the given policy and fast_switch_enabled, to be set by the governor if it is going to use fast frequency switching for the given policy. Also add a helper for setting the latter. Since fast frequency switching is inherently incompatible with cpufreq transition notifiers, make it possible to set the fast_switch_enabled only if there are no transition notifiers already registered and make the registration of new transition notifiers fail if fast_switch_enabled is set for at least one policy. Implement the ->fast_switch callback in the ACPI cpufreq driver and make it set fast_switch_possible during policy initialization as appropriate. Signed-off-by:
-
Rafael J. Wysocki authored
Move definitions of symbols related to transition latency and sampling rate to include/linux/cpufreq.h so they can be used by (future) goverernors located outside of drivers/cpufreq/. No functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
Move definitions and function headers related to struct gov_attr_set to include/linux/cpufreq.h so they can be used by (future) goverernors located outside of drivers/cpufreq/. No functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
Move abstract code related to struct gov_attr_set to a separate (new) file so it can be shared with (future) goverernors that won't share more code with "ondemand" and "conservative". No intentional functional changes. Signed-off-by:
-
Rafael J. Wysocki authored
In addition to fields representing governor tunables, struct dbs_data contains some fields needed for the management of objects of that type. As it turns out, that part of struct dbs_data may be shared with (future) governors that won't use the common code used by "ondemand" and "conservative", so move it to a separate struct type and modify the code using struct dbs_data to follow. Signed-off-by:
-
Rafael J. Wysocki authored
Replace the single helper for adding and removing cpufreq utilization update hooks, cpufreq_set_update_util_data(), with a pair of helpers, cpufreq_add_update_util_hook() and cpufreq_remove_update_util_hook(), and modify the users of cpufreq_set_update_util_data() accordingly. With the new helpers, the code using them doesn't need to worry about the internals of struct update_util_data and in particular it doesn't need to worry about populating the func field in it properly upfront. Signed-off-by:
-
Rafael J. Wysocki authored
* pm-cpufreq: intel_pstate: Avoid extra invocation of intel_pstate_sample() intel_pstate: Do not set utilization update hook too early
-
