summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/ti-cpufreq.c
AgeCommit message (Collapse)Author
2020-02-12cpufreq: ti-cpufreq: Add support for OPP_PLUSLokesh Vutla
DRA762 SoC introduces OPP_PLUS which runs at 1.8GHz. Add support for this OPP in ti-cpufreq driver. Acked-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-10-10cpufreq: ti-cpufreq: Add support for AM3517Adam Ford
The AM3517 only lists 600MHz @ 1.2V, but the register values for 0x4830A204 = 1b86 802f, it seems like am3517 might be a derivative of the omap36 which OPPs would be OPP50 (300 MHz) and OPP100 (600 MHz). This patch simply adds the am3517 to the compatible table similar to a mix of the omap3430 and omap3430 structure. Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-10-10ARM: dts: omap36xx: using OPP1G needs to control the abb_ldoH. Nikolaus Schaller
See DM3730,DM275 data sheet (SPRS685B) footnote (6) in Table 4-19 which says that ABB must be switched to FBB mode when using the OPP1G. The LOD definition abb_mpu_iva already exists so that we need to add plumbing for vbb-supply = <&abb_mpu_iva> and define two voltage vectors for each OPP so that the abb LDO is also updated by the ti-cpufreq driver. We also must switch the ti_cpufreq_soc_data to multi_regulator. Note: reading out the abb reglator voltage to verify that it does do transitions can be done by cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.*/microvolts Likewise, read the twl4030 provided VDD voltage by cat /sys/devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:regulator-vdd1/regulator/regulator.*/microvolts Note: to check if the ABB FBB is enabled/disabled, check registers PRM_LDO_ABB_CTRL 0x483072F4 bit 3:0 1=bypass 5=FBB PRM_LDO_ABB_SETUP 0x483072F0 0x00=bypass 0x11=FBB e.g. /dev/mem opened. Memory mapped at address 0xb6fe4000. Value at address 0x483072F4 (0xb6fe42f4): 0x3205 /dev/mem opened. Memory mapped at address 0xb6f89000. Value at address 0x483072F4 (0xb6f892f4): 0x3201 Note: omap34xx and am3517 have/need no comparable LDO or mechanism. Suggested-by: Adam Ford <aford173@gmail.com> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-10-10cpufreq: ti-cpufreq: omap36xx use "cpu0","vbb" if run in multi_regulator modeH. Nikolaus Schaller
In preparation for using the multi_regulator capability of this driver for handling the ABB LDO for OPP1G of the omap36xx we have to take care that the (legacy) vdd-supply name is cpu0-supply = <&vcc>; To do this we add another field to the SoC description table which optionally can specify a list of regulator names. For omap36xx we define "cpu0-supply" and "vbb-supply". The default remains "vdd-supply" and "vbb-supply". Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-10-10cpufreq: ti-cpufreq: add support for omap34xx and omap36xxH. Nikolaus Schaller
This adds code and tables to read the silicon revision and eFuse (speed binned / 720 MHz grade) bits for selecting opp-v2 table entries. Since these bits are not always part of the syscon register range (like for am33xx, am43, dra7), we add code to directly read the register values using ioremap() if syscon access fails. The format of the opp-supported-hw entries is that it has two 32 bit bitfields. E.g.: opp-supported-hw = <0xffffffff 3> The first value is matched against the bit position of the silicon revision which is (see TRM) omap34xx: BIT(0) ES1.0 BIT(1) ES2.0 BIT(2) ES2.1 BIT(3) ES3.0 BIT(4) ES3.1 BIT(7) ES3.1.2 omap36xx: BIT(0) ES1.0 BIT(1) ES1.1 BIT(2) ES1.2 The second value is matched against the speed grade eFuse: BIT(0) no high speed OPP BIT(1) high speed OPP This means for the example above that it is always enabled while e.g. opp-supported-hw = <0x1 2> enables the OPP only for ES1.0 BIT(0) and if the high speed eFuse is set BIT(1). Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Tony Lindgren <tony@atomide.com> Tested-by: Adam Ford <aford173@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-07-30cpufreq: ti-cpufreq: Mark expected switch fall-throughGustavo A. R. Silva
Mark switch cases where we are expecting to fall through. This patch fixes the following warning (Building: arm): drivers/cpufreq/ti-cpufreq.c: In function ‘dra7_efuse_xlate’: drivers/cpufreq/ti-cpufreq.c:79:20: warning: this statement may fall through [-Wimplicit-fallthrough=] calculated_efuse |= DRA7_EFUSE_HIGH_MPU_OPP; drivers/cpufreq/ti-cpufreq.c:80:2: note: here case DRA7_EFUSE_HAS_OD_MPU_OPP: ^~~~ Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2019-05-30treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 174Thomas Gleixner
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 655 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Richard Fontana <rfontana@redhat.com> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070034.575739538@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-11-19cpufreq: ti-cpufreq: Only register platform_device when supportedDave Gerlach
Currently the ti-cpufreq driver blindly registers a 'ti-cpufreq' to force the driver to probe on any platforms where the driver is built in. However, this should only happen on platforms that actually can make use of the driver. There is already functionality in place to match the SoC compatible so let's factor this out into a separate call and make sure we find a match before creating the ti-cpufreq platform device. Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-06cpufreq: ti-cpufreq: Use devres managed API in probe()Suman Anna
The ti_cpufreq_probe() function uses regular kzalloc to allocate the ti_cpufreq_data structure and kfree for freeing this memory on failures. Simplify this code by using the devres managed API. Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-06-06cpufreq: ti-cpufreq: Fix an incorrect error return valueSuman Anna
Commit 05829d9431df (cpufreq: ti-cpufreq: kfree opp_data when failure) has fixed a memory leak in the failure path, however the patch returned a positive value on get_cpu_device() failure instead of the previous negative value. Fix this incorrect error return value properly. Fixes: 05829d9431df (cpufreq: ti-cpufreq: kfree opp_data when failure) Cc: 4.14+ <stable@vger.kernel.org> # v4.14+ Signed-off-by: Suman Anna <s-anna@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-10cpufreq: ti-cpufreq: Use builtin_platform_driver()Viresh Kumar
This driver can not be built as a module and there is no need of the platform driver unregister part. Use builtin_platform_driver() instead of module_platform_driver(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-17cpufreq: ti-cpufreq: Add support for multiple regulatorsDave Gerlach
Some platforms, like those in the DRA7 and AM57 families, require the scaling of multiple regulators in order to properly support higher OPPs. Let the ti-cpufreq driver determine when this is required and pass the appropriate regulator names to the OPP core so that they can be properly managed. 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>
2017-12-17cpufreq: ti-cpufreq: Convert to module_platform_driverDave Gerlach
ti-cpufreq will be responsible for calling dev_pm_opp_set_regulators on platforms that require AVS and ABB regulator support so we must be able to defer probe if regulators are not yet available, so change ti-cpufreq to be a module_platform_driver to allow for probe defer. 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>
2017-10-14cpufreq: ti-cpufreq: add missing of_node_put()Zumeng Chen
call of_node_put to release the refcount of np. Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-03cpufreq: ti-cpufreq: kfree opp_data when failureZumeng Chen
memory leakage was found by kmemleak. opp_data needs to be freed when failure, including fail_put_node. unreferenced object 0xccdd4c40 (size 64): comm "swapper", pid 1, jiffies 4294938465 (age 888.520s) hex dump (first 32 bytes): 00 7c 00 c1 98 69 d8 ce 00 24 03 ce 00 24 03 ce .|...i...$...$.. 20 35 23 c1 00 00 00 00 00 00 00 00 00 00 00 00 5#............. backtrace: [<c028fb64>] kmem_cache_alloc_trace+0x2c4/0x3cc [<c076d5f0>] ti_cpufreq_probe+0x6c/0x334 [<c068d6e4>] platform_drv_probe+0x60/0xc0 [<c068b384>] driver_probe_device+0x218/0x2c4 [<c068b5a4>] __device_attach_driver+0xa8/0xdc [<c0689340>] bus_for_each_drv+0x70/0xa4 [<c068b020>] __device_attach+0xc0/0x124 [<c068b634>] device_initial_probe+0x1c/0x20 [<c068a3b8>] bus_probe_device+0x94/0x9c [<c0688300>] device_add+0x404/0x590 [<c068d408>] platform_device_add+0x11c/0x230 [<c068df40>] platform_device_register_full+0x10c/0x128 [<c076d578>] ti_cpufreq_init+0x44/0x50 [<c01017c4>] do_one_initcall+0x54/0x180 [<c0e00fe0>] kernel_init_freeable+0x270/0x33c [<c093f2bc>] kernel_init+0x18/0x124 Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-09-20cpufreq: ti-cpufreq: Support additional am43xx platformsDave Gerlach
Rather than letting the ti-cpufreq driver match against 'ti,am4372' machine compatible during probe let's match against 'ti,am43' so that we can support both 'ti,am4372' and 'ti,am438x' platforms which both match to this compatible. Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-25cpufreq: ti: Fix 'of_node_put' being called twice in error handling pathChristophe Jaillet
If 'dev_pm_opp_set_supported_hw()' fails, 'opp_data->opp_node' refcount will be decremented 2 times. One, just a few lines above, and another one in the error handling path. Fix it by simply moving the 'of_node_put' call of the normal path. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-16cpufreq: make ti-cpufreq explicitly non-modularPaul Gortmaker
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: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-09cpufreq: ti: Add cpufreq driver to determine available OPPs at runtimeDave Gerlach
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>