Commit Graph

9 Commits

Author SHA1 Message Date
Stefano Brivio 232e8884cb [CPUFREQ] fix configuration help message
cpufreq support can't be built as a module. Fix the related configuration
help message.

Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Signed-off-by: Dave Jones <davej@redhat.com>
2008-02-06 22:57:58 -05:00
Thomas Renninger 1c2562459f [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-04 18:40:57 -04:00
Mike Frysinger 9101be532a [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-26 14:32:03 -04:00
Adrian Bunk f0ec313a89 [CPUFREQ] CPU_FREQ_TABLE shouldn't be a def_tristate
CPU_FREQ_TABLE enables helper code and gets select'ed when it's required.

Building it as a module when it's not required doesn't seem to make much sense.

Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Jones <davej@redhat.com>
2007-02-10 20:01:48 -05:00
Dave Jones 6af6e1efb1 [PATCH] Fix CPU_FREQ_GOV_ONDEMAND=y compile error
The ONDEMAND governor needs FREQ_TABLE

Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-11-21 14:07:15 -08:00
Erik Mouw 4c41251e31 [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 07:25:54 -05:00
Dave Jones b9170836d1 [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
Dave Jones 3310010818 [CPUFREQ] Add warning comment about default governors.
This comes up time and time again. Until its fixed, place this
comment in the Kconfig which should stem the flow of resubmissions.

Signed-off-by: Rob Weryk <rjweryk@uwo.ca>
Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31 19:03:44 -07:00
Linus Torvalds 1da177e4c3 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