iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
c4cfdd81c8
linux/drivers/cpufreq/Kconfig.arm

264 lines
6.7 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 01:18:22 +04:00
#
# ARM CPU Frequency scaling drivers
#
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 10:40:54 +04: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 16:57:49 +04: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 10:33:54 +04:00
tristate "Generic ARM big LITTLE CPUfreq driver"
cpufreq: arm_big_little: remove compile-time dependency on BIG_LITTLE With the addition of switcher code, there's compile-time dependency on BIG_LITTLE to get arm_big_little driver compiling on ARM64. Since ARM64 will never add support for bL switcher, it's better to remove the dependency so that the driver can be reused on ARM64 platforms. This patch adds stubs to remove BIG_LITTLE dependency in the driver. 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>
2015-05-13 15:35:52 +03:00
depends on (ARM_CPU_TOPOLOGY || ARM64) && HAVE_CLK
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 02:12:27 +04: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 10:33:54 +04: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 16:57:49 +04:00
config ARM_DT_BL_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 10:33:54 +04:00
tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver"
depends on ARM_BIG_LITTLE_CPUFREQ && OF
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 16:57:49 +04:00
help
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 10:33:54 +04:00
This enables probing via DT for Generic CPUfreq driver for ARM
big.LITTLE platform. This gets frequency tables from DT.
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 16:57:49 +04:00
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 10:40:54 +04:00
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: 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 16:54:09 +04:00
config ARM_EXYNOS_CPUFREQ
cpufreq: exynos: allow modular build The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-31 21:35:18 +03:00
tristate "SAMSUNG EXYNOS CPUfreq Driver"
depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
depends on THERMAL
help
This adds the CPUFreq driver for Samsung EXYNOS platforms.
Supported SoC versions are:
Exynos4210, Exynos4212, Exynos4412, and Exynos5250.
If in doubt, say N.
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 16:54:09 +04:00
config ARM_EXYNOS4X12_CPUFREQ
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
bool "SAMSUNG EXYNOS4x12"
cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM Currently Exynos cpufreq drivers rely on globally mapped clock controller registers to configure frequency of CPU cores. This is obviously wrong and will be removed in near future, but to enable support for multi-platform builds without introducing a regression it needs to be worked around. This patch hacks the code to look for clock controller node in device tree and map its registers using of_iomap(), instead of relying on global mapping, so dependencies on platform headers are removed and the driver can compile again with multiplatform support. Signed-off-by: Tomasz Figa <t.figa@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2014-05-26 01:26:03 +04:00
depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
cpufreq: exynos: allow modular build The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-31 21:35:18 +03:00
depends on ARM_EXYNOS_CPUFREQ
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
default y
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 16:54:09 +04:00
help
This adds the CPUFreq driver for Samsung EXYNOS4X12
SoC (EXYNOS4212 or EXYNOS4412).
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
If in doubt, say N.
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 16:54:09 +04:00
config ARM_EXYNOS5250_CPUFREQ
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
bool "SAMSUNG EXYNOS5250"
cpufreq: exynos: Fix driver compilation with ARCH_MULTIPLATFORM Currently Exynos cpufreq drivers rely on globally mapped clock controller registers to configure frequency of CPU cores. This is obviously wrong and will be removed in near future, but to enable support for multi-platform builds without introducing a regression it needs to be worked around. This patch hacks the code to look for clock controller node in device tree and map its registers using of_iomap(), instead of relying on global mapping, so dependencies on platform headers are removed and the driver can compile again with multiplatform support. Signed-off-by: Tomasz Figa <t.figa@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
2014-05-26 01:26:03 +04:00
depends on SOC_EXYNOS5250
cpufreq: exynos: allow modular build The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-31 21:35:18 +03:00
depends on ARM_EXYNOS_CPUFREQ
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
default y
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 16:54:09 +04:00
help
This adds the CPUFreq driver for Samsung EXYNOS5250
SoC.
cpufreq: fix EXYNOS drivers selection * remove superfluous pr_debug() call from exynos_cpufreq_init() (init errors are always logged anyway) * add dummy per-SoC type init functions to exynos-cpufreq.h * make per-SoC type cpufreq config options selectable * make CONFIG_ARM_EXYNOS_CPUFREQ config option invisible to user and automatically enable it when needed This patch fixes following issues: * EXYNOS per-SoC type cpufreq support (i.e. exynos4210-cpufreq.c) being always built if given SoC support was enabled (i.e. CPU_EXYNOS4210), even if common EXYNOS cpufreq support was disabled * inability to select cpufreq for each SoC type separately (it could be only enabled/disabled for all SoCs for which support was enabled) * EXYNOS5440 cpufreq support was always enabled when EXYNOS5440 support was enabled and couldn't be disabled Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Reviewed-by: Tomasz Figa <t.figa@samsung.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2013-08-09 16:04:55 +04:00
If in doubt, say N.
cpufreq / boost: Kconfig: Support for software-managed BOOST Add CONFIG_CPU_FREQ_BOOST_SW Kconfig option such that software-managed boost is enabled only after selecting "EXYNOS Frequency Overclocking - Software". It also depends on the thermal subsystem to be compiled in, which is necessary for disabling boost and cooling down the device when overheating is detected. Software-managed boost _MUST_ _NOT_ be enabled without thermal subsystem with properly defined overheating temperature thresholds. This option doesn't affect the x86's hardware-driven boost support in the acpi-cpufreq driver. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-20 18:24:51 +04:00
config ARM_EXYNOS_CPU_FREQ_BOOST_SW
bool "EXYNOS Frequency Overclocking - Software"
ARM: cns3xxx: fix allmodconfig panic in pci driver The kernel panic occurs when running an allmodconfig kernel on OMAP4460. The inicall "cns3xxx_pcie_init" does not check which hardware it's running on and just tries to access to its specific registers. Now call it from .init_late callback from the two machine descriptors. Signed-off-by: Xia Kaixu <kaixu.xia@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Felix Fietkau <nbd@openwrt.org> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: linaro-kernel@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org
2014-09-03 17:18:12 +04:00
depends on ARM_EXYNOS_CPUFREQ && THERMAL
cpufreq / boost: Kconfig: Support for software-managed BOOST Add CONFIG_CPU_FREQ_BOOST_SW Kconfig option such that software-managed boost is enabled only after selecting "EXYNOS Frequency Overclocking - Software". It also depends on the thermal subsystem to be compiled in, which is necessary for disabling boost and cooling down the device when overheating is detected. Software-managed boost _MUST_ _NOT_ be enabled without thermal subsystem with properly defined overheating temperature thresholds. This option doesn't affect the x86's hardware-driven boost support in the acpi-cpufreq driver. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-20 18:24:51 +04:00
select CPU_FREQ_BOOST_SW
select EXYNOS_THERMAL
help
This driver supports software managed overclocking (BOOST).
It allows usage of special frequencies for Samsung Exynos
processors if thermal conditions are appropriate.
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-22 23:40:10 +04:00
It requires, for safe operation, thermal framework with properly
cpufreq / boost: Kconfig: Support for software-managed BOOST Add CONFIG_CPU_FREQ_BOOST_SW Kconfig option such that software-managed boost is enabled only after selecting "EXYNOS Frequency Overclocking - Software". It also depends on the thermal subsystem to be compiled in, which is necessary for disabling boost and cooling down the device when overheating is detected. Software-managed boost _MUST_ _NOT_ be enabled without thermal subsystem with properly defined overheating temperature thresholds. This option doesn't affect the x86's hardware-driven boost support in the acpi-cpufreq driver. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-12-20 18:24:51 +04:00
defined trip points.
If in doubt, say N.
cpufreq: exynos: allow modular build The exynos cpufreq driver code recently gained a dependency on the cooling code, which may be a loadable module. This breaks an ARM allmodconfig build: drivers/built-in.o: In function `exynos_cpufreq_probe': :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register' To avoid this problem, change cpufreq Kconfig to allow the drivers to be loadable modules as well and enforce a dependency on the thermal module. This change, in order to allow module builds on this cpufreq driver, properly constructs the driver into a single module, instead of several modules. The change also keeps the proper platform dependency, and therefore, it wont load in platforms that are not supposed to be loaded. The user will be able to build the support for all platforms, or select which platforms (s)he wants (as originally), except that now it can be a module, instead. Besides, it will still keep the driver only on those configs that expect it to be on. And it won't compile/load on platforms that it is not supposed to. It brings the config ARM_EXYNOS_CPU_FREQ_BOOST_SW closer to this driver, so it looks better in the menuconfig. We intentionally change ARM_EXYNOS5440_CPUFREQ to be tristate too, to avoid future troubles. Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Kukjin Kim <kgene@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-pm@vger.kernel.org Cc: linux-samsung-soc@vger.kernel.org Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
2015-01-31 21:35:18 +03:00
config ARM_EXYNOS5440_CPUFREQ
tristate "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
depends on HAVE_CLK && OF
select PM_OPP
default y
help
This adds the CPUFreq driver for Samsung EXYNOS5440
SoC. The nature of exynos5440 clock controller is
different than previous exynos controllers so not using
the common exynos framework.
If in doubt, say N.
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 16:54:09 +04: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 18:28:03 +04: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 16:54:09 +04:00
default m
help
This adds the CPUFreq driver for Calxeda Highbank SoC
based boards.
If in doubt, say N.
cpufreq: hisilicon: add acpu driver Add acpu driver for hisilicon SoC, acpu is application processor subsystem. Currently the acpu has the coupled clock domain for two clusters, so this driver will directly use cpufreq-dt driver as backend. Signed-off-by: Leo Yan <leo.yan@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-30 08:26:37 +03:00
config ARM_HISI_ACPU_CPUFREQ
tristate "Hisilicon ACPU CPUfreq driver"
depends on ARCH_HISI && CPUFREQ_DT
select PM_OPP
help
This enables the hisilicon ACPU CPUfreq driver.
If in doubt, say N.
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 16:54:09 +04:00
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 06:12:16 +04: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 16:54:09 +04: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 01:59:00 +04: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 16:54:09 +04: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 06:12:16 +04: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 16:54:09 +04:00
If in doubt, say N.
cpufreq: integrator: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of ARM based integrator platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 16:54:14 +04:00
config ARM_INTEGRATOR
tristate "CPUfreq driver for ARM Integrator CPUs"
depends on ARCH_INTEGRATOR
default y
help
This enables the CPUfreq driver for ARM Integrator CPUs.
If in doubt, say Y.
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 16:54:09 +04:00
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-30 20:46:12 +04: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 16:54:09 +04:00
help
This adds the CPUFreq driver for Marvell Kirkwood
SoCs.
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-15 23:01:11 +04: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 00:32:30 +04: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-15 23:01:11 +04:00
default ARCH_OMAP2PLUS
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 16:54:15 +04: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 14:42:32 +04: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-22 23:40:10 +04: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 14:42:32 +04: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-02 22:16:53 +04: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 14:42:32 +04: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 16:54:15 +04: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 05:43:01 +04: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 01:18:22 +04: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 16:54:16 +04:00
config ARM_SA1100_CPUFREQ
bool
config ARM_SA1110_CPUFREQ
bool
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 17:05:26 +04: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 10:35:48 +04:00
config ARM_TEGRA_CPUFREQ
bool "TEGRA CPUFreq support"
depends on ARCH_TEGRA
default y
help
This adds the CPUFreq driver support for TEGRA 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 06:59:26 +03: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.
Reference in New Issue Copy Permalink