evie/android_kernel_oneplus_msm8998
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
android_kernel_oneplus_msm8998/drivers/cpufreq/Kconfig

377 lines
11 KiB
Text
Raw Normal View History

[CPUFREQ] Move x86 drivers to drivers/cpufreq/ Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-19 18:51:07 -04:00
menu "CPU Frequency scaling"
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
config CPU_FREQ
bool "CPU Frequency scaling"
rcu: Make SRCU optional by using CONFIG_SRCU SRCU is not necessary to be compiled by default in all cases. For tinification efforts not compiling SRCU unless necessary is desirable. The current patch tries to make compiling SRCU optional by introducing a new Kconfig option CONFIG_SRCU which is selected when any of the components making use of SRCU are selected. If we do not select CONFIG_SRCU, srcu.o will not be compiled at all. text data bss dec hex filename 2007 0 0 2007 7d7 kernel/rcu/srcu.o Size of arch/powerpc/boot/zImage changes from text data bss dec hex filename 831552 64180 23944 919676 e087c arch/powerpc/boot/zImage : before 829504 64180 23952 917636 e0084 arch/powerpc/boot/zImage : after so the savings are about ~2000 bytes. Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com> CC: Josh Triplett <josh@joshtriplett.org> CC: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> [ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
2014-12-05 11:24:45 -05:00
select SRCU
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
help
CPU Frequency scaling allows you to change the clock speed of
CPUs on the fly. This is a nice method to save power, because
the lower the CPU clock speed, the less power the CPU consumes.
Note that this driver doesn't automatically change the CPU
clock speed, you need to either enable a dynamic cpufreq governor
(see below) after boot, or use a userspace tool.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
if CPU_FREQ
cpufreq / governor: Fix problem with cpufreq_ondemand or cpufreq_conservative Since commit 2aacdff entitled "cpufreq: Move common part from governors to separate file", whenever the drivers that depend on this new file (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module named cpufreq_governor is created because the Makefile includes cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the resulting module has no license specified, which results in logging of a "module license 'unspecified' taints kernel". In addition, a number of globals are exported GPL only, and are therefore not available. This fix establishes a new boolean configuration variable that forces cpufreq_governor.o to be linked into the kernel whenever either cpufreq_ondemand or cpufreq_conservative is selected. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-29 01:55:20 +00:00
config CPU_FREQ_GOV_COMMON
bool
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 15:24:51 +01:00
config CPU_FREQ_BOOST_SW
bool
depends on THERMAL
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
config CPU_FREQ_STAT
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
tristate "CPU frequency translation statistics"
default y
help
This driver exports CPU frequency statistics information through sysfs
file system.
To compile this driver as a module, choose M here: the
module will be called cpufreq_stats.
If in doubt, say N.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
config CPU_FREQ_STAT_DETAILS
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
bool "CPU frequency translation statistics details"
depends on CPU_FREQ_STAT
help
This will show detail CPU frequency translation table in sysfs file
system.
If in doubt, say N.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
choice
prompt "Default CPUFreq governor"
cpufreq: Fix incorrect dependecies for ARM SA11xx drivers Kconfig dependecies for ARM SA11xx drivers are incorrect, so fix them. [rjw: Changelog] Signed-off-by: Alexander Shiyan <shc_work@mail.ru> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-05-05 12:18:08 +00:00
default CPU_FREQ_DEFAULT_GOV_USERSPACE if ARM_SA1100_CPUFREQ || ARM_SA1110_CPUFREQ
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
default CPU_FREQ_DEFAULT_GOV_PERFORMANCE
help
This option sets which CPUFreq governor shall be loaded at
startup. If in doubt, select 'performance'.
config CPU_FREQ_DEFAULT_GOV_PERFORMANCE
bool "performance"
select CPU_FREQ_GOV_PERFORMANCE
help
Use the CPUFreq governor 'performance' as default. This sets
the frequency statically to the highest frequency supported by
the CPU.
[CPUFREQ] allow use of the powersave governor as the default one Allow use of the powersave cpufreq governor as the default one for EMBEDDED configs. Signed-off-by: Alessandro Guido <alessandro.guido@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
2008-04-18 13:31:13 -07:00
config CPU_FREQ_DEFAULT_GOV_POWERSAVE
bool "powersave"
select CPU_FREQ_GOV_POWERSAVE
help
Use the CPUFreq governor 'powersave' as default. This sets
the frequency statically to the lowest frequency supported by
the CPU.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
config CPU_FREQ_DEFAULT_GOV_USERSPACE
bool "userspace"
select CPU_FREQ_GOV_USERSPACE
help
Use the CPUFreq governor 'userspace' as default. This allows
trivial: fix an -> a typos in documentation and comments It is always "an" if there is a vowel _spoken_ (not written). So it is: "an hour" (spoken vowel) but "a uniform" (spoken 'j') Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2008-12-29 22:14:56 +01:00
you to set the CPU frequency manually or when a userspace
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
program shall be able to set the CPU dynamically without having
to enable the userspace governor manually.
[CPUFREQ] allow ondemand and conservative cpufreq governors to be used as default Depending on the transition latency of the HW for cpufreq switches, the ondemand or conservative governor cannot be used with certain cpufreq drivers. Still the ondemand should be the default governor on a wide range of systems. This patch allows this and lets the governor fallback to the performance governor at cpufreq driver load time, if the driver does not support fast enough frequency switching. Main benefit is that on e.g. installation or other systems without userspace support a working dynamic cpufreq support can be achieved on most systems by simply loading the cpufreq driver. This is especially essential for recent x86(_64) laptop hardware which may rely on working dynamic cpufreq OS support. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Bryan Wu <bryan.wu@analog.com> Cc: Andi Kleen <ak@suse.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mundt <lethal@linux-sh.org> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-10-02 13:28:12 -07:00
config CPU_FREQ_DEFAULT_GOV_ONDEMAND
bool "ondemand"
select CPU_FREQ_GOV_ONDEMAND
select CPU_FREQ_GOV_PERFORMANCE
help
Use the CPUFreq governor 'ondemand' as default. This allows
you to get a full dynamic frequency capable system by simply
loading your cpufreq low-level hardware driver.
Be aware that not all cpufreq drivers support the ondemand
governor. If unsure have a look at the help section of the
driver. Fallback governor will be the performance governor.
config CPU_FREQ_DEFAULT_GOV_CONSERVATIVE
bool "conservative"
select CPU_FREQ_GOV_CONSERVATIVE
select CPU_FREQ_GOV_PERFORMANCE
help
Use the CPUFreq governor 'conservative' as default. This allows
you to get a full dynamic frequency capable system by simply
loading your cpufreq low-level hardware driver.
Be aware that not all cpufreq drivers support the conservative
governor. If unsure have a look at the help section of the
driver. Fallback governor will be the performance governor.
cpufreq: interactive: New 'interactive' governor This governor is designed for latency-sensitive workloads, such as interactive user interfaces. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins. Existing governors sample CPU load at a particular rate, typically every X ms. This can lead to under-powering UI threads for the period of time during which the user begins interacting with a previously-idle system until the next sample period happens. The 'interactive' governor uses a different approach. Instead of sampling the CPU at a specified rate, the governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy from exiting idle to when the timer fires then we assume the CPU is underpowered and ramp to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed, then the governor evaluates the CPU load since the last speed adjustment, choosing the highest value between that longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to. A realtime thread is used for scaling up, giving the remaining tasks the CPU performance benefit, unlike existing governors which are more likely to schedule rampup work to occur after your performance starved tasks have completed. The tuneables for this governor are: /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic CPU load data to determine the appropriate workload. Default is 80000 uS. /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load The CPU load at which to ramp to max speed. Default is 85. Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585 Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com> Bug: 3152864
2010-06-22 11:26:45 -07:00
config CPU_FREQ_DEFAULT_GOV_INTERACTIVE
bool "interactive"
select CPU_FREQ_GOV_INTERACTIVE
help
Use the CPUFreq governor 'interactive' as default. This allows
you to get a full dynamic cpu frequency capable system by simply
loading your cpufreq low-level hardware driver, using the
'interactive' governor for latency-sensitive workloads.
sched: scheduler-driven cpu frequency selection Scheduler-driven CPU frequency selection hopes to exploit both per-task and global information in the scheduler to improve frequency selection policy, achieving lower power consumption, improved responsiveness/performance, and less reliance on heuristics and tunables. For further discussion on the motivation of this integration see [0]. This patch implements a shim layer between the Linux scheduler and the cpufreq subsystem. The interface accepts capacity requests from the CFS, RT and deadline sched classes. The requests from each sched class are summed on each CPU with a margin applied to the CFS and RT capacity requests to provide some headroom. Deadline requests are expected to be precise enough given their nature to not require headroom. The maximum total capacity request for a CPU in a frequency domain drives the requested frequency for that domain. Policy is determined by both the sched classes and this shim layer. Note that this algorithm is event-driven. There is no polling loop to check cpu idle time nor any other method which is unsynchronized with the scheduler, aside from a throttling mechanism to ensure frequency changes are not attempted faster than the hardware can accommodate them. Thanks to Juri Lelli <juri.lelli@arm.com> for contributing design ideas, code and test results, and to Ricky Liang <jcliang@chromium.org> for initialization and static key inc/dec fixes. [0] http://article.gmane.org/gmane.linux.kernel/1499836 [smuckle@linaro.org: various additions and fixes, revised commit text] CC: Ricky Liang <jcliang@chromium.org> Signed-off-by: Michael Turquette <mturquette@baylibre.com> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Steve Muckle <smuckle@linaro.org>
2015-06-30 12:45:48 +01:00
config CPU_FREQ_DEFAULT_GOV_SCHED
bool "sched"
cpufreq: Kconfig: Fixup incorrect selection by CPU_FREQ_DEFAULT_GOV_SCHED The CPU_FREQ_DEFAULT_GOV_SCHED option is incorrectly selecting CPU_FREQ_GOV_INTERACTIVE, when it should be selecting CPU_FREQ_GOV_SCHED. Signed-off-by: John Stultz <john.stultz@linaro.org>
2016-09-08 16:43:21 -07:00
select CPU_FREQ_GOV_SCHED
sched: scheduler-driven cpu frequency selection Scheduler-driven CPU frequency selection hopes to exploit both per-task and global information in the scheduler to improve frequency selection policy, achieving lower power consumption, improved responsiveness/performance, and less reliance on heuristics and tunables. For further discussion on the motivation of this integration see [0]. This patch implements a shim layer between the Linux scheduler and the cpufreq subsystem. The interface accepts capacity requests from the CFS, RT and deadline sched classes. The requests from each sched class are summed on each CPU with a margin applied to the CFS and RT capacity requests to provide some headroom. Deadline requests are expected to be precise enough given their nature to not require headroom. The maximum total capacity request for a CPU in a frequency domain drives the requested frequency for that domain. Policy is determined by both the sched classes and this shim layer. Note that this algorithm is event-driven. There is no polling loop to check cpu idle time nor any other method which is unsynchronized with the scheduler, aside from a throttling mechanism to ensure frequency changes are not attempted faster than the hardware can accommodate them. Thanks to Juri Lelli <juri.lelli@arm.com> for contributing design ideas, code and test results, and to Ricky Liang <jcliang@chromium.org> for initialization and static key inc/dec fixes. [0] http://article.gmane.org/gmane.linux.kernel/1499836 [smuckle@linaro.org: various additions and fixes, revised commit text] CC: Ricky Liang <jcliang@chromium.org> Signed-off-by: Michael Turquette <mturquette@baylibre.com> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Steve Muckle <smuckle@linaro.org>
2015-06-30 12:45:48 +01:00
help
Use the CPUfreq governor 'sched' as default. This scales
cpu frequency using CPU utilization estimates from the
scheduler.
BACKPORT: cpufreq: schedutil: New governor based on scheduler utilization data Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c55 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Change-Id: I03876e622768e4b3ee4dc28682af7cce771f2f4c Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> (cherry-picked from 9bdcb44e391da5c41b98573bf0305a0e0b1c9569) [ Backport the schedutil cpufreq governor from 4.9. Some cpufreq tunable infrastructure as well as the resolve_freq API is also backported as those are dependencies] Signed-off-by: Steve Muckle <smuckle@linaro.org> [trivial cherry-picking fixes] Signed-off-by: Juri Lelli <juri.lelli@arm.com> [fixed default governor machinery] Signed-off-by: Chris Redpath <chris.redpath@arm.com>
2016-11-11 17:14:39 -08:00
config CPU_FREQ_DEFAULT_GOV_SCHEDUTIL
bool "schedutil"
depends on SMP
select CPU_FREQ_GOV_SCHEDUTIL
select CPU_FREQ_GOV_PERFORMANCE
help
Use the 'schedutil' CPUFreq governor by default. If unsure,
have a look at the help section of that governor. The fallback
governor will be 'performance'.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
endchoice
config CPU_FREQ_GOV_PERFORMANCE
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
tristate "'performance' governor"
help
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
This cpufreq governor sets the frequency statically to the
highest available CPU frequency.
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
To compile this driver as a module, choose M here: the
module will be called cpufreq_performance.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
If in doubt, say Y.
config CPU_FREQ_GOV_POWERSAVE
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
tristate "'powersave' governor"
help
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
This cpufreq governor sets the frequency statically to the
lowest available CPU frequency.
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
To compile this driver as a module, choose M here: the
module will be called cpufreq_powersave.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
If in doubt, say Y.
config CPU_FREQ_GOV_USERSPACE
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
tristate "'userspace' governor for userspace frequency scaling"
help
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
Enable this cpufreq governor when you either want to set the
trivial: fix an -> a typos in documentation and comments It is always "an" if there is a vowel _spoken_ (not written). So it is: "an hour" (spoken vowel) but "a uniform" (spoken 'j') Signed-off-by: Frederik Schwarzer <schwarzerf@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2008-12-29 22:14:56 +01:00
CPU frequency manually or when a userspace program shall
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
be able to set the CPU dynamically, like on LART
[CPUFREQ] Update LART site URL Update LART site URL. The LART website moved to http://www.lartmaker.nl/. This patch updates the URL in CpuFreq specific files. Signed-off-by: Erik Mouw <erik@bitwizard.nl> Signed-off-by: Dave Jones <davej@redhat.com>
2006-04-03 14:21:00 +02:00
<http://www.lartmaker.nl/>.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
To compile this driver as a module, choose M here: the
module will be called cpufreq_userspace.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
For details, take a look at <file:Documentation/cpu-freq/>.
If in doubt, say Y.
config CPU_FREQ_GOV_ONDEMAND
tristate "'ondemand' cpufreq policy governor"
cpufreq / governor: Fix problem with cpufreq_ondemand or cpufreq_conservative Since commit 2aacdff entitled "cpufreq: Move common part from governors to separate file", whenever the drivers that depend on this new file (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module named cpufreq_governor is created because the Makefile includes cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the resulting module has no license specified, which results in logging of a "module license 'unspecified' taints kernel". In addition, a number of globals are exported GPL only, and are therefore not available. This fix establishes a new boolean configuration variable that forces cpufreq_governor.o to be linked into the kernel whenever either cpufreq_ondemand or cpufreq_conservative is selected. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-29 01:55:20 +00:00
select CPU_FREQ_GOV_COMMON
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
help
'ondemand' - This driver adds a dynamic cpufreq policy governor.
The governor does a periodic polling and
changes frequency based on the CPU utilization.
The support for this governor depends on CPU capability to
do fast frequency switching (i.e, very low latency frequency
transitions).
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
To compile this driver as a module, choose M here: the
module will be called cpufreq_ondemand.
Linux-2.6.12-rc2 Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
2005-04-16 15:20:36 -07:00
For details, take a look at linux/Documentation/cpu-freq.
If in doubt, say N.
cpufreq: interactive: New 'interactive' governor This governor is designed for latency-sensitive workloads, such as interactive user interfaces. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins. Existing governors sample CPU load at a particular rate, typically every X ms. This can lead to under-powering UI threads for the period of time during which the user begins interacting with a previously-idle system until the next sample period happens. The 'interactive' governor uses a different approach. Instead of sampling the CPU at a specified rate, the governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy from exiting idle to when the timer fires then we assume the CPU is underpowered and ramp to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed, then the governor evaluates the CPU load since the last speed adjustment, choosing the highest value between that longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to. A realtime thread is used for scaling up, giving the remaining tasks the CPU performance benefit, unlike existing governors which are more likely to schedule rampup work to occur after your performance starved tasks have completed. The tuneables for this governor are: /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic CPU load data to determine the appropriate workload. Default is 80000 uS. /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load The CPU load at which to ramp to max speed. Default is 85. Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585 Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com> Bug: 3152864
2010-06-22 11:26:45 -07:00
config CPU_FREQ_GOV_INTERACTIVE
android: skip building drivers as modules Few Android drivers e.g. uid_cputime and PPPoLAC/oPNS, keyreset/combo, cpufreq_interactive etc.. fail to build as kernel modules. Instead of fixing the build lets make these drivers non-modular (switch config to "bool" from "tristate" in Kconfig) since Android doesn't support building kernel modules anyway. Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
2015-12-29 12:59:31 +05:30
bool "'interactive' cpufreq policy governor"
cpufreq: interactive: New 'interactive' governor This governor is designed for latency-sensitive workloads, such as interactive user interfaces. The interactive governor aims to be significantly more responsive to ramp CPU quickly up when CPU-intensive activity begins. Existing governors sample CPU load at a particular rate, typically every X ms. This can lead to under-powering UI threads for the period of time during which the user begins interacting with a previously-idle system until the next sample period happens. The 'interactive' governor uses a different approach. Instead of sampling the CPU at a specified rate, the governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy from exiting idle to when the timer fires then we assume the CPU is underpowered and ramp to MAX speed. If the CPU was not sufficiently busy to immediately ramp to MAX speed, then the governor evaluates the CPU load since the last speed adjustment, choosing the highest value between that longer-term load or the short-term load since idle exit to determine the CPU speed to ramp to. A realtime thread is used for scaling up, giving the remaining tasks the CPU performance benefit, unlike existing governors which are more likely to schedule rampup work to occur after your performance starved tasks have completed. The tuneables for this governor are: /sys/devices/system/cpu/cpufreq/interactive/min_sample_time: The minimum amount of time to spend at the current frequency before ramping down. This is to ensure that the governor has seen enough historic CPU load data to determine the appropriate workload. Default is 80000 uS. /sys/devices/system/cpu/cpufreq/interactive/go_maxspeed_load The CPU load at which to ramp to max speed. Default is 85. Change-Id: Ib2b362607c62f7c56d35f44a9ef3280f98c17585 Signed-off-by: Mike Chan <mike@android.com> Signed-off-by: Todd Poynor <toddpoynor@google.com> Bug: 3152864
2010-06-22 11:26:45 -07:00
help
'interactive' - This driver adds a dynamic cpufreq policy governor
designed for latency-sensitive workloads.
This governor attempts to reduce the latency of clock
increases so that the system is more responsive to
interactive workloads.
For details, take a look at linux/Documentation/cpu-freq.
If in doubt, say N.
[CPUFREQ] Conservative cpufreq governer A new cpufreq module, based on the ondemand one with my additional patches just posted. This one is more suitable for battery environments where its probably more appealing to have the cpu freq gracefully increase and decrease rather than flip between the min and max freq's. N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency between min and max freq transition, due to the step-by-step requirements (200MHz IIRC)"; so AMD64 users would probably benefit from this too. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31 19:03:47 -07:00
config CPU_FREQ_GOV_CONSERVATIVE
tristate "'conservative' cpufreq governor"
depends on CPU_FREQ
cpufreq / governor: Fix problem with cpufreq_ondemand or cpufreq_conservative Since commit 2aacdff entitled "cpufreq: Move common part from governors to separate file", whenever the drivers that depend on this new file (cpufreq_ondemand or cpufreq_conservative) are built as modules, a new module named cpufreq_governor is created because the Makefile includes cpufreq_governor.o twice. As drivers/cpufreq/cpufreq_governor.c contains no MODULE directives, the resulting module has no license specified, which results in logging of a "module license 'unspecified' taints kernel". In addition, a number of globals are exported GPL only, and are therefore not available. This fix establishes a new boolean configuration variable that forces cpufreq_governor.o to be linked into the kernel whenever either cpufreq_ondemand or cpufreq_conservative is selected. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-29 01:55:20 +00:00
select CPU_FREQ_GOV_COMMON
[CPUFREQ] Conservative cpufreq governer A new cpufreq module, based on the ondemand one with my additional patches just posted. This one is more suitable for battery environments where its probably more appealing to have the cpu freq gracefully increase and decrease rather than flip between the min and max freq's. N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency between min and max freq transition, due to the step-by-step requirements (200MHz IIRC)"; so AMD64 users would probably benefit from this too. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31 19:03:47 -07:00
help
'conservative' - this driver is rather similar to the 'ondemand'
governor both in its source code and its purpose, the difference is
its optimisation for better suitability in a battery powered
environment. The frequency is gracefully increased and decreased
rather than jumping to 100% when speed is required.
If you have a desktop machine then you should really be considering
the 'ondemand' governor instead, however if you are using a laptop,
PDA or even an AMD64 based computer (due to the unacceptable
step-by-step latency issues between the minimum and maximum frequency
transitions in the CPU) you will probably want to use this governor.
[CPUFREQ] cleanup kconfig options Adds proper lines to help output of kconfig so people can find the module names. Also fixed some broken leading spaces versus tabs. Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
2007-04-18 16:18:13 -04:00
To compile this driver as a module, choose M here: the
module will be called cpufreq_conservative.
[CPUFREQ] Conservative cpufreq governer A new cpufreq module, based on the ondemand one with my additional patches just posted. This one is more suitable for battery environments where its probably more appealing to have the cpu freq gracefully increase and decrease rather than flip between the min and max freq's. N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency between min and max freq transition, due to the step-by-step requirements (200MHz IIRC)"; so AMD64 users would probably benefit from this too. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31 19:03:47 -07:00
For details, take a look at linux/Documentation/cpu-freq.
If in doubt, say N.
cpufreq: cpu-boost: Move CPU_BOOST Kconfig to correct section cpu-boost driver is not a CPUFreq device. Moving it to the end of CPUFreq governor section. Change-Id: Ib433f81e7596789a2e6ea03d0bd0a8d166ecf9e9 Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
2015-12-30 15:10:08 -08:00
config CPU_BOOST
tristate "Event base short term CPU freq boost"
depends on CPU_FREQ
help
This driver boosts the frequency of one or more CPUs based on
various events that might occur in the system. As of now, the
events it reacts to are:
- Migration of important threads from one CPU to another.
If in doubt, say N.
BACKPORT: cpufreq: schedutil: New governor based on scheduler utilization data Add a new cpufreq scaling governor, called "schedutil", that uses scheduler-provided CPU utilization information as input for making its decisions. Doing that is possible after commit 34e2c55 (cpufreq: Add mechanism for registering utilization update callbacks) that introduced cpufreq_update_util() called by the scheduler on utilization changes (from CFS) and RT/DL task status updates. In particular, CPU frequency scaling decisions may be based on the the utilization data passed to cpufreq_update_util() by CFS. The new governor is relatively simple. The frequency selection formula used by it depends on whether or not the utilization is frequency-invariant. In the frequency-invariant case the new CPU frequency is given by next_freq = 1.25 * max_freq * util / max where util and max are the last two arguments of cpufreq_update_util(). In turn, if util is not frequency-invariant, the maximum frequency in the above formula is replaced with the current frequency of the CPU: next_freq = 1.25 * curr_freq * util / max The coefficient 1.25 corresponds to the frequency tipping point at (util / max) = 0.8. All of the computations are carried out in the utilization update handlers provided by the new governor. One of those handlers is used for cpufreq policies shared between multiple CPUs and the other one is for policies with one CPU only (and therefore it doesn't need to use any extra synchronization means). The governor supports fast frequency switching if that is supported by the cpufreq driver in use and possible for the given policy. In the fast switching case, all operations of the governor take place in its utilization update handlers. If fast switching cannot be used, the frequency switch operations are carried out with the help of a work item which only calls __cpufreq_driver_target() (under a mutex) to trigger a frequency update (to a value already computed beforehand in one of the utilization update handlers). Currently, the governor treats all of the RT and DL tasks as "unknown utilization" and sets the frequency to the allowed maximum when updated from the RT or DL sched classes. That heavy-handed approach should be replaced with something more subtle and specifically targeted at RT and DL tasks. The governor shares some tunables management code with the "ondemand" and "conservative" governors and uses some common definitions from cpufreq_governor.h, but apart from that it is stand-alone. Change-Id: I03876e622768e4b3ee4dc28682af7cce771f2f4c Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> (cherry-picked from 9bdcb44e391da5c41b98573bf0305a0e0b1c9569) [ Backport the schedutil cpufreq governor from 4.9. Some cpufreq tunable infrastructure as well as the resolve_freq API is also backported as those are dependencies] Signed-off-by: Steve Muckle <smuckle@linaro.org> [trivial cherry-picking fixes] Signed-off-by: Juri Lelli <juri.lelli@arm.com> [fixed default governor machinery] Signed-off-by: Chris Redpath <chris.redpath@arm.com>
2016-11-11 17:14:39 -08:00
config CPU_FREQ_GOV_SCHEDUTIL
bool "'schedutil' cpufreq policy governor"
depends on CPU_FREQ && SMP
select CPU_FREQ_GOV_ATTR_SET
select IRQ_WORK
help
This governor makes decisions based on the utilization data provided
by the scheduler. It sets the CPU frequency to be proportional to
the utilization/capacity ratio coming from the scheduler. If the
utilization is frequency-invariant, the new frequency is also
proportional to the maximum available frequency. If that is not the
case, it is proportional to the current frequency of the CPU. The
frequency tipping point is at utilization/capacity equal to 80% in
both cases.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
comment "CPU frequency scaling drivers"
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 19:58:03 +05:30
config CPUFREQ_DT
tristate "Generic DT based cpufreq driver"
cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR cpufreq-cpu0 uses thermal framework to register a cooling device, but doesn't depend on it as there are dummy calls provided by thermal layer when CONFIG_THERMAL=n. And when these calls fail, the driver is still usable. Similar explanation is valid for regulators as well. We do have dummy calls available for regulator APIs and the driver can work even when those calls fail. So, we don't really need to mention thermal and regulators as a dependency for cpufreq-cpu0 in Kconfig as platforms without support for thermal/regulator can also use this driver. Remove this dependency. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-10 10:39:46 +05:30
depends on HAVE_CLK && OF
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 19:58:03 +05:30
# if CPU_THERMAL is on and THERMAL=m, CPUFREQ_DT cannot be =y:
cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") was a little too quick in completely removing the dependency on the THERMAL driver. The problem is that while there are inline wrappers to turn the thermal API calls into empty functions, those do not help if the cpu-thermal driver is a loadable module and cpufreq-cpu0 is builtin. Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu code is built into the thermal module or not, we have to use a dependency on the thermal driver itself. However, if CPU_THERMAL is disabled, we don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL' construct. Fixes: 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and REGULATOR") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-06-13 10:40:32 +02:00
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-11 22:12:27 +00:00
select PM_OPP
cpufreq: Add a generic cpufreq-cpu0 driver It adds a generic cpufreq driver for CPU0 frequency management based on clk, regulator, OPP and device tree support. It can support both uniprocessor (UP) and those symmetric multiprocessor (SMP) systems which share clock and voltage across all CPUs. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-06 07:09:11 +00:00
help
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 19:58:03 +05:30
This adds a generic DT based cpufreq driver for frequency management.
cpufreq: Add a generic cpufreq-cpu0 driver It adds a generic cpufreq driver for CPU0 frequency management based on clk, regulator, OPP and device tree support. It can support both uniprocessor (UP) and those symmetric multiprocessor (SMP) systems which share clock and voltage across all CPUs. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2012-09-06 07:09:11 +00:00
It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
systems which share clock and voltage across all CPUs.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if X86
[CPUFREQ] Move x86 drivers to drivers/cpufreq/ Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-19 18:51:07 -04:00
source "drivers/cpufreq/Kconfig.x86"
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
[CPUFREQ] Move x86 drivers to drivers/cpufreq/ Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-19 18:51:07 -04:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if ARM || ARM64
[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-01 14:18:22 -07:00
source "drivers/cpufreq/Kconfig.arm"
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
[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-01 14:18:22 -07:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if PPC32 || PPC64
source "drivers/cpufreq/Kconfig.powerpc"
endif
cpufreq: AVR32: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of AVR32 based at32ap platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:17 +00:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if AVR32
cpufreq: AVR32: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of AVR32 based at32ap platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:17 +00:00
config AVR32_AT32AP_CPUFREQ
bool "CPU frequency driver for AT32AP"
depends on PLATFORM_AT32AP
default n
help
This enables the CPU frequency driver for AT32AP processors.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
cpufreq: AVR32: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of AVR32 based at32ap platform to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:17 +00:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if IA64
cpufreq: ia64: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of IA64 architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:20 +00:00
config IA64_ACPI_CPUFREQ
tristate "ACPI Processor P-States driver"
depends on ACPI_PROCESSOR
help
This driver adds a CPUFreq driver which utilizes the ACPI
Processor Performance States.
For details, take a look at <file:Documentation/cpu-freq/>.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
cpufreq: ia64: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of IA64 architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:20 +00:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if MIPS
cpufreq: mips: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of MIPS architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: John Crispin <blogic@openwrt.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:21 +00:00
config LOONGSON2_CPUFREQ
tristate "Loongson2 CPUFreq Driver"
cpufreq: Add Loongson machine dependencies [ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ] The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan <jhogan@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-15 21:17:55 +00:00
depends on LEMOTE_MACH2F
cpufreq: mips: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of MIPS architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: John Crispin <blogic@openwrt.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:21 +00:00
help
This option adds a CPUFreq driver for loongson processors which
support software configurable cpu frequency.
Loongson2F and it's successors support this feature.
For details, take a look at <file:Documentation/cpu-freq/>.
If in doubt, say N.
cpufreq: Loongson1: Add cpufreq driver for Loongson1B This patch adds cpufreq driver for Loongson1B which is capable of changing the CPU frequency dynamically. Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-17 18:23:31 +08:00
config LOONGSON1_CPUFREQ
tristate "Loongson1 CPUFreq Driver"
cpufreq: Add Loongson machine dependencies [ Upstream commit 0d307935fefa6389eb726c6362351c162c949101 ] The MIPS loongson cpufreq drivers don't build unless configured for the correct machine type, due to dependency on machine specific architecture headers and symbols in machine specific platform code. More specifically loongson1-cpufreq.c uses RST_CPU_EN and RST_CPU, neither of which is defined in asm/mach-loongson32/regs-clk.h unless CONFIG_LOONGSON1_LS1B=y, and loongson2_cpufreq.c references loongson2_clockmod_table[], which is only defined in arch/mips/loongson64/lemote-2f/clock.c, i.e. when CONFIG_LEMOTE_MACH2F=y. Add these dependencies to Kconfig to avoid randconfig / allyesconfig build failures (e.g. when based on BMIPS which also has a cpufreq driver). Signed-off-by: James Hogan <jhogan@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-15 21:17:55 +00:00
depends on LOONGSON1_LS1B
cpufreq: Loongson1: Add cpufreq driver for Loongson1B This patch adds cpufreq driver for Loongson1B which is capable of changing the CPU frequency dynamically. Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-17 18:23:31 +08:00
help
This option adds a CPUFreq driver for loongson1 processors which
support software configurable cpu frequency.
For details, take a look at <file:Documentation/cpu-freq/>.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
cpufreq: Loongson1: Add cpufreq driver for Loongson1B This patch adds cpufreq driver for Loongson1B which is capable of changing the CPU frequency dynamically. Signed-off-by: Kelvin Cheung <keguang.zhang@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-10-17 18:23:31 +08:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if SPARC64
cpufreq: sparc: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:24 +00:00
config SPARC_US3_CPUFREQ
tristate "UltraSPARC-III CPU Frequency driver"
help
This adds the CPUFreq driver for UltraSPARC-III processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
config SPARC_US2E_CPUFREQ
tristate "UltraSPARC-IIe CPU Frequency driver"
help
This adds the CPUFreq driver for UltraSPARC-IIe processors.
For details, take a look at <file:Documentation/cpu-freq>.
If in doubt, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
cpufreq: sparc: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of SPARC architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:24 +00:00
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
if SUPERH
cpufreq: sh: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of SUPERH architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:22 +00:00
config SH_CPU_FREQ
tristate "SuperH CPU Frequency driver"
help
This adds the cpufreq driver for SuperH. Any CPU that supports
clock rate rounding through the clock framework can use this
driver. While it will make the kernel slightly larger, this is
harmless for CPUs that don't support rate rounding. The driver
will also generate a notice in the boot log before disabling
itself if the CPU in question is not capable of rate rounding.
For details, take a look at <file:Documentation/cpu-freq>.
If unsure, say N.
cpufreq: Kconfig: Remove architecture specific menu entries CPUFreq driver's Kconfig entries are added in Kconfig.<arch> files and they are all included from the main Kconfig file using a menu entry. This creates another level of (unnecessary) hierarchy within the menuconfig entries. The problem occurs when there are drivers usable across architectures. Either their config entry is duplicated in all the supported architectures or is put into the main Kconfig entry. With the later one, we have menuconfig entries for drivers at two levels then. Fix these issues by getting rid of another level of menuconfig hierarchy and populate all drivers within the main cpufreq menu. To clearly distinguish where the drivers start from, also add a comment that will appear in menuconfig. Reported-by: Tang Yuantian <Yuantian.Tang@freescale.com> Suggested-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-15 08:50:44 +05:30
endif
cpufreq: sh: move cpufreq driver to drivers/cpufreq This patch moves cpufreq driver of SUPERH architecture to drivers/cpufreq. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-04 12:54:22 +00:00
cpufreq: qoriq: rename the driver This driver works on all QorIQ platforms which include ARM-based cores and PPC-based cores. Rename it in order to represent better. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-13 12:39:02 +08:00
config QORIQ_CPUFREQ
tristate "CPU frequency scaling driver for Freescale QorIQ SoCs"
depends on OF && COMMON_CLK && (PPC_E500MC || ARM)
select CLK_QORIQ
help
This adds the CPUFreq driver support for Freescale QorIQ SoCs
which are capable of changing the CPU's frequency dynamically.
[CPUFREQ] Move x86 drivers to drivers/cpufreq/ Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-19 18:51:07 -04:00
endif
endmenu
Reference in a new issue Copy permalink