UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity
OpenCloudOS-Kernel/drivers/cpufreq/Kconfig.arm

294 lines
8.1 KiB
Plaintext
Raw Normal View History

[CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/ According to discussion of the ARM arch subsystem migration, ARM cpufreq drivers move to drivers/cpufreq. So this patch adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 and EXYNOS4210 cpufreq driver compile in there. As a note, otherw will be moved. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-06-02 05:18:22 +08:00
#
# ARM CPU Frequency scaling drivers
#
cpufreq: ARM: sort the Kconfig menu Group all the related big LITTLE configuration together and sort the other entries in alphabetic order. Also fixing tab vs space issue while mofifying these entries. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 01:05:35 +08:00
config ACPI_CPPC_CPUFREQ
tristate "CPUFreq driver based on the ACPI CPPC spec"
depends on ACPI_PROCESSOR
select ACPI_CPPC_LIB
help
This adds a CPUFreq driver which uses CPPC methods
as described in the ACPIv5.1 spec. CPPC stands for
Collaborative Processor Performance Controls. It
is based on an abstract continuous scale of CPU
performance values which allows the remote power
processor to flexibly optimize for power and
performance. CPPC relies on power management firmware
support for its operation.
If in doubt, say N.
cpufreq: Add DVFS support for Armada 37xx This patch adds DVFS support for the Armada 37xx SoCs There are up to four CPU frequency loads for Armada 37xx controlled by the hardware. This driver associates the CPU load level to a frequency, then the hardware will switch while selecting a load level. The hardware also can associate a voltage for each level (AVS support) but it is not yet supported Tested-by: Andre Heider <a.heider@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 23:00:05 +08:00
config ARM_ARMADA_37XX_CPUFREQ
tristate "Armada 37xx CPUFreq support"
cpufreq: armada-37xx: driver relies on cpufreq-dt Armada-37xx driver registers a cpufreq-dt driver. Not having CONFIG_CPUFREQ_DT selected leads to a silent abort during the probe. Prevent that situation by having the former depending on the latter. Fixes: 92ce45fb875d7 (cpufreq: Add DVFS support for Armada 37xx) Cc: 4.16+ <stable@vger.kernel.org> # 4.16+ Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-04-24 23:45:06 +08:00
depends on ARCH_MVEBU && CPUFREQ_DT
cpufreq: Add DVFS support for Armada 37xx This patch adds DVFS support for the Armada 37xx SoCs There are up to four CPU frequency loads for Armada 37xx controlled by the hardware. This driver associates the CPU load level to a frequency, then the hardware will switch while selecting a load level. The hardware also can associate a voltage for each level (AVS support) but it is not yet supported Tested-by: Andre Heider <a.heider@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 23:00:05 +08:00
help
This adds the CPUFreq driver support for Marvell Armada 37xx SoCs.
The Armada 37xx PMU supports 4 frequency and VDD levels.
cpufreq: arm_big_little: make vexpress driver depend on bL core driver Currently vexpress big LITTLE driver selects ARM_BIG_LITTLE_CPUFREQ, so if CONFIG_BIG_LITTLE isn't enabled and CONFIG_ARM_VEXPRESS_SPC_CPUFREQ is enabled, we get the following build warnings: warning: (ARM_VEXPRESS_SPC_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && (ARM || ARM64) && ARM && BIG_LITTLE && ARM_CPU_TOPOLOGY && HAVE_CLK) To fix this, make ARM_VEXPRESS_SPC_CPUFREQ depend on ARM_BIG_LITTLE_CPUFREQ instead of selecting it. This also moves the entry for ARM_VEXPRESS_SPC_CPUFREQ along with other big LITTLE config entries. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-14 14:40:54 +08:00
# big LITTLE core layer and glue drivers
cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue big LITTLE is ARM's new Architecture focussing power/performance needs of modern world. More information about big LITTLE can be found here: http://www.arm.com/products/processors/technologies/biglittleprocessing.php http://lwn.net/Articles/481055/ In order to keep cpufreq support for all big LITTLE platforms simple/generic, this patch tries to add a generic cpufreq driver layer for all big LITTLE platforms. The driver is divided into two parts: - Core driver: Generic and shared across all big LITTLE SoC's - Glue drivers: Per platform drivers providing ops to the core driver This patch adds in a generic glue driver which would extract information from Device Tree. Future SoC's can either reuse the DT glue or write their own depending on the need. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-01 20:57:49 +08:00
config ARM_BIG_LITTLE_CPUFREQ
cpufreq: ARM big LITTLE: Fix Kconfig entries This fixes usage of "depends on" and "select" options in Kconfig for ARM big LITTLE cpufreq driver. Otherwise we get these warnings: warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-04 14:33:54 +08:00
tristate "Generic ARM big LITTLE CPUfreq driver"
cpufreq: drop ARM_BIG_LITTLE_CPUFREQ support for ARM64 ARM_BIG_LITTLE_CPUFREQ depends on topology_physical_package_id to get the cluster id which inturn provides the information on related cpus in the same performance domain. ARM64 core doesn't provide the cluster information as it's not architecturally defined. There are no users of this driver in ARM64 after the one and only user(SCPI) moved away. So let's ban the usage of this driver for ARM64. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-10-24 21:44:57 +08:00
depends on ARM_CPU_TOPOLOGY && HAVE_CLK
cpufreq: arm_big_little: Add support to register a cpufreq cooling device Register passive cooling devices when initialising cpufreq on big.LITTLE systems. If the device tree provides a dynamic power coefficient for the CPUs then the bound cooling device will support the extensions that allow it to be used with all the existing thermal governors including the power allocator governor. A cooling device will be created per individual frequency domain and can be bound to thermal zones via the thermal DT bindings. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-11-17 20:06:23 +08:00
# if CPU_THERMAL is on and THERMAL=m, ARM_BIT_LITTLE_CPUFREQ cannot be =y
depends on !CPU_THERMAL || THERMAL
cpufreq: Select PM_OPP rather than depending on it PM_OPP is a helper library used by several of the existing cpufreq drivers. Some of the drivers select this symbol while others depend on it and rely on the architecture to enable it. Make this behaviour more consistent and obvious by having all the drivers select the symbol. This will also allow better build coverage of the affected drivers. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-12 06:12:27 +08:00
select PM_OPP
cpufreq: ARM big LITTLE: Fix Kconfig entries This fixes usage of "depends on" and "select" options in Kconfig for ARM big LITTLE cpufreq driver. Otherwise we get these warnings: warning: (ARM_DT_BL_CPUFREQ) selects ARM_BIG_LITTLE_CPUFREQ which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && ARM && ARM_CPU_TOPOLOGY) Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-04 14:33:54 +08:00
help
This enables the Generic CPUfreq driver for ARM big.LITTLE platforms.
cpufreq: ARM big LITTLE: Add generic cpufreq driver and its DT glue big LITTLE is ARM's new Architecture focussing power/performance needs of modern world. More information about big LITTLE can be found here: http://www.arm.com/products/processors/technologies/biglittleprocessing.php http://lwn.net/Articles/481055/ In order to keep cpufreq support for all big LITTLE platforms simple/generic, this patch tries to add a generic cpufreq driver layer for all big LITTLE platforms. The driver is divided into two parts: - Core driver: Generic and shared across all big LITTLE SoC's - Glue drivers: Per platform drivers providing ops to the core driver This patch adds in a generic glue driver which would extract information from Device Tree. Future SoC's can either reuse the DT glue or write their own depending on the need. Signed-off-by: Sudeep KarkadaNagesha <sudeep.karkadanagesha@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-01 20:57:49 +08:00
cpufreq: ARM: sort the Kconfig menu Group all the related big LITTLE configuration together and sort the other entries in alphabetic order. Also fixing tab vs space issue while mofifying these entries. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 01:05:35 +08:00
config ARM_SCPI_CPUFREQ
tristate "SCPI based CPUfreq driver"
cpufreq: scpi: Fix incorrect arm_big_little config dependency Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) removed the SCPI cpufreq dependency on arm_big_little cpufreq driver. However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ which is clearly wrong. This patch removes that unnecessary Kconfig dependency. Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Reported-by: Quentin Perret <quentin.perret@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-23 23:54:42 +08:00
depends on ARM_SCPI_PROTOCOL && COMMON_CLK_SCPI
cpufreq: scpi: Add thermal dependency A built-in scpi cpufreq driver cannot link against a modular thermal framework: drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_ready': scpi-cpufreq.c:(.text+0x4c): undefined reference to `of_cpufreq_cooling_register' drivers/cpufreq/scpi-cpufreq.o: In function `scpi_cpufreq_exit': scpi-cpufreq.c:(.text+0x9c): undefined reference to `cpufreq_cooling_unregister' This adds a Kconfig dependency that makes sure this configuration is not possible, while allowing all configurations that can work. Note that disabling CPU_THERMAL means we don't care about the THERMAL dependency. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-03-13 19:45:40 +08:00
depends on !CPU_THERMAL || THERMAL
cpufreq: ARM: sort the Kconfig menu Group all the related big LITTLE configuration together and sort the other entries in alphabetic order. Also fixing tab vs space issue while mofifying these entries. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 01:05:35 +08:00
help
cpufreq: scpi: Fix incorrect arm_big_little config dependency Commit 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) removed the SCPI cpufreq dependency on arm_big_little cpufreq driver. However the Kconfig entry still depends on ARM_BIG_LITTLE_CPUFREQ which is clearly wrong. This patch removes that unnecessary Kconfig dependency. Fixes: 343a8d17fa8d (cpufreq: scpi: remove arm_big_little dependency) Reported-by: Quentin Perret <quentin.perret@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-23 23:54:42 +08:00
This adds the CPUfreq driver support for ARM platforms using SCPI
protocol for CPU power management.
cpufreq: ARM: sort the Kconfig menu Group all the related big LITTLE configuration together and sort the other entries in alphabetic order. Also fixing tab vs space issue while mofifying these entries. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-14 01:05:35 +08:00
This driver uses SCPI Message Protocol driver to interact with the
firmware providing the CPU DVFS functionality.
config ARM_VEXPRESS_SPC_CPUFREQ
tristate "Versatile Express SPC based CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && ARCH_VEXPRESS_SPC
help
This add the CPUfreq driver support for Versatile Express
big.LITTLE platforms using SPC for power management.
cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs This driver supports voltage and frequency scaling on Broadcom STB SoCs using AVS firmware with DFS and DVFS support. Actual frequency or voltage scaling is done exclusively by the AVS firmware. The driver merely provides a standard CPUfreq interface to other kernel components and userland, and instructs the AVS firmware to perform frequency or voltage changes on its behalf. Signed-off-by: Markus Mayer <mmayer@broadcom.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-10-28 05:05:35 +08:00
config ARM_BRCMSTB_AVS_CPUFREQ
tristate "Broadcom STB AVS CPUfreq driver"
depends on ARCH_BRCMSTB || COMPILE_TEST
default y
help
Some Broadcom STB SoCs use a co-processor running proprietary firmware
("AVS") to handle voltage and frequency scaling. This driver provides
a standard CPUfreq interface to to the firmware.
Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
config ARM_HIGHBANK_CPUFREQ
tristate "Calxeda Highbank-based"
cpufreq: cpu0: rename driver and internals to 'cpufreq_dt' The naming convention of this driver was always under the scanner, people complained that it should have a more generic name than cpu0, as it manages all CPUs that are sharing clock lines. Also, in future it will be modified to support any number of clusters with separate clock/voltage lines. Lets rename it to 'cpufreq_dt' from 'cpufreq_cpu0'. Tested-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>
2014-09-09 22:28:03 +08:00
depends on ARCH_HIGHBANK && CPUFREQ_DT && REGULATOR
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
default m
help
This adds the CPUFreq driver for Calxeda Highbank SoC
based boards.
If in doubt, say N.
config ARM_IMX6Q_CPUFREQ
cpufreq: imx6q-cpufreq driver is reused on i.MX6 series SoCs The imx6q-cpufreq driver nowadays is not only running on imx6q but also other i.MX6 series SoCs like imx6dl and imx6sl. Update Kconfig prompt and help text to make it clear to users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-20 10:12:16 +08:00
tristate "Freescale i.MX6 cpufreq support"
depends on ARCH_MXC
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
depends on REGULATOR_ANATOP
cpufreq: imx6q: Select PM_OPP PM_OPP is a library used by several of the existing cpufreq drivers. ARM IMX6Q cpufreq driver uses this library for its functionality. Thus, it should be selected in Kconfig. Reported-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Nicolas Del Piano <ndel314@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-14 05:59:00 +08:00
select PM_OPP
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
help
cpufreq: imx6q-cpufreq driver is reused on i.MX6 series SoCs The imx6q-cpufreq driver nowadays is not only running on imx6q but also other i.MX6 series SoCs like imx6dl and imx6sl. Update Kconfig prompt and help text to make it clear to users. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-20 10:12:16 +08:00
This adds cpufreq driver support for Freescale i.MX6 series SoCs.
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
If in doubt, say N.
config ARM_KIRKWOOD_CPUFREQ
cpufreq: Remove ARCH_KIRKWOOD dependency mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu. ARCH_MVEBU is sufficient. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net> Link: https://lkml.kernel.org/r/1409417172-6846-8-git-send-email-andrew@lunn.ch Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-08-31 00:46:12 +08:00
def_bool MACH_KIRKWOOD
cpufreq: ARM: Arrange drivers in alphabetical order Normally we keep drivers in alphabetical inside Kconfig and Makefile and over time this was broken for ARM cpufreq drivers. Fix it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:09 +08:00
help
This adds the CPUFreq driver for Marvell Kirkwood
SoCs.
cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with single cluster and this hardware is also compatible with the existing driver through enabling CPU frequency feature with operating-points-v2 bindings. Also, this driver actually supports all MediaTek SoCs, the Kconfig menu entry and file name itself should be updated with more generic name to drop "MT8173" Signed-off-by: Sean Wang <sean.wang@mediatek.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-18 14:01:43 +08:00
config ARM_MEDIATEK_CPUFREQ
tristate "CPU Frequency scaling support for MediaTek SoCs"
cpufreq: mediatek: Add MT8173 cpufreq driver Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation: 100mV < Vsram - Vproc < 200mV which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC. 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>
2015-08-19 10:05:06 +08:00
depends on ARCH_MEDIATEK && REGULATOR
cpufreq: mediatek: allow building as a module The MT8173 cpufreq driver can currently only be built-in, but it has a Kconfig dependency on the thermal core. THERMAL can be a loadable module, which in turn makes this driver impossible to build. It is nicer to make the cpufreq driver a module as well, so this patch turns the option in to a 'tristate' and adapts the dependency accordingly. The driver has no module_exit() function, so it will continue to not support unloading, but it can be built as a module and loaded at runtime now. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 5269e7067cd6 (cpufreq: Add ARM_MT8173_CPUFREQ dependency on THERMAL) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-01 00:04:21 +08:00
depends on !CPU_THERMAL || THERMAL
cpufreq: mediatek: Add MT8173 cpufreq driver Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation: 100mV < Vsram - Vproc < 200mV which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC. 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>
2015-08-19 10:05:06 +08:00
select PM_OPP
help
cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC MT2701/MT7623 is a 32-bit ARMv7 based quad-core (4 * Cortex-A7) with single cluster and this hardware is also compatible with the existing driver through enabling CPU frequency feature with operating-points-v2 bindings. Also, this driver actually supports all MediaTek SoCs, the Kconfig menu entry and file name itself should be updated with more generic name to drop "MT8173" Signed-off-by: Sean Wang <sean.wang@mediatek.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-18 14:01:43 +08:00
This adds the CPUFreq driver support for MediaTek SoCs.
cpufreq: mediatek: Add MT8173 cpufreq driver Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and 2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage inputs, Vproc and Vsram are supplied by two regulators. For the big cluster, two regulators come from different PMICs. In this case, when scaling voltage inputs of the cluster, the voltages of two regulator inputs need to be controlled by software explicitly under the SoC specific limitation: 100mV < Vsram - Vproc < 200mV which is called 'voltage tracking' mechanism. And when scaling the frequency of cluster clock input, the input MUX need to be parented to another "intermediate" stable PLL first and reparented to the original PLL once the original PLL is stable at the target frequency. This patch implements those mechanisms to enable CPU DVFS support for Mediatek MT8173 SoC. 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>
2015-08-19 10:05:06 +08:00
cpufreq: OMAP driver depends CPUfreq tables The OMAP driver depends on CPUfreq table support for creating a table of frequencies from the OPP layer. Ensure that it's build to avoid link-time errors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [khilman@ti.com: make user-selectable, but default y] Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-02-16 03:01:11 +08:00
config ARM_OMAP2PLUS_CPUFREQ
bool "TI OMAP2+"
cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only builds for OMAP2+ platforms. This 'depends on' was in the original patch from Russell King, but was erroneously removed by me when making this option user-selectable in commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.) This patch remedies that. Apologies to Russell King for breaking his originally working patch. Also, thanks to Grazvydas Ignotas for reporting the same problem. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-04-14 04:32:30 +08:00
depends on ARCH_OMAP2PLUS
cpufreq: OMAP driver depends CPUfreq tables The OMAP driver depends on CPUfreq table support for creating a table of frequencies from the OPP layer. Ensure that it's build to avoid link-time errors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [khilman@ti.com: make user-selectable, but default y] Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-02-16 03:01:11 +08:00
default ARCH_OMAP2PLUS
cpufreq: Add Kryo CPU scaling driver In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, the CPU frequency subset and voltage value of each OPP varies based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables defines the voltage and frequency value based on the msm-id in SMEM and speedbin blown in the efuse combination. The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC to provide the OPP framework with required information. This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. Signed-off-by: Ilia Lin <ilialin@codeaurora.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-30 10:39:28 +08:00
config ARM_QCOM_CPUFREQ_KRYO
cpufreq: kryo: allow building as a loadable module Building the kryo cpufreq driver while QCOM_SMEM is a loadable module results in a link error: drivers/cpufreq/qcom-cpufreq-kryo.o: In function `qcom_cpufreq_kryo_probe': qcom-cpufreq-kryo.c:(.text+0xbc): undefined reference to `qcom_smem_get' The problem is that Kconfig ignores interprets the dependency as met when the dependent symbol is a 'bool' one. By making it 'tristate', it will be forced to be a module here, which builds successfully. Fixes: 46e2856b8e18 (cpufreq: Add Kryo CPU scaling driver) 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>
2018-06-05 19:44:24 +08:00
tristate "Qualcomm Kryo based CPUFreq"
cpufreq: Add Kryo CPU scaling driver In Certain QCOM SoCs like apq8096 and msm8996 that have KRYO processors, the CPU frequency subset and voltage value of each OPP varies based on the silicon variant in use. Qualcomm Process Voltage Scaling Tables defines the voltage and frequency value based on the msm-id in SMEM and speedbin blown in the efuse combination. The qcom-cpufreq-kryo driver reads the msm-id and efuse value from the SoC to provide the OPP framework with required information. This is used to determine the voltage and frequency value for each OPP of operating-points-v2 table when it is parsed by the OPP framework. Signed-off-by: Ilia Lin <ilialin@codeaurora.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-30 10:39:28 +08:00
depends on ARM64
depends on QCOM_QFPROM
depends on QCOM_SMEM
select PM_OPP
help
This adds the CPUFreq driver for Qualcomm Kryo SoC based boards.
If in doubt, say N.
cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2013-04-04 20:54:15 +08:00
config ARM_S3C_CPUFREQ
bool
help
Internal configuration node for common cpufreq on Samsung SoC
config ARM_S3C24XX_CPUFREQ
bool "CPUfreq driver for Samsung S3C24XX series CPUs (EXPERIMENTAL)"
depends on ARCH_S3C24XX
select ARM_S3C_CPUFREQ
help
This enables the CPUfreq driver for the Samsung S3C24XX family
of CPUs.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
config ARM_S3C24XX_CPUFREQ_DEBUG
bool "Debug CPUfreq Samsung driver core"
depends on ARM_S3C24XX_CPUFREQ
help
Enable s3c_freq_dbg for the Samsung S3C CPUfreq core
config ARM_S3C24XX_CPUFREQ_IODEBUG
bool "Debug CPUfreq Samsung driver IO timing"
depends on ARM_S3C24XX_CPUFREQ
help
Enable s3c_freq_iodbg for the Samsung S3C CPUfreq core
config ARM_S3C24XX_CPUFREQ_DEBUGFS
bool "Export debugfs for CPUFreq"
depends on ARM_S3C24XX_CPUFREQ && DEBUG_FS
help
Export status information via debugfs.
config ARM_S3C2410_CPUFREQ
bool
depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2410
select S3C2410_CPUFREQ_UTILS
help
CPU Frequency scaling support for S3C2410
config ARM_S3C2412_CPUFREQ
bool
depends on ARM_S3C24XX_CPUFREQ && CPU_S3C2412
default y
select S3C2412_IOTIMING
help
CPU Frequency scaling support for S3C2412 and S3C2413 SoC CPUs.
[CPUFREQ] Add S3C2416/S3C2450 cpufreq driver The S3C2416/S3C2450 SoCs support two sources for the armclk. The first source is the so called armdiv which divides the msysclk down to provide necessary cpu rates. In this mode the core voltage must be always at 1.3V. The frequency from the armdiv is not allowed to be lower than the hclk frequency. In the second mode the armclk can be sourced directly from the hclk in the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv isn't used at all. Also in this mode the core voltage may be lowered. Existing hardware and tests with it suggest 1.0V as sufficient. When changing the clock source to the armdiv from the hclk, the SoC shows stability issues if the new frequency is higher than the current hclk frequency. Hence the driver always forces the armdiv to the hclk frequency before the source change and lets the cpufreq issue another set_target call for higher frequencies. To mark the hclk frequency as lower as the corresponding armdiv frequency it is set 1MHz below the real frequency. This lets the cpufreq framework change between 133MHz based on hclk and 133MHz based on armdiv at will. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Andrey Gusakov <dron0gus@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-02-16 18:42:32 +08:00
config ARM_S3C2416_CPUFREQ
bool "S3C2416 CPU Frequency scaling support"
depends on CPU_S3C2416
help
This adds the CPUFreq driver for the Samsung S3C2416 and
S3C2450 SoC. The S3C2416 supports changing the rate of the
armdiv clock source and also entering a so called dynamic
voltage scaling mode in which it is possible to reduce the
cpufreq: Kconfig: Fix spelling errors Fix 4 spelling errors in help sections. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-23 03:40:10 +08:00
core voltage of the CPU.
[CPUFREQ] Add S3C2416/S3C2450 cpufreq driver The S3C2416/S3C2450 SoCs support two sources for the armclk. The first source is the so called armdiv which divides the msysclk down to provide necessary cpu rates. In this mode the core voltage must be always at 1.3V. The frequency from the armdiv is not allowed to be lower than the hclk frequency. In the second mode the armclk can be sourced directly from the hclk in the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv isn't used at all. Also in this mode the core voltage may be lowered. Existing hardware and tests with it suggest 1.0V as sufficient. When changing the clock source to the armdiv from the hclk, the SoC shows stability issues if the new frequency is higher than the current hclk frequency. Hence the driver always forces the armdiv to the hclk frequency before the source change and lets the cpufreq issue another set_target call for higher frequencies. To mark the hclk frequency as lower as the corresponding armdiv frequency it is set 1MHz below the real frequency. This lets the cpufreq framework change between 133MHz based on hclk and 133MHz based on armdiv at will. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Andrey Gusakov <dron0gus@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-02-16 18:42:32 +08:00
If in doubt, say N.
config ARM_S3C2416_CPUFREQ_VCORESCALE
drivers/cpufreq: remove depends on CONFIG_EXPERIMENTAL The CONFIG_EXPERIMENTAL config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it from any "depends on" lines in Kconfigs. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-10-03 02:16:53 +08:00
bool "Allow voltage scaling for S3C2416 arm core"
depends on ARM_S3C2416_CPUFREQ && REGULATOR
[CPUFREQ] Add S3C2416/S3C2450 cpufreq driver The S3C2416/S3C2450 SoCs support two sources for the armclk. The first source is the so called armdiv which divides the msysclk down to provide necessary cpu rates. In this mode the core voltage must be always at 1.3V. The frequency from the armdiv is not allowed to be lower than the hclk frequency. In the second mode the armclk can be sourced directly from the hclk in the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv isn't used at all. Also in this mode the core voltage may be lowered. Existing hardware and tests with it suggest 1.0V as sufficient. When changing the clock source to the armdiv from the hclk, the SoC shows stability issues if the new frequency is higher than the current hclk frequency. Hence the driver always forces the armdiv to the hclk frequency before the source change and lets the cpufreq issue another set_target call for higher frequencies. To mark the hclk frequency as lower as the corresponding armdiv frequency it is set 1MHz below the real frequency. This lets the cpufreq framework change between 133MHz based on hclk and 133MHz based on armdiv at will. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Andrey Gusakov <dron0gus@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-02-16 18:42:32 +08:00
help
Enable CPU voltage scaling when entering the dvs mode.
It uses information gathered through existing hardware and
tests but not documented in any datasheet.
If in doubt, say N.
cpufreq: s3c24xx: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of Samsung's ARM based s3c24xx platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2013-04-04 20:54:15 +08:00
config ARM_S3C2440_CPUFREQ
bool "S3C2440/S3C2442 CPU Frequency scaling support"
depends on ARM_S3C24XX_CPUFREQ && (CPU_S3C2440 || CPU_S3C2442)
select S3C2410_CPUFREQ_UTILS
default y
help
CPU Frequency scaling support for S3C2440 and S3C2442 SoC CPUs.
[CPUFREQ] Move compile for S3C64XX cpufreq to /drivers/cpufreq Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-06-07 09:43:01 +08:00
config ARM_S3C64XX_CPUFREQ
bool "Samsung S3C64XX"
depends on CPU_S3C6410
default y
help
This adds the CPUFreq driver for Samsung S3C6410 SoC.
If in doubt, say N.
[CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/ According to discussion of the ARM arch subsystem migration, ARM cpufreq drivers move to drivers/cpufreq. So this patch adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 and EXYNOS4210 cpufreq driver compile in there. As a note, otherw will be moved. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-06-02 05:18:22 +08:00
config ARM_S5PV210_CPUFREQ
bool "Samsung S5PV210 and S5PC110"
depends on CPU_S5PV210
default y
help
This adds the CPUFreq driver for Samsung S5PV210 and
S5PC110 SoCs.
If in doubt, say N.
cpufreq: sa11x0: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of ARM based sa11x0 platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 20:54:16 +08:00
config ARM_SA1100_CPUFREQ
bool
config ARM_SA1110_CPUFREQ
bool
cpufreq: add support for CPU DVFS based on SCMI message protocol On some ARM based systems, a separate Cortex-M based System Control Processor(SCP) provides the overall power, clock, reset and system control including CPU DVFS. SCMI Message Protocol is used to communicate with the SCP. This patch adds a cpufreq driver for such systems using SCMI interface to drive CPU DVFS. Cc: linux-pm@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-06-18 16:38:11 +08:00
config ARM_SCMI_CPUFREQ
tristate "SCMI based CPUfreq driver"
depends on ARM_SCMI_PROTOCOL || COMPILE_TEST
cpufreq: scmi: add thermal dependency A built-in scmi cpufreq driver cannot link against a modular thermal framework: drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_ready': scmi-cpufreq.c:(.text+0x40): undefined reference to `of_cpufreq_cooling_register' drivers/cpufreq/scmi-cpufreq.o: In function `scmi_cpufreq_exit': scmi-cpufreq.c:(.text+0x88): undefined reference to `cpufreq_cooling_unregister' This adds a Kconfig dependency that makes sure this configuration is not possible, while allowing all configurations that can work. Note that disabling CPU_THERMAL means we don't care about the THERMAL dependency. Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-13 17:37:33 +08:00
depends on !CPU_THERMAL || THERMAL
cpufreq: add support for CPU DVFS based on SCMI message protocol On some ARM based systems, a separate Cortex-M based System Control Processor(SCP) provides the overall power, clock, reset and system control including CPU DVFS. SCMI Message Protocol is used to communicate with the SCP. This patch adds a cpufreq driver for such systems using SCMI interface to drive CPU DVFS. Cc: linux-pm@vger.kernel.org Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-06-18 16:38:11 +08:00
select PM_OPP
help
This adds the CPUfreq driver support for ARM platforms using SCMI
protocol for CPU power management.
This driver uses SCMI Message Protocol driver to interact with the
firmware providing the CPU DVFS functionality.
cpufreq: SPEAr: Add CPUFreq driver SPEAr is an ARM based family of SoCs. This patch adds in support of cpufreq driver for SPEAr SoCs. It is supported via DT only and so bindings are present in binding document. Signed-off-by: Deepak Sikri <deepak.sikri@st.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-11-27 21:05:26 +08:00
config ARM_SPEAR_CPUFREQ
bool "SPEAr CPUFreq support"
depends on PLAT_SPEAR
default y
help
This adds the CPUFreq driver support for SPEAr SOCs.
cpufreq: tegra: create CONFIG_ARM_TEGRA_CPUFREQ currently Tegra cpufreq driver gets built based on ARCH_TEGRA, which doesn't depend on nor select CPU_FREQ itself, so: select CPU_FREQ_TABLE if CPU_FREQ ... isn't guaranteed to fire. The correct solution seems to be: * Add CONFIG_ARM_TEGRA_CPUFREQ to drivers/cpufreq/Kconfig.arm. * Make that Kconfig option selct CPU_FREQ_TABLE. * Make that Kconfig option be def_bool ARCH_TEGRA. * Modify drivers/cpufreq/Makefile to build tegra-cpufreq.c based on that. * Remove all the cpufreq-related stuff from arch/arm/mach-tegra/Kconfig. That way, tegra-cpufreq.c can't be built if !CPU_FREQ, and Tegra's cpufreq works the same way as all the other cpufreq drivers. This patch does it. Suggested-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-06-12 14:35:48 +08:00
cpufreq: st: Provide runtime initialised driver for ST's platforms The bootloader is charged with the responsibility to provide platform specific Dynamic Voltage and Frequency Scaling (DVFS) information via Device Tree. This driver takes the supplied configuration and registers it with the new generic OPP framework, to then be used with CPUFreq. Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-10 17:42:16 +08:00
config ARM_STI_CPUFREQ
tristate "STi CPUFreq support"
depends on SOC_STIH407
help
This driver uses the generic OPP framework to match the running
platform with a predefined set of suitable values. If not provided
we will fall-back so safe-values contained in Device Tree. Enable
this config option if you wish to add CPUFreq support for STi based
SoCs.
cpufreq: dt: Don't use generic platdev driver for tango On tango platforms, firmware configures the CPU clock, and Linux is then only allowed to use the cpu_clk_divider to change the frequency. Build the OPP table dynamically at init, in order to support whatever firmware throws at us. Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-19 00:48:39 +08:00
config ARM_TANGO_CPUFREQ
bool
depends on CPUFREQ_DT && ARCH_TANGO
default y
cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq The Tegra124 will use a different driver for frequency scaling, so rename the old driver (which handles only Tegra20) appropriately. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-13 22:58:47 +08:00
config ARM_TEGRA20_CPUFREQ
cpufreq: tegra20: Allow cpufreq driver to be built as loadable module Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to be built as a non-builtin kernel module. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-05-19 04:06:41 +08:00
tristate "Tegra20 CPUFreq support"
cpufreq: tegra: create CONFIG_ARM_TEGRA_CPUFREQ currently Tegra cpufreq driver gets built based on ARCH_TEGRA, which doesn't depend on nor select CPU_FREQ itself, so: select CPU_FREQ_TABLE if CPU_FREQ ... isn't guaranteed to fire. The correct solution seems to be: * Add CONFIG_ARM_TEGRA_CPUFREQ to drivers/cpufreq/Kconfig.arm. * Make that Kconfig option selct CPU_FREQ_TABLE. * Make that Kconfig option be def_bool ARCH_TEGRA. * Modify drivers/cpufreq/Makefile to build tegra-cpufreq.c based on that. * Remove all the cpufreq-related stuff from arch/arm/mach-tegra/Kconfig. That way, tegra-cpufreq.c can't be built if !CPU_FREQ, and Tegra's cpufreq works the same way as all the other cpufreq drivers. This patch does it. Suggested-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-06-12 14:35:48 +08:00
depends on ARCH_TEGRA
default y
help
cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq The Tegra124 will use a different driver for frequency scaling, so rename the old driver (which handles only Tegra20) appropriately. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-13 22:58:47 +08:00
This adds the CPUFreq driver support for Tegra20 SOCs.
cpufreq: pxa2xx: Add Kconfig entry Add ability for PXA2xx CPUFreq to be compiled as a module or not at all. Signed-off-by: Petr Cvek <petr.cvek@tul.cz> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 11:59:26 +08:00
cpufreq: Add cpufreq driver for Tegra124 Add a new cpufreq driver for Tegra124. Instead of using the PLLX as the CPU clocksource, switch immediately to the DFLL. It allows the use of higher clock rates, and will automatically scale the CPU voltage as well. Besides the CPU clocksource switch, we let the cpufreq-dt driver for all the cpufreq operations. This driver also relies on the DFLL driver to fill the OPP table for the CPU0 device, so that the cpufreq-dt driver knows what frequencies to use. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-13 22:58:48 +08:00
config ARM_TEGRA124_CPUFREQ
tristate "Tegra124 CPUFreq support"
cpufreq: tegra: add regulator dependency for T124 This driver is the only one that calls regulator_sync_voltage(), but it can currently be built with CONFIG_REGULATOR disabled, producing this build error: drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx': drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration] regulator_sync_voltage(priv->vdd_cpu_reg); My first attempt was to implement a helper for this function for regulator_sync_voltage, but Mark Brown explained: We don't do this for *all* regulator API functions - there's some where using them strongly suggests that there is actually a dependency on the regulator API. This does seem like it might be falling into the specialist category [...] Looking at the code I'm pretty unclear on what the authors think the use of _sync_voltage() is doing in the first place so it may be even better to just remove the call. It seems to have been included in the first commit so there's not changelog explaining things and there's no comment either. I'd *expect* it to be a noop as far as I can see. This adds the dependency to make the driver always build successfully or not be enabled at all. Alternatively, we could investigate if the driver should stop calling regulator_sync_voltage instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-09 05:52:45 +08:00
depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR
cpufreq: Add cpufreq driver for Tegra124 Add a new cpufreq driver for Tegra124. Instead of using the PLLX as the CPU clocksource, switch immediately to the DFLL. It allows the use of higher clock rates, and will automatically scale the CPU voltage as well. Besides the CPU clocksource switch, we let the cpufreq-dt driver for all the cpufreq operations. This driver also relies on the DFLL driver to fill the OPP table for the CPU0 device, so that the cpufreq-dt driver knows what frequencies to use. Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com> Signed-off-by: Mikko Perttunen <mikko.perttunen@kapsi.fi> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-05-13 22:58:48 +08:00
default y
help
This adds the CPUFreq driver support for Tegra124 SOCs.
cpufreq: Add Tegra186 cpufreq driver Add a new cpufreq driver for Tegra186 (and likely later). The CPUs are organized into two clusters, Denver and A57, with two and four cores respectively. CPU frequency can be adjusted by writing the desired rate divisor and a voltage hint to a special per-core register. The frequency of each core can be set individually; however, this is just a hint as all CPUs in a cluster will run at the maximum rate of non-idle CPUs in the cluster. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-11 16:09:15 +08:00
config ARM_TEGRA186_CPUFREQ
tristate "Tegra186 CPUFreq support"
depends on ARCH_TEGRA && TEGRA_BPMP
help
This adds the CPUFreq driver support for Tegra186 SOCs.
cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime 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>
2017-02-04 01:29:28 +08:00
config ARM_TI_CPUFREQ
bool "Texas Instruments CPUFreq support"
depends on ARCH_OMAP2PLUS
help
This driver enables valid OPPs on the running platform based on
values contained within the SoC in use. Enable this in order to
use the cpufreq-dt driver on all Texas Instruments platforms that
provide dt based operating-points-v2 tables with opp-supported-hw
data provided. Required for cpufreq support on AM335x, AM437x,
DRA7x, and AM57x platforms.
cpufreq: pxa2xx: Add Kconfig entry Add ability for PXA2xx CPUFreq to be compiled as a module or not at all. Signed-off-by: Petr Cvek <petr.cvek@tul.cz> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-24 11:59:26 +08:00
config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
depends on PXA27x || PXA25x
help
This add the CPUFreq driver support for Intel PXA2xx SOCs.
If in doubt, say N.