aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* cpufreq: Do not clear real_cpus mask on policy initRafael J. Wysocki2017-02-15
| | | | | | | | | | | 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
* cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platformsDave Gerlach2017-02-09
| | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: ti: Add cpufreq driver to determine available OPPs at runtimeDave Gerlach2017-02-09
| | | | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Documentation: dt: add bindings for ti-cpufreqDave Gerlach2017-02-09
| | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge OPP material for v4.11 to satisfy dependencies.Rafael J. Wysocki2017-02-09
|\
| * PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp APIDave Gerlach2017-02-09
| | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Make _find_opp_table_unlocked() staticWei Yongjun2017-02-07
| | | | | | | | | | | | | | | | | | | | | | | | 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: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Update Documentation to remove RCU specific bitsViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | Update OPP documentation to remove the RCU specific bits. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Simplify dev_pm_opp_get_max_volt_latency()Viresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Simplify _opp_set_availability()Viresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Move away from RCU lockingViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Take kref from _find_opp_table()Viresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Update OPP users to put referenceViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> [Devfreq] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Add 'struct kref' to struct dev_pm_oppViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Use dev_pm_opp_get_opp_table() instead of _add_opp_table()Viresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Migrate all users of _add_opp_table() to use dev_pm_opp_get_opp_table() to guarantee that the OPP table doesn't get freed while being used. Also update _managed_opp() to get the reference to the OPP table. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Now that _add_opp_table(), _remove_opp_table() and the unlocked release routines aren't used anymore, remove them. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Take reference of the OPP table while adding/removing OPPsViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | Take reference of the OPP table while adding and removing OPPs, that helps us remove special checks in _remove_opp_table(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Return opp_table from dev_pm_opp_set_*() routinesViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we have proper kernel reference infrastructure in place for OPP tables, use it to guarantee that the OPP table isn't freed while being used by the callers of dev_pm_opp_set_*() APIs. Make them all return the pointer to the OPP table after taking its reference and put the reference back with dev_pm_opp_put_*() APIs. Now that the OPP table wouldn't get freed while these routines are executing after dev_pm_opp_get_opp_table() is called, there is no need to take opp_table_lock. Drop them as well. Remove the rcu specific comments from these routines as they aren't relevant anymore. Note that prototypes of dev_pm_opp_{set|put}_regulators() were already updated by another patch. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Add 'struct kref' to OPP tableViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add kref to struct opp_table for easier accounting of the OPP table. Note that the new routine dev_pm_opp_get_opp_table() takes the reference from under the opp_table_lock, which guarantees that the OPP table doesn't get freed unless dev_pm_opp_put_opp_table() is called for the OPP table. Two separate release mechanisms are added: locked and unlocked. In unlocked version the routines aren't required to take/drop opp_table_lock as the callers have already done that. This is required to avoid breaking git bisect, otherwise we may get lockdeps between commits. Once all the users of OPP table are updated the unlocked version shall be removed. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Add per OPP table mutexViresh Kumar2017-01-30
| | | | | | | | | | | | | | | | | | | | | | | | Add per OPP table lock to protect opp_table->opp_list. Note that at few places opp_list is used under the rcu_read_lock() and so a mutex can't be added there for now. This will be fixed by a later patch. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Split out part of _add_opp_table() and _remove_opp_table()Viresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | Split out parts of _add_opp_table() and _remove_opp_table() into separate routines. This improves readability as well. Should result in no functional changes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Don't expose srcu_head to register notifiersViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | Let the OPP core provide helpers to register notifiers for any device, instead of exposing srcu_head outside of the core. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Rename dev_pm_opp_get_suspend_opp() and return OPP rateViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | | | There is only one user of dev_pm_opp_get_suspend_opp() and that uses it to get the OPP rate for the suspend_opp. Rename dev_pm_opp_get_suspend_opp() as dev_pm_opp_get_suspend_opp_freq() and return the rate directly from it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Don't allocate OPP table from _opp_allocate()Viresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no point in trying to find/allocate the table for every OPP that is added for a device. It would be far more efficient to allocate the table only once and pass its pointer to the routines that add the OPP entry. Locking is removed from _opp_add_static_v2() and _opp_add_v1() now as the callers call them with that lock already held. Call to _remove_opp_table() routine is also removed from _opp_free() now, as opp_table isn't allocated from within _opp_allocate(). This is handled by the routines which created the OPP table in the first place. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Rename and split _dev_pm_opp_remove_table()Viresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | | | Later patches would want to remove OPP table (and its OPPs) using the opp_table pointer instead of 'dev'. In order to prepare for that, rename _dev_pm_opp_remove_table() as _dev_pm_opp_find_and_remove_table() split out part of it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Add light weight _opp_free() routineViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OPPs which are never successfully added using _opp_add() are not required to be freed with the _opp_remove() routine, as a simple kfree() is enough for them. Introduce a new light weight routine _opp_free(), which will do that. That also helps us removing the 'notify' parameter to _opp_remove(), which isn't required anymore. Note that _opp_free() contains a call to _remove_opp_table() as the OPP table might have been added for this very OPP only. The _remove_opp_table() routine returns quickly if there are more OPPs in the table. This will be simplified in later patches though. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Error out on failing to add static OPPs for v1 bindingsViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | The code adding static OPPs for V2 bindings already does so. Make the V1 bindings specific code behave the same. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Rename _allocate_opp() to _opp_allocate()Viresh Kumar2017-01-27
| | | | | | | | | | | | | | | | Make the naming consistent with how other routines are named. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Remove useless TODOViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | This TODO doesn't make sense anymore as we have all the information in a single OPP table. Remove it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * PM / OPP: Fix memory leak while adding duplicate OPPsViresh Kumar2017-01-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two types of duplicate OPPs that get different behavior from the core: A) An earlier OPP is marked 'available' and has same freq/voltages as the new one. B) An earlier OPP with same frequency, but is marked 'unavailable' OR doesn't have same voltages as the new one. The OPP core returns 0 for the first one, but -EEXIST for the second. While the OPP core returns 0 for the first case, its callers don't free the newly allocated OPP structure which isn't used anymore. Fix that by returning -EBUSY instead of 0, but make the callers return 0 eventually. As this isn't a critical fix, its not getting marked for stable kernel. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: qoriq: Don't look at clock implementation detailsTang Yuantian2017-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: qoriq: add ARM64 SoCs supportTang Yuantian2017-02-09
| | | | | | | | | | | | | | | | Add ARM64 config to Kconfig to enable CPU frequency feature on NXP ARM64 SoCs. Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: brcmstb-avs-cpufreq: remove unnecessary platform_set_drvdata()Wei Yongjun2017-02-08
| | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: s3c2416: double free on driver init error pathDan Carpenter2017-02-08
| | | | | | | | | | | | | | | | | | | | | | The "goto err_armclk;" error path already does a clk_put(s3c_freq->hclk); so this is a double free. Fixes: 34ee55075265 ([CPUFREQ] Add S3C2416/S3C2450 cpufreq driver) Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | MIPS: BMIPS: enable CPUfreqMarkus Mayer2017-02-08
| | | | | | | | | | | | | | | | Enable all applicable CPUfreq options. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: bmips-cpufreq: CPUfreq driver for Broadcom's BMIPS SoCsMarkus Mayer2017-02-08
| | | | | | | | | | | | | | | | | | | | Add the MIPS CPUfreq driver. This driver currently supports CPUfreq on BMIPS5xxx-based SoCs. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | BMIPS: Enable prerequisites for CPUfreq in MIPS Kconfig.Markus Mayer2017-02-08
| | | | | | | | | | | | | | | | Turn on CPU_SUPPORTS_CPUFREQ and MIPS_EXTERNAL_TIMER for BMIPS. 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>
* | MIPS: BMIPS: Update defconfigMarkus Mayer2017-02-08
| | | | | | | | | | | | | | | | Ran "make savedefconfig" to bring bmips_stb_defconfig up to date. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge back earlier cpufreq changes for v4.11.Rafael J. Wysocki2017-02-08
|\ \
| * | cpufreq: Fix typos in commentsViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | - s/freqnency/frequency/ - s/accomodating/accommodating/ Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: intel_pstate: Calculate guaranteed performance for HWPSrinivas Pandruvada2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: intel_pstate: Make HWP limits compatible with legacySrinivas Pandruvada2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: intel_pstate: Lower frequency than expected under no_turboSrinivas Pandruvada2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: intel_pstate: Operation mode control from sysfsRafael J. Wysocki2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rafael.j.wysocki@intel.com>
| * | cpufreq: intel_pstate: Expose global sysfs attributes upfrontRafael J. Wysocki2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | 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: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: Remove CPUFREQ_START notifier eventViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | Its not used anymore, remove it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPI: processor_perflib: Simplify code and stop using CPUFREQ_STARTViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: powernv: Add boost files to export ultra-turbo frequenciesShilpasri G Bhat2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: Documentation: Updates based on current codeViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: Documentation: Minor reformattingViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | This patch doesn't change the content of the documentation, but rather reformat it to make it more readable. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config optionViresh Kumar2017-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-30 05:14:31 -0400