- Jul 26, 2017
-
-
Julia Lawall authored
for_each_compatible_node performs an of_node_get on each iteration, so a return from the loop requires an of_node_put. The semantic patch that fixes this problem is as follows (http://coccinelle.lip6.fr ): // <smpl> @@ local idexpression n; expression e,e1,e2; statement S; iterator i1; iterator name for_each_compatible_node; @@ for_each_compatible_node(n,e1,e2) { ... ( of_node_put(n); | e = n | return n; | i1(...,n,...) S | + of_node_put(n); ? return ...; ) ... } // </smpl> Additionally, call of_node_put on the previous value of np, obtained from of_find_compatible_node, that is no longer accessible at the point of the for_each_compatible_node. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jul 25, 2017
-
-
Viresh Kumar authored
With the recent updates, CPUFREQ_ETERNAL is only used by the drivers which don't know their transition latency but want to use dynamic switching. Anyway, the routine cpufreq_policy_transition_delay_us() caps the value of transition latency to 10 ms now and that can be used safely with such platforms. Remove the check from cpufreq_init_governor() and allow dynamic switching for such configurations as well. Signed-off-by:
-
Viresh Kumar authored
The policy->transition_latency field is used for multiple purposes today and its not straight forward at all. This is how it is used: A. Set the correct transition_latency value. B. Set it to CPUFREQ_ETERNAL because: 1. We don't want automatic dynamic switching (with ondemand/conservative) to happen at all. 2. We don't know the transition latency. This patch handles the B.1. case in a more readable way. A new flag for the cpufreq drivers is added to disallow use of cpufreq governors which have dynamic_switching flag set. All the current cpufreq drivers which are setting transition_latency unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't need to set transition_latency anymore. There shouldn't be any functional change after this patch. Signed-off-by:Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by:
-
Viresh Kumar authored
There is no limitation in the ondemand or conservative governors which disallow the transition_latency to be greater than 10 ms. The max_transition_latency field is rather used to disallow automatic dynamic frequency switching for platforms which didn't wanted these governors to run. Replace max_transition_latency with a boolean (dynamic_switching) and check for transition_latency == CPUFREQ_ETERNAL along with that. This makes it pretty straight forward to read/understand now. Signed-off-by:
-
Viresh Kumar authored
All users of arm_big_little driver are defining it and there is no need to keep it optional. Make it mandatory to remove the always true conditional statement. Signed-off-by:
-
Viresh Kumar authored
The transition_latency field isn't used for drivers with ->setpolicy() callback present and there is no point setting it from the drivers. Signed-off-by:
-
- Jul 22, 2017
-
-
Viresh Kumar authored
The policy->transition_delay_us field is used only by the schedutil governor currently, and this field describes how fast the driver wants the cpufreq governor to change CPUs frequency. It should rather be a common thing across all governors, as it doesn't have any schedutil dependency here. Create a new helper cpufreq_policy_transition_delay_us() to get the transition delay across all governors. Signed-off-by:
-
Viresh Kumar authored
The cpufreq core and governors aren't supposed to set a limit on how fast we want to try changing the frequency. This is currently done for the legacy governors with help of min_sampling_rate. At worst, we may end up setting the sampling rate to a value lower than the rate at which frequency can be changed and then one of the CPUs in the policy will be only changing frequency for ever. But that is something for the user to decide and there is no need to have special handling for such cases in the core. Leave it for the user to figure out. Signed-off-by:
-
Marc Gonzalez authored
On tango platforms, firmware configures the CPU clock, and Linux is then only allowed to use the cpu_clk_divider to change the frequency. Build the OPP table dynamically at init, in order to support whatever firmware throws at us. Signed-off-by:
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Acked-by:
-
Sean Wang authored
MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with single cluster and this hardware is also compatible with the existing driver through enabling CPU frequency feature with operating-points-v2 bindings. Also, this driver actually supports all MediaTek SoCs, the Kconfig menu entry and file name itself should be updated with more generic name to drop "MT8173" Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Acked-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
- Jul 16, 2017
-
-
Shubhrajyoti Datta authored
Add zynqmp to the cpufreq dt platform device. Signed-off-by:
Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Acked-by:
-
Gustavo A. R. Silva authored
Remove unnecessary static on local variable hostbridge. Such variable is initialized before being used, on every execution path throughout the function. The static has no benefit and, removing it reduces the code size. This issue was detected using Coccinelle and the following semantic patch: @bad exists@ position p; identifier x; type T; @@ static T x@p; ... x = <+...x...+> @@ identifier x; expression e; type T; position p != bad.p; @@ -static T x@p; ... when != x when strict ?x = e; In the following log you can see the difference in the code size. Also, there is a significant difference in the bss segment. This log is the output of the size command, before and after the code change: before: text data bss dec hex filename 5084 3392 256 8732 221c drivers/cpufreq/speedstep-ich.o after: text data bss dec hex filename 5062 3304 192 8558 216e drivers/cpufreq/speedstep-ich.o Signed-off-by:Gustavo A. R. Silva <garsilva@embeddedor.com> Acked-by:
-
- Jul 12, 2017
-
-
Srinivas Pandruvada authored
When the minimum performance limit percentage is set to the power-up default, it is possible that minimum performance ratio is off by one. In the set_policy() callback the minimum ratio is calculated by applying global.min_perf_pct to turbo_ratio and rounding up, but the power-up default global.min_perf_pct is already rounded up to the next percent in min_perf_pct_min(). That results in two round up operations, so for the default min_perf_pct one of them is not required. It is better to remove rounding up in min_perf_pct_min() as this matches the displayed min_perf_pct prior to commit c5a2ee7d (cpufreq: intel_pstate: Active mode P-state limits rework) in 4.12. For example on a platform with max turbo ratio of 37 and minimum ratio of 10, the min_perf_pct resulted in 28 with the above commit. Before this commit it was 27 and it will be the same after this change. Fixes: 1a4fe38a (cpufreq: intel_pstate: Remove max/min fractions to limit performance) Reported-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
- Jul 04, 2017
-
-
Arvind Yadav authored
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 15197 2552 40 17789 457d drivers/cpufreq/intel_pstate.o File size After adding 'const': text data bss dec hex filename 15261 2488 40 17789 457d drivers/cpufreq/intel_pstate.o Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Acked-by:
-
Arvind Yadav authored
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. File size before: text data bss dec hex filename 1655 256 4 1915 77b drivers/cpufreq/cpufreq_stats.o File size After adding 'const': text data bss dec hex filename 1695 192 4 1891 763 drivers/cpufreq/cpufreq_stats.o Signed-off-by:
-
- Jun 29, 2017
-
-
Rafael J. Wysocki authored
After commit 82b4e03e (intel_pstate: skip scheduler hook when in "performance" mode) get_target_pstate_use_performance() and get_target_pstate_use_cpu_load() are never called if scaling_governor is "performance", so drop the CPUFREQ_POLICY_PERFORMANCE checks from them as they will never trigger anyway. Moreover, the documentation needs to be updated to reflect the change made by the above commit, so do that too. Signed-off-by:
-
- Jun 27, 2017
-
-
Prakash, Prashanth authored
Description of Lowest Perfomance in ACPI 6.1 specification states: "Lowest Performance is the absolute lowest performance level of the platform. Selecting a performance level lower than the lowest nonlinear performance level may actually cause an efficiency penalty, but should reduce the instantaneous power consumption of the processor. In traditional terms, this represents the T-state range of performance levels." Set the default value of policy->min to Lowest Nonlinear Performance to avoid any potential efficiency penalty. Signed-off-by:
Prashanth Prakash <pprakash@codeaurora.org> Acked-by:
Alexey Klimov <alexey.klimov@arm.com> Signed-off-by:
-
- Jun 26, 2017
-
-
Len Brown authored
When the governor is set to "performance", intel_pstate does not need the scheduler hook for doing any calculations. Under these conditions, its only purpose is to continue to maintain cpufreq/scaling_cur_freq. The cpufreq/scaling_cur_freq sysfs attribute is now provided by shared x86 cpufreq code on modern x86 systems, including all systems supported by the intel_pstate driver. So in "performance" governor mode, the scheduler hook can be skipped. This applies to both in Software and Hardware P-state control modes. Suggested-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Len Brown authored
The cpufreq/scaling_cur_freq sysfs attribute is now provided by shared x86 cpufreq code on modern x86 systems, including all systems supported by the intel_pstate driver. In HWP mode, maintaining that value was the sole purpose of the scheduler hook, intel_pstate_update_util_hwp(), so it can now be removed. Signed-off-by:
-
Len Brown authored
The goal of this change is to give users a uniform and meaningful result when they read /sys/...cpufreq/scaling_cur_freq on modern x86 hardware, as compared to what they get today. Modern x86 processors include the hardware needed to accurately calculate frequency over an interval -- APERF, MPERF, and the TSC. Here we provide an x86 routine to make this calculation on supported hardware, and use it in preference to any driver driver-specific cpufreq_driver.get() routine. MHz is computed like so: MHz = base_MHz * delta_APERF / delta_MPERF MHz is the average frequency of the busy processor over a measurement interval. The interval is defined to be the time between successive invocations of aperfmperf_khz_on_cpu(), which are expected to to happen on-demand when users read sysfs attribute cpufreq/scaling_cur_freq. As with previous methods of calculating MHz, idle time is excluded. base_MHz above is from TSC calibration global "cpu_khz". This x86 native method to calculate MHz returns a meaningful result no matter if P-states are controlled by hardware or firmware and/or if the Linux cpufreq sub-system is or is-not installed. When this routine is invoked more frequently, the measurement interval becomes shorter. However, the code limits re-computation to 10ms intervals so that average frequency remains meaningful. Discerning users are encouraged to take advantage of the turbostat(8) utility, which can gracefully handle concurrent measurement intervals of arbitrary length. Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
- Jun 23, 2017
-
-
Srinivas Pandruvada authored
In the current model the max/min perf limits are a fraction of current user space limits to the allowed max_freq or 100% for global limits. This results in wrong ratio limits calculation because of rounding issues for some user space limits. Initially we tried to solve this issue by issue by having more shift bits to increase precision. Still there are isolated cases where we still have error. This can be avoided by using ratios all together. Since the way we get cpuinfo.max_freq is by multiplying scaling factor to max ratio, we can easily keep the max/min ratios in terms of ratios and not fractions. For example: if the max ratio = 36 cpuinfo.max_freq = 36 * 100000 = 3600000 Suppose user space sets a limit of 1200000, then we can calculate max ratio limit as = 36 * 1200000 / 3600000 = 12 This will be correct for any user limits. The other advantage is that, we don't need to do any calculation in the fast path as ratio limit is already calculated via set_policy() callback. Signed-off-by:
-
Colin Ian King authored
pointer freq_table can be made static as it does not need to be in global scope. Cleans up sparse warning: "symbol 'freq_table' was not declared. Should it be static?" Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Krzysztof Kozlowski authored
Fix inconsistent indenting and unneeded white space in assignment. Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
-
Octavian Purdila authored
This fixes an issue with imx6ull where setting the frequency to 528Mhz would actually set the ARM clock to 324Mhz. Signed-off-by:
Octavian Purdila <octavian.purdila@nxp.com> Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Acked-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Tao Wang authored
Add the compatible string for supporting the generic device tree cpufreq-dt driver on Hisilicon's 3660 SoC. Signed-off-by:
Tao Wang <kevin.wangtao@hisilicon.com> Acked-by:
-
- Jun 12, 2017
-
-
Tomasz Wilczyński authored
Commit 27ed3cd2 (cpufreq: conservative: Fix the logic in frequency decrease checking) removed the 10 point substraction when comparing the load against down_threshold but did not remove the related limit for the down_threshold value. As a result, down_threshold lower than 11 is not allowed even though values from 1 to 10 do work correctly too. The comment ("cannot be lower than 11 otherwise freq will not fall") also does not apply after removing the substraction. For this reason, allow down_threshold to take any value from 1 to 99 and fix the related comment. Fixes: 27ed3cd2 (cpufreq: conservative: Fix the logic in frequency decrease checking) Signed-off-by:
Tomasz Wilczyński <twilczynski@naver.com> Acked-by:
-
- Jun 05, 2017
-
-
Rafael J. Wysocki authored
Commit c5a2ee7d (cpufreq: intel_pstate: Active mode P-state limits rework) incorrectly assumed that pstate.turbo_pstate would always be nonzero for CPU0 in min_perf_pct_min() if cpufreq_register_driver() had succeeded which may not be the case in virtualized environments. If that assumption doesn't hold, it leads to an early crash on boot in intel_pstate_register_driver(), so add a sanity check to min_perf_pct_min() to prevent the crash from happening. Fixes: c5a2ee7d (cpufreq: intel_pstate: Active mode P-state limits rework) Reported-and-tested-by:
Jongman Heo <jongman.heo@samsung.com> Signed-off-by:
-
Sudeep Holla authored
scpi_ops now provide APIs to get the transition_latency and to add OPPs to the devices making those logic redundant here. This patch makes use of those APIs and removes the redundant code in this driver. Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Acked-by:
Sudeep Holla <sudeep.holla@arm.com>
-
- May 29, 2017
-
-
Arvind Yadav authored
clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
-
David Arcari authored
For a driver that does not set the CPUFREQ_STICKY flag, if all of the ->init() calls fail, cpufreq_register_driver() should return an error. This will prevent the driver from loading. Fixes: ce1bcfe9 (cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUs) Cc: 4.0+ <stable@vger.kernel.org> # 4.0+ Signed-off-by:
David Arcari <darcari@redhat.com> Acked-by:
-
- May 28, 2017
-
-
Viresh Kumar authored
We need such a routine at two places already, lets create one. Signed-off-by:
Lukasz Luba <lukasz.luba@arm.com> Tested-by:
Eduardo Valentin <edubezval@gmail.com>
-
Viresh Kumar authored
The CPU cooling driver uses the cpufreq policy, to get clip_cpus, the frequency table, etc. Most of the callers of CPU cooling driver's registration routines have the cpufreq policy with them, but they only pass the policy->related_cpus cpumask. The __cpufreq_cooling_register() routine then gets the policy by itself and uses it. It would be much better if the callers can pass the policy instead directly. This also fixes a basic design flaw, where the policy can be freed while the CPU cooling driver is still active. Signed-off-by:
-
- May 26, 2017
-
-
Sebastian Andrzej Siewior authored
cpufreq holds get_online_cpus() while invoking cpuhp_setup_state_nocalls() to make subsys_interface_register() and the registration of hotplug calls atomic versus cpu hotplug. cpuhp_setup_state_nocalls() invokes get_online_cpus() as well. This is correct, but prevents the conversion of the hotplug locking to a percpu rwsem. Use cpuhp_setup/remove_state_nocalls_cpuslocked() to avoid the nested call. Convert *_online_cpus() to the new interfaces while at it. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Acked-by:
-
- May 23, 2017
-
-
Thomas Gleixner authored
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state check in pas_cpufreq_cpu_exit() to handle the extra states. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
-
- May 14, 2017
-
-
Arnd Bergmann authored
Moving the cooling code into the cpufreq driver caused a possible build failure when the cpu_thermal helper code is a loadable module or disabled: drivers/cpufreq/dbx500-cpufreq.o: In function `dbx500_cpufreq_ready': dbx500-cpufreq.c:(.text.dbx500_cpufreq_ready+0x4): undefined reference to `cpufreq_cooling_register' This adds the same dependency that we have in other cpufreq drivers, forcing the driver to be disabled when we can't possibly link it. Fixes: 19678ffb (cpufreq: dbx500: Manage cooling device from cpufreq driver) Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- May 12, 2017
-
-
Len Brown authored
intel_pstate exports sysfs attributes for setting and observing HWP.EPP. These attributes use strings to describe 4 operating states, and inside the driver, these strings are mapped to numerical register values. The authorative mapping between the strings and numerical HWP.EPP values are now globally defined in msr-index.h, replacing the out-dated mapping that were open-coded into intel_pstate.c new old string --- --- ------ 0 0 performance 128 64 balance_performance 192 128 balance_power 255 192 power Note that the HW and BIOS default value on most system is 128, which intel_pstate will now call "balance_performance" while it used to call it "balance_power". Signed-off-by:
-
- May 09, 2017
-
-
Kees Cook authored
While examining output from trial builds with -Wformat-security enabled, many strings were found that should be defined as "const", or as a char array instead of char pointer. This makes some static analysis easier, by producing fewer false positives. As these are all trivial changes, it seemed best to put them all in a single patch rather than chopping them up per maintainer. Link: http://lkml.kernel.org/r/20170405214711.GA5711@beast Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by: Jes Sorensen <jes@trained-monkey.org> [runner.c] Cc: Tony Lindgren <tony@atomide.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Maciej W. Rozycki" <macro@linux-mips.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Yisen Zhuang <yisen.zhuang@huawei.com> Cc: Salil Mehta <salil.mehta@huawei.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Jiri Slaby <jslaby@suse.com> Cc: Patrice Chotard <patrice.chotard@st.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Mugunthan V N <mugunthanvnm@ti.com> Cc: Felipe Balbi <felipe.balbi@linux.intel.com> Cc: Jarod Wilson <jarod@redhat.com> Cc: Florian Westphal <fw@strlen.de> Cc: Antonio Quartulli <a@unstable.cc> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Kejian Yan <yankejian@huawei.com> Cc: Daode Huang <huangdaode@hisilicon.com> Cc: Qianqian Xie <xieqianqian@huawei.com> Cc: Philippe Reynes <tremyfr@gmail.com> Cc: Colin Ian King <colin.king@canonical.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Christian Gromm <christian.gromm@microchip.com> Cc: Andrey Shvetsov <andrey.shvetsov@k2l.de> Cc: Jason Litzinger <jlitzingerdev@gmail.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Stephen Boyd authored
This typo is quite common. Fix it and add it to the spelling file so that checkpatch catches it earlier. Link: http://lkml.kernel.org/r/20170317011131.6881-2-sboyd@codeaurora.org Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
- Apr 20, 2017
-
-
David Howells authored
When the kernel is running in secure boot mode, we lock down the kernel to prevent userspace from modifying the running kernel image. Whilst this includes prohibiting access to things like /dev/mem, it must also prevent access by means of configuring driver modules in such a way as to cause a device to access or modify the kernel image. To this end, annotate module_param* statements that refer to hardware configuration and indicate for future reference what type of parameter they specify. The parameter parser in the core sees this information and can skip such parameters with an error message if the kernel is locked down. The module initialisation then runs as normal, but just sees whatever the default values for those parameters is. Note that we do still need to do the module initialisation because some drivers have viable defaults set in case parameters aren't specified and some drivers support automatic configuration (e.g. PNP or PCI) in addition to manually coded parameters. This patch annotates drivers in drivers/cpufreq/. Suggested-by:
Alan Cox <gnomes@lxorguk.ukuu.org.uk> Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
"Rafael J. Wysocki" <rjw@rjwysocki.net> Acked-by:
-
- Apr 19, 2017
-
-
Mikko Perttunen authored
Add a new cpufreq driver for Tegra186 (and likely later). The CPUs are organized into two clusters, Denver and A57, with two and four cores respectively. CPU frequency can be adjusted by writing the desired rate divisor and a voltage hint to a special per-core register. The frequency of each core can be set individually; however, this is just a hint as all CPUs in a cluster will run at the maximum rate of non-idle CPUs in the cluster. Signed-off-by:
Mikko Perttunen <mperttunen@nvidia.com> Acked-by:
-
