- Feb 18, 2017
-
-
Markus Mayer authored
Add maintainer information for bmips-cpufreq.c. Signed-off-by:
Markus Mayer <mmayer@broadcom.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Feb 16, 2017
-
-
Arnd Bergmann authored
Without the Kconfig dependency, we can get this warning: warning: ACPI_CPPC_CPUFREQ selects ACPI_CPPC_LIB which has unmet direct dependencies (ACPI && ACPI_PROCESSOR) Fixes: 5477fb3b (ACPI / CPPC: Add a CPUFreq driver for use with CPPC) Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Paul Gortmaker authored
The Kconfig currently controlling compilation of this code is: drivers/cpufreq/Kconfig.arm:config ARM_TI_CPUFREQ drivers/cpufreq/Kconfig.arm: bool "Texas Instruments CPUFreq support" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple traces of modular infrastructure use, 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
If new_policy is set in cpufreq_online(), the policy object has just been created and its real_cpus mask has been zeroed on allocation, and the driver's ->init() callback should not touch it. It doesn't need to be cleared again, so don't do that. Signed-off-by:
-
- Feb 10, 2017
-
-
Dave Gerlach authored
Some TI platforms, specifically those in the am33xx, am43xx, dra7xx, and am57xx families of SoCs can make use of the ti-cpufreq driver to selectively enable OPPs based on the exact configuration in use. The ti-cpufreq is given the responsibility of creating the cpufreq-dt platform device when the driver is in use so drop am33xx and dra7xx from the cpufreq-dt-platdev driver so it is not created twice. Acked-by:
Dave Gerlach <d-gerlach@ti.com> Signed-off-by:
-
Dave Gerlach authored
Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families, have different OPPs available for the MPU depending on which specific variant of the SoC is in use. This can be determined through use of the revision and an eFuse register present in the silicon. Introduce a ti-cpufreq driver that can read the aformentioned values and provide them as version matching data to the opp framework. Through this the opp-supported-hw dt binding that is part of the operating-points-v2 table can be used to indicate availability of OPPs for each device. This driver also creates the "cpufreq-dt" platform_device after passing the version matching data to the OPP framework so that the cpufreq-dt handles the actual cpufreq implementation. Even without the necessary data to pass the version matching data the driver will still create this device to maintain backwards compatibility with operating-points v1 tables. Acked-by:
-
Dave Gerlach authored
Add the device tree bindings document for the TI CPUFreq/OPP driver on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2 binding allows us to provide an opp-supported-hw property for each OPP to define when it is available. This driver is responsible for reading and parsing registers to determine which OPPs can be selectively enabled based on the specific SoC in use by matching against the opp-supported-hw data. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rafael J. Wysocki authored
-
Dave Gerlach authored
Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add it to include/linux/pm_opp.h to allow other drivers, such as platform OPP and cpufreq drivers, to make use of it. Acked-by:
-
- Feb 09, 2017
-
-
Tang Yuantian authored
Get the CPU clock's potential parent clocks from the clock interface itself, rather than manually parsing the clocks property to find a phandle, looking at the clock-names property of that, and assuming that those are valid parent clocks for the cpu clock. This is necessary now that the clocks are generated based on the clock driver's knowledge of the chip rather than a fragile device-tree description of the mux options. We can now rely on the clock driver to ensure that the mux only exposes options that are valid. The cpufreq driver was currently being overly conservative in some cases -- for example, the "min_cpufreq = get_bus_freq()" restriction only applies to chips with erratum A-004510, and whether the freq_mask used on p5020 is needed depends on the actual frequencies of the PLLs (FWIW, p5040 has a similar limitation but its .freq_mask was zero) -- and the frequency mask mechanism made assumptions about particular parent clock indices that are no longer valid. Signed-off-by:
Scott Wood <scottwood@nxp.com> Signed-off-by:
Tang Yuantian <yuantian.tang@nxp.com> Acked-by:
-
Tang Yuantian authored
Add ARM64 config to Kconfig to enable CPU frequency feature on NXP ARM64 SoCs. Signed-off-by:
-
Wei Yongjun authored
The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Acked-by:
-
Dan Carpenter authored
The "goto err_armclk;" error path already does a clk_put(s3c_freq->hclk); so this is a double free. Fixes: 34ee5507 ([CPUFREQ] Add S3C2416/S3C2450 cpufreq driver) Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Acked-by:
-
Markus Mayer authored
Enable all applicable CPUfreq options. Signed-off-by:
-
Markus Mayer authored
Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on BMIPS5xxx-based SoCs. Signed-off-by:
-
Markus Mayer authored
Turn on CPU_SUPPORTS_CPUFREQ and MIPS_EXTERNAL_TIMER for BMIPS. Signed-off-by:
-
Markus Mayer authored
Ran "make savedefconfig" to bring bmips_stb_defconfig up to date. Signed-off-by:
-
Rafael J. Wysocki authored
-
- Feb 07, 2017
-
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/base/power/opp/core.c:49:18: warning: symbol '_find_opp_table_unlocked' was not declared. Should it be static? Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Acked-by:
-
- Feb 04, 2017
-
-
Viresh Kumar authored
- s/freqnency/frequency/ - s/accomodating/accommodating/ Signed-off-by:
-
Srinivas Pandruvada authored
Some Kabylake desktop processors may not reach max turbo when running in HWP mode, even if running under sustained 100% utilization. This occurs when the HWP.EPP (Energy Performance Preference) is set to "balance_power" (0x80) -- the default on most systems. It occurs because the platform BIOS may erroneously enable an energy-efficiency setting -- MSR_IA32_POWER_CTL BIT-EE, which is not recommended to be enabled on this SKU. On the failing systems, this BIOS issue was not discovered when the desktop motherboard was tested with Windows, because the BIOS also neglects to provide the ACPI/CPPC table, that Windows requires to enable HWP, and so Windows runs in legacy P-state mode, where this setting has no effect. Linux' intel_pstate driver does not require ACPI/CPPC to enable HWP, and so it runs in HWP mode, exposing this incorrect BIOS configuration. There are several ways to address this problem. First, Linux can also run in legacy P-state mode on this system. As intel_pstate is how Linux enables HWP, booting with "intel_pstate=disable" will run in acpi-cpufreq/ondemand legacy p-state mode. Or second, the "performance" governor can be used with intel_pstate, which will modify HWP.EPP to 0. Or third, starting in 4.10, the /sys/devices/system/cpu/cpufreq/policy*/energy_performance_preference attribute in can be updated from "balance_power" to "performance". Or fourth, apply this patch, which fixes the erroneous setting of MSR_IA32_POWER_CTL BIT_EE on this model, allowing the default configuration to function as designed. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by:
Len Brown <len.brown@intel.com> Cc: 4.6+ <stable@vger.kernel.org> # 4.6+ Signed-off-by:
-
Srinivas Pandruvada authored
When HWP is active, turbo activation ratio is not used to calculate max non turbo ratio. But on these systems the max non turbo ratio is decided by config TDP settings. This change removes usage of MSR_TURBO_ACTIVATION_RATIO for HWP systems, instead directly use TDP ratios, when more than one TDPs are available. Signed-off-by:
-
Srinivas Pandruvada authored
Under HWP the performance limits are calculated using max_perf_pct and min_perf_pct using possible performance, not available performance. The available performance can be reduced by no_turbo setting. To make compatible with legacy mode, use max/min performance percentage with respect to available performance. Signed-off-by:
-
Srinivas Pandruvada authored
When turbo is not disabled by BIOS, but user disabled from intel P-State sysfs and changes max/min using cpufreq sysfs, the resultant frequency is lower than what user requested. The reason for this, when the perf limits are calculated in set_policy() callback, they are with reference to max cpu frequency (turbo frequency ), but when enforced in the intel_pstate_get_min_max() they are with reference to max available performance as documented in the intel_pstate documentation (in this case max non turbo P-State). This needs similar change as done in intel_cpufreq_verify_policy() for passive mode. Set policy->cpuinfo.max_freq based on the turbo status. Signed-off-by:
-
Rafael J. Wysocki authored
Make it possible to change the operation mode of intel_pstate with the help of a new sysfs attribute called "status". There are three possible configurations that can be selected using this attribute: "off" - The driver is not in use at this time. "active" - The driver works as a P-state governor (default). "passive" - The driver works as a regular cpufreq one and collaborates with the generic cpufreq governors (it sets P-states as requested by those governors). [This is the same mode the driver can be started in by passing intel_pstate=passive in the kernel command line.] The current setting is returned by reads from this attribute. Writing one of the above strings to it changes the operation mode as indicated by that string, if possible. If HW-managed P-states (HWP) feature is enabled, it is not possible to change the driver's operation mode and attempts to write to this attribute will fail. Signed-off-by: -
Rafael J. Wysocki authored
Expose the intel_pstate's global sysfs attributes before registering the driver to prepare for the addition of an attribute that also will have to work if the driver is not registered. Signed-off-by: -
Viresh Kumar authored
Its not used anymore, remove it. Signed-off-by:
-
Viresh Kumar authored
acpi_processor_ppc_notifier() can live without using CPUFREQ_START (which is gonna be removed soon), as it is only used while setting ignore_ppc to 0. This can be done with the help of "ignore_ppc < 0" check alone. The notifier function anyway ignores all events except CPUFREQ_ADJUST and dropping CPUFREQ_START wouldn't harm at all. Once CPUFREQ_START event is removed from the cpufreq core, acpi_processor_ppc_notifier() will get called only for CPUFREQ_NOTIFY or CPUFREQ_ADJUST event. Drop the return statement from the first if block to make sure we don't ignore any such events. Signed-off-by:
-
Shilpasri G Bhat authored
In P8+, Workload Optimized Frequency(WOF) provides the capability to boost the cpu frequency based on the utilization of the other cpus running in the chip. The On-Chip-Controller(OCC) firmware will control the achievability of these frequencies depending on the power headroom available in the chip. Currently the ultra-turbo frequencies provided by this feature are exported along with the turbo and sub-turbo frequencies as scaling_available_frequencies. This patch will export the ultra-turbo frequencies separately as scaling_boost_frequencies in WOF enabled systems. This patch will add the boost sysfs file which can be used to disable/enable ultra-turbo frequencies. Signed-off-by:
Shilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com> Reviewed-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Acked-by:
-
Viresh Kumar authored
The cpufreq core has gone though lots of updates in recent times, but on many occasions the documentation wasn't updated along with the code. This patch tries to catchup the documentation with the code. Also add Rafael and Viresh as the contributors to the documentation. Based on a patch from Claudio Scordino. Signed-off-by:
Claudio Scordino <claudio@evidence.eu.com> Signed-off-by:
-
Viresh Kumar authored
This patch doesn't change the content of the documentation, but rather reformat it to make it more readable. Signed-off-by:
-
Viresh Kumar authored
This doesn't have any benefit apart from saving a small amount of memory when it is disabled. The ifdef hackery in the code makes it dirty unnecessarily. Clean it up by removing the Kconfig option completely. Few defconfigs are also updated and CONFIG_CPU_FREQ_STAT_DETAILS is replaced with CONFIG_CPU_FREQ_STAT now in them, as users wanted stats to be enabled. Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by:
Chanwoo Choi <cw00.choi@samsung.com> Acked-by:
-
Viresh Kumar authored
Those were added by: commit fcd7af91 ("cpufreq: stats: handle cpufreq_unregister_driver() and suspend/resume properly") but aren't used anymore since: commit 1aefc75b ("cpufreq: stats: Make the stats code non-modular"). Remove them. Also remove the redundant parameter to the respective routines. Signed-off-by:
-
- Jan 30, 2017
-
-
Viresh Kumar authored
Update OPP documentation to remove the RCU specific bits. Signed-off-by:
-
Viresh Kumar authored
dev_pm_opp_get_max_volt_latency() calls _find_opp_table() two times effectively. Merge _get_regulator_count() into dev_pm_opp_get_max_volt_latency() to avoid that. Signed-off-by:
-
Viresh Kumar authored
As we don't use RCU locking anymore, there is no need to replace an earlier OPP node with a new one. Just update the existing one. Signed-off-by:
-
Viresh Kumar authored
The RCU locking isn't well suited for the OPP core. The RCU locking fits better for reader heavy stuff, while the OPP core have at max one or two readers only at a time. Over that, it was getting very confusing the way RCU locking was used with the OPP core. The individual OPPs are mostly well handled, i.e. for an update a new structure was created and then that replaced the older one. But the OPP tables were updated directly all the time from various parts of the core. Though they were mostly used from within RCU locked region, they didn't had much to do with RCU and were governed by the mutex instead. And that mixed with the 'opp_table_lock' has made the core even more confusing. Now that we are already managing the OPPs and the OPP tables with kernel reference infrastructure, we can get rid of RCU locking completely and simplify the code a lot. Remove all RCU references from code and comments. Acquire opp_table->lock while parsing the list of OPPs though. Signed-off-by:
-
Viresh Kumar authored
Take reference of the OPP table from within _find_opp_table(). Also update the callers of _find_opp_table() to call dev_pm_opp_put_opp_table() after they have used the OPP table. Note that _find_opp_table() increments the reference under the opp_table_lock. Now that the OPP table wouldn't get freed until the callers of _find_opp_table() call dev_pm_opp_put_opp_table(), there is no need to take the opp_table_lock or rcu_read_lock() around it. Drop them. Signed-off-by:
-
Viresh Kumar authored
This patch updates dev_pm_opp_find_freq_*() routines to get a reference to the OPPs returned by them. Also updates the users of dev_pm_opp_find_freq_*() routines to call dev_pm_opp_put() after they are done using the OPPs. As it is guaranteed the that OPPs wouldn't get freed while being used, the RCU read side locking present with the users isn't required anymore. Drop it as well. This patch also updates all users of devfreq_recommended_opp() which was returning an OPP received from the OPP core. Note that some of the OPP core routines have gained rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs within them. Signed-off-by: -
Viresh Kumar authored
Add kref to struct dev_pm_opp for easier accounting of the OPPs. Note that the OPPs are freed under the opp_table->lock mutex only. Signed-off-by:
-
