aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2016-04-01PM / OPP: Rename structures for clarityv4.1/topic/OPPv2Viresh Kumar
Stephen pointed out recently, that few structures always confuse him as they aren't named properly. And this patch tries to address that: Names are updated as: - device_opp or dev_opp -> opp_table - dev_opp_list -> opp_tables - dev_opp_list_lock -> opp_table_lock - device_list_opp -> opp_device (it was never a list, but a structure) - list_dev -> opp_dev - And similar changes in comments and function names as well. This also fixes checkpatch warnings that were generated with this patch. No functional changes. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> 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>
2016-04-01PM / OPP: Fix incorrect commentsViresh Kumar
Some comments were just copy/pasted from other sections and don't match to the routines they were added for. Fix 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>
2016-04-01PM / OPP: Initialize regulator pointer to an error valueViresh Kumar
We are currently required to do two checks for regulator pointer: IS_ERR() and IS_NULL(). And multiple instances are reported, about both of these not being used consistently and so resulting in crashes. Fix that by initializing regulator pointer with an error value and checking it only against an error. This makes code more consistent and more efficient. Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) Reported-and-tested-by: Jon Hunter <jonathanh@nvidia.com> Reported-and-tested-by: Tony Lindgren <tony@atomide.com> Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Initialize to -ENXIO ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Initialize u_volt_min/max to a valid valueViresh Kumar
We kept u_volt_min/max initialized to 0, when only the target voltage is present in DT, instead of the target/min/max triplet. This didn't go well with the regulator framework, as on few calls the min voltage was set to target and max was set to 0 and so resulted in a kernel crash like below: kernel BUG at ../drivers/regulator/core.c:216! [<c0684af4>] (regulator_check_voltage) from [<c06857ac>] (regulator_set_voltage_unlocked+0x58/0x230) [<c06857ac>] (regulator_set_voltage_unlocked) from [<c06859ac>] (regulator_set_voltage+0x28/0x54) [<c06859ac>] (regulator_set_voltage) from [<c0775b28>] (_set_opp_voltage+0x30/0x98) [<c0775b28>] (_set_opp_voltage) from [<c0776630>] (dev_pm_opp_set_rate+0xf0/0x28c) [<c0776630>] (dev_pm_opp_set_rate) from [<c096f784>] (__cpufreq_driver_target+0x184/0x2b4) [<c096f784>] (__cpufreq_driver_target) from [<c0973760>] (dbs_check_cpu+0x1b0/0x1f4) [<c0973760>] (dbs_check_cpu) from [<c0973f30>] (cpufreq_governor_dbs+0x324/0x5c4) [<c0973f30>] (cpufreq_governor_dbs) from [<c0970958>] (__cpufreq_governor+0xe4/0x1ec) [<c0970958>] (__cpufreq_governor) from [<c09711e0>] (cpufreq_init_policy+0x64/0x8c) [<c09711e0>] (cpufreq_init_policy) from [<c09718cc>] (cpufreq_online+0x2fc/0x708) [<c09718cc>] (cpufreq_online) from [<c0765ff0>] (subsys_interface_register+0x94/0xd8) [<c0765ff0>] (subsys_interface_register) from [<c0970530>] (cpufreq_register_driver+0x14c/0x19c) [<c0970530>] (cpufreq_register_driver) from [<c09746dc>] (dt_cpufreq_probe+0x70/0xec) [<c09746dc>] (dt_cpufreq_probe) from [<c076907c>] (platform_drv_probe+0x4c/0xb0) [<c076907c>] (platform_drv_probe) from [<c07678e0>] (driver_probe_device+0x214/0x2c0) [<c07678e0>] (driver_probe_device) from [<c0767a18>] (__driver_attach+0x8c/0x90) [<c0767a18>] (__driver_attach) from [<c0765c2c>] (bus_for_each_dev+0x68/0x9c) [<c0765c2c>] (bus_for_each_dev) from [<c0766d78>] (bus_add_driver+0x1a0/0x218) [<c0766d78>] (bus_add_driver) from [<c076810c>] (driver_register+0x78/0xf8) [<c076810c>] (driver_register) from [<c0301d74>] (do_one_initcall+0x90/0x1d8) [<c0301d74>] (do_one_initcall) from [<c1100e14>] (kernel_init_freeable+0x15c/0x1fc) [<c1100e14>] (kernel_init_freeable) from [<c0b27a0c>] (kernel_init+0x8/0xf0) [<c0b27a0c>] (kernel_init) from [<c0307d78>] (ret_from_fork+0x14/0x3c) Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2) Fix that by initializing u_volt_min/max to the target voltage in such cases. Reported-and-tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Fix NULL pointer dereference crash when disabling OPPsJon Hunter
Commit 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) causes a crash to happen on Tegra124 Jetson TK1 when using the DFLL clock source for the CPU. The DFLL manages the voltage itself and so there is no regulator specified for the OPPs and so we get a crash when we try to dereference the regulator pointer. Fix this by checking to see if the regulator IS_ERR_OR_NULL before dereferencing it. Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01cpufreq: dt: No need to allocate resources anymoreViresh Kumar
OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we still need to check for availability of resources for deferred probing. 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>
2016-04-01cpufreq: dt: No need to fetch voltage-toleranceViresh Kumar
Its already done by core and we don't need to get it anymore. And so, we don't need to get of node in cpufreq_init() anymore, move that to find_supply_name() instead. 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>
2016-04-01cpufreq: dt: Use dev_pm_opp_set_rate() to switch frequencyViresh Kumar
OPP core supports frequency/voltage changes based on the target frequency now, use that instead of open coding the same in cpufreq-dt driver. 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>
2016-04-01cpufreq: dt: Reuse dev_pm_opp_get_max_transition_latency()Viresh Kumar
OPP layer has all the information now to calculate transition latency (clock_latency + voltage_latency). Lets reuse the OPP layer helper dev_pm_opp_get_max_transition_latency() instead of open coding the same in cpufreq-dt driver. 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>
2016-04-01cpufreq: dt: Unsupported OPPs are already disabledViresh Kumar
The core already have a valid regulator set for the device opp and the unsupported OPPs are already disabled by the core. There is no need to repeat that in the user drivers, get rid 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>
2016-04-01cpufreq: dt: Pass regulator name to the OPP coreViresh Kumar
OPP core can handle the regulators by itself, and but it needs to know the name of the regulator to fetch. Add support for 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>
2016-04-01cpufreq: dt: OPP layers handles clock-latency for V1 bindings as wellViresh Kumar
"clock-latency" is handled by OPP layer for all bindings and so there is no need to make special calls for V1 bindings. Use dev_pm_opp_get_max_clock_latency() for both the cases. 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>
2016-04-01cpufreq: dt: Rename 'need_update' to 'opp_v1'Viresh Kumar
That's the real purpose of this field, i.e. to take special care of old OPP V1 bindings. Lets name it accordingly, so that it can be used elsewhere. 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>
2016-04-01cpufreq: dt: Convert few pr_debug/err() calls to dev_dbg/err()Viresh Kumar
We have the device structure available now, lets use it for better print messages. 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>
2016-04-01PM / OPP: Add dev_pm_opp_set_rate()Viresh Kumar
This adds a routine, dev_pm_opp_set_rate(), responsible for configuring power-supply and clock source for an OPP. The OPP is found by matching against the target_freq passed to the routine. This shall replace similar code present in most of the OPP users and help simplify them a lot. 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>
2016-04-01PM / OPP: Manage device clkViresh Kumar
OPP core has got almost everything now to manage device's OPP transitions, the only thing left is device's clk. Get that as well. 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>
2016-04-01PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindingsViresh Kumar
V2 bindings have better support for clock-latency and voltage-tolerance and doesn't need special care. To use callbacks, like dev_pm_opp_get_max_{transition|volt}_latency(), irrespective of the bindings, the core needs to know clock-latency/voltage-tolerance for the earlier bindings. This patch reads clock-latency/voltage-tolerance from the device node, irrespective of the bindings (to keep it simple) and use them only for V1 bindings. 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>
2016-04-01PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()Viresh Kumar
In few use cases (like: cpufreq), it is desired to get the maximum latency for changing OPPs. Add support for 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>
2016-04-01PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()Viresh Kumar
In few use cases (like: cpufreq), it is desired to get the maximum voltage latency for changing OPPs. Add support for 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>
2016-04-01PM / OPP: Disable OPPs that aren't supported by the regulatorViresh Kumar
Disable any OPPs where the connected regulator isn't able to provide the specified voltage. 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>
2016-04-01PM / OPP: get/put regulators from OPP coreViresh Kumar
This allows the OPP core to request/free the regulator resource, attached to a device OPP. The regulator device is fetched using the name provided by the driver, while calling: dev_pm_opp_set_regulator(). This will work for both OPP-v1 and v2 bindings. This is a preliminary step for moving the OPP switching logic into the OPP core. 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>
2016-04-01cpufreq: cpufreq-dt: avoid uninitialized variable warnings:Arnd Bergmann
gcc warns quite a bit about values returned from allocate_resources() in cpufreq-dt.c: cpufreq-dt.c: In function 'cpufreq_init': cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here cpufreq-dt.c: In function 'dt_cpufreq_probe': cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized] cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here The problem is that it's slightly hard for gcc to follow return codes across PTR_ERR() calls. This patch uses explicit assignments to the "ret" variable to make it easier for gcc to verify that the code is actually correct, without the need to add a bogus initialization. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Use snprintf() instead of sprintf()Viresh Kumar
sprintf() can access memory outside of the range of the character array, and is risky in some situations. The driver specified prop_name string can be longer than NAME_MAX here (only an attacker will do that though) and so blindly copying it into the character array of size NAME_MAX isn't safe. Instead we must use snprintf() here. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01cpufreq-dt: fix handling regulator_get_voltage() resultAndrzej Hajda
The function can return negative values so it should be assigned to signed type. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci. Link: http://permalink.gmane.org/gmane.linux.kernel/2038576 Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Set cpu_dev->id in cpumask firstPi-Cheng Chen
Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that share the same OPP table. This might be helpful when handling cpumask without the original CPU bitfield set. Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Fix parsing of opp-microvolt and opp-microamp propertiesBartlomiej Zolnierkiewicz
Commit 01fb4d3c39d3 ("PM / OPP: Parse 'opp-<prop>-<name>' bindings") broke support for parsing standard opp-microvolt and opp-microamp properties. Fix it by setting 'name' string to proper value for !prop cases. Fixes: 01fb4d3c39d3 ("PM / OPP: Parse 'opp-<prop>-<name> 'bindings") Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Parse 'opp-<prop>-<name>' bindingsViresh Kumar
OPP bindings (for few properties) allow a platform to choose a value/range among a set of available options. The options are present as opp-<prop>-<name>, where the platform needs to supply the <name> string. The OPP properties which allow such an option are: opp-microvolt and opp-microamp. Add support to the OPP-core to parse these bindings, by introducing dev_pm_opp_{set|put}_prop_name() APIs. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Parse 'opp-supported-hw' bindingViresh Kumar
OPP bindings allow a platform to enable OPPs based on the version of the hardware they are used for. Add support to the OPP-core to parse these bindings, by introducing dev_pm_opp_{set|put}_supported_hw() APIs. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Add missing doc commentsViresh Kumar
Few doc-style comments were missing, add them. Rearrange another one to match the sequence within the structure. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Rename OPP nodes as opp@<opp-hz>Viresh Kumar
It would be better to name OPP nodes as opp@<opp-hz> as that will ensure that multiple DT nodes don't contain the same frequency. Of course we expect the writer to name the node with its opp-hz frequency and not any other frequency. And that will let the compile error out if multiple nodes are using the same opp-hz frequency. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Remove 'operating-points-names' bindingViresh Kumar
These aren't used until now by any DT files and wouldn't be used now as we have a better scheme in place now, i.e. opp-property-<name> properties. Remove the (useless) binding without breaking ABI. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Add {opp-microvolt|opp-microamp}-<name> bindingViresh Kumar
Depending on the version of hardware or its properties, which are only known at runtime, various properties of the OPP can change. For example, an OPP with frequency 1.2 GHz, may have different voltage/current requirements based on the version of the hardware it is running on. In order to not replicate the same OPP tables for varying values of all such fields, this commit introduces the concept of opp-property-<name>. The <name> can be chosen by the platform at runtime, and OPPs will be initialized depending on that name string. Currently support is extended for the following properties: - opp-microvolt-<name> - opp-microamp-<name> If the name string isn't provided by the platform, or if it is provided but doesn't match the properties present in the OPP node, we will fall back to the original properties without the -<name> string, if they are available. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Add "opp-supported-hw" bindingViresh Kumar
We may want to enable only a subset of OPPs, from the bigger list of OPPs, based on what version of the hardware we are running on. This would enable us to not duplicate OPP tables for every version of the hardware we support. To enable that, this patch defines a new property 'opp-supported-hw'. It can support any number of hierarchy levels of the versions the hardware follows. And based on the selected hardware versions, we can pick only the relevant OPPs at runtime. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Create a directory for opp bindingsViresh Kumar
More platform specific extended opp bindings will follow and it would be easy to manage them with a directory for opp. Lets create that and move the existing opp bindings into it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Update bindings to make opp-hz a 64 bit valueViresh Kumar
With a 32 bit value, the maximum frequency that the bindings can support is ~ 4 GHz. And that might fall short of what newer systems may have. Allow opp-hz to be a 64 bit big-endian value. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Add binding for 'opp-suspend'Viresh Kumar
On few platforms, for power efficiency, we want the device to be configured for a specific OPP while we put the device in suspend state. Add an optional property in operating-points-v2 bindings for that. Suggested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Nishanth Menon <nm@ti.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Allow multiple OPP tables to be passed via DTViresh Kumar
On some platforms (Like Qualcomm's SoCs), it is not decided until runtime on what OPPs to use. The OPP tables can be fixed at compile time, but which table to use is found out only after reading some efuses (sort of an prom) and knowing characteristics of the SoC. To support such platform we need to pass multiple OPP tables per device and hardware should be able to choose one and only one table out of those. Update operating-points-v2 bindings to support that. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Add new bindings to address shortcomings of existing bindingsViresh Kumar
Current OPP (Operating performance point) device tree bindings have been insufficient due to the inflexible nature of the original bindings. Over time, we have realized that Operating Performance Point definitions and usage is varied depending on the SoC and a "single size (just frequency, voltage) fits all" model which the original bindings attempted and failed. The proposed next generation of the bindings addresses by providing a expandable binding for OPPs and introduces the following common shortcomings seen with the original bindings: - Getting clock/voltage/current rails sharing information between CPUs. Shared by all cores vs independent clock per core vs shared clock per cluster. - Support for specifying current levels along with voltages. - Support for multiple regulators. - Support for turbo modes. - Other per OPP settings: transition latencies, disabled status, etc.? - Expandability of OPPs in future. This patch introduces new bindings "operating-points-v2" to get these problems solved. Refer to the bindings for more details. We now have multiple versions of OPP binding and only one of them should be used per device. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01Revert "PM / OPP: Create a directory for opp bindings"Viresh Kumar
This reverts commit d799a9490ebce9299f102ed34f4901e5dd2a9e07. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2016-04-01PM / OPP: Add debugfs supportViresh Kumar
This patch adds debugfs support to OPP layer to export OPPs and their properties for all the devices. This creates a top level directory: /sys/kernel/debug/opp and then device specific directories (based on device names) inside it. For example: 'cpu0', 'cpu1', etc.. If multiple devices share the OPP table, then the real directory is created only for the first device. For all others, links are created to the real directory. Inside the device specific directory, a separate directory is created for each OPP. And within that files per opp property. 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>
2016-04-01PM / OPP: Add opp_rcu_lockdep_assert() to _find_device_opp()Viresh Kumar
_find_device_opp() should be called with rcu-read lock or dev_opp_list_lock held. Add the opp_rcu_lockdep_assert() check to make sure caller have taken appropriate locks. Fix comment over the routine as well. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Hold dev_opp_list_lock for writersViresh Kumar
Writers need to update OPP device and their list with dev_opp_list_lock mutex held, which was missed at few places. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.3 <stable@vger.kernel.org> # 4.3 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Protect updates to list_dev with mutexViresh Kumar
dev_opp_list_lock is used everywhere to protect device and OPP lists, but dev_pm_opp_set_sharing_cpus() is missed somehow. And instead we used rcu-lock, which wouldn't help here as we are adding a new list_dev. This also fixes a problem where we have called kzalloc(..., GFP_KERNEL) from within rcu-lock, which isn't allowed as kzalloc can sleep when called with GFP_KERNEL. With CONFIG_DEBUG_ATOMIC_SLEEP set, we get following lockdep-splat: include/linux/rcupdate.h:578 Illegal context switch in RCU read-side critical section! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 5 locks held by swapper/0/1: #0: (&dev->mutex){......}, at: [<c02f68f4>] __driver_attach+0x48/0x98 #1: (&dev->mutex){......}, at: [<c02f6904>] __driver_attach+0x58/0x98 #2: (cpu_hotplug.lock){++++++}, at: [<c00249d0>] get_online_cpus+0x40/0xb0 #3: (subsys mutex#5){+.+.+.}, at: [<c02f4f8c>] subsys_interface_register+0x44/0xdc #4: (rcu_read_lock){......}, at: [<c0305c80>] dev_pm_opp_set_sharing_cpus+0x0/0x1e4 stack backtrace: CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 4.3.0-rc7-00047-g81f5932958a8 #59 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c0016874>] (unwind_backtrace) from [<c001355c>] (show_stack+0x10/0x14) [<c001355c>] (show_stack) from [<c022553c>] (dump_stack+0x94/0xbc) [<c022553c>] (dump_stack) from [<c004904c>] (___might_sleep+0x24c/0x298) [<c004904c>] (___might_sleep) from [<c00f07e4>] (kmem_cache_alloc+0xe8/0x164) [<c00f07e4>] (kmem_cache_alloc) from [<c0305354>] (_add_list_dev+0x30/0x58) [<c0305354>] (_add_list_dev) from [<c0305d50>] (dev_pm_opp_set_sharing_cpus+0xd0/0x1e4) [<c0305d50>] (dev_pm_opp_set_sharing_cpus) from [<c040eda4>] (cpufreq_init+0x4cc/0x62c) [<c040eda4>] (cpufreq_init) from [<c040a964>] (cpufreq_online+0xbc/0x73c) [<c040a964>] (cpufreq_online) from [<c02f4fe0>] (subsys_interface_register+0x98/0xdc) [<c02f4fe0>] (subsys_interface_register) from [<c040a640>] (cpufreq_register_driver+0x110/0x17c) [<c040a640>] (cpufreq_register_driver) from [<c040ef64>] (dt_cpufreq_probe+0x60/0x8c) [<c040ef64>] (dt_cpufreq_probe) from [<c02f8084>] (platform_drv_probe+0x44/0xa4) [<c02f8084>] (platform_drv_probe) from [<c02f67c0>] (driver_probe_device+0x208/0x2f4) [<c02f67c0>] (driver_probe_device) from [<c02f6940>] (__driver_attach+0x94/0x98) [<c02f6940>] (__driver_attach) from [<c02f4c1c>] (bus_for_each_dev+0x68/0x9c) Reported-by: Michael Turquette <mturquette@baylibre.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.3 <stable@vger.kernel.org> # 4.3 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Propagate error properly from dev_pm_opp_set_sharing_cpus()Viresh Kumar
We are returning 0 even in case of errors, fix it. Fixes: 8d4d4e98acd6 ("PM / OPP: Add helpers for initializing CPU OPPs") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 4.3 <stable@vger.kernel.org> # 4.3 Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Parse all power-supply related bindings togetherViresh Kumar
Move all DT parsing for the power supplies to a single function, rather than keeping them at separate places. This will help manage things properly. 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>
2016-04-01PM / OPP: Rename routines specific to old bindings with _v1Viresh Kumar
Clearly distinguish routines based on what version of bindings they parse. We have already postfixed routines properly with _v2 for new bindings. Postfix the older ones now with _v1. 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>
2016-04-01PM / OPP: Improve print messages with pr_fmtViresh Kumar
To identify OPP core's print messages easily, prefix them with KBUILD_MODNAME. 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>
2016-04-01PM / OPP: passing NULL to PTR_ERR()Dan Carpenter
The code was using PTR_ERR(NULL) which causes a static checker warning. I have fixed up the printks and changed the return to -ENOENT. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Move cpu specific code to opp/cpu.cViresh Kumar
Move cpu device specific code out of generic opp library, and add it to cpu.c. Along with that, create a core-internal opp.h header, which will be used to share structures and function prototypes within opp core. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-04-01PM / OPP: Move opp core to its own directoryViresh Kumar
OPP code is expanding and is already present in multiple directories (cpufreq and power). Lets move it to its own directory, to manage it better. This also moves/renames the cpufreq_opp file to cpu.c, as it will contain helpers for cpu device. Its not just about cpufreq, other frameworks can use OPPs as well. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>