aboutsummaryrefslogtreecommitdiff
path: root/drivers/cpufreq/Kconfig
AgeCommit message (Collapse)Author
2007-02-10[CPUFREQ] CPU_FREQ_TABLE shouldn't be a def_tristateAdrian Bunk
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>
2006-11-21[PATCH] Fix CPU_FREQ_GOV_ONDEMAND=y compile errorDave Jones
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-04-03[CPUFREQ] Update LART site URLErik Mouw
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>
2005-05-31[CPUFREQ] Conservative cpufreq governerDave Jones
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[CPUFREQ] Add warning comment about default governors.Dave Jones
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-04-16Linux-2.6.12-rc2Linus Torvalds
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!