aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
Commit message (Collapse)AuthorAge
* WorkStruct: make allyesconfigDavid Howells2006-11-22
| | | | | | Fix up for make allyesconfig. Signed-Off-By: David Howells <dhowells@redhat.com>
* WorkStruct: Pass the work_struct pointer instead of context dataDavid Howells2006-11-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pass the work_struct pointer to the work function rather than context data. The work function can use container_of() to work out the data. For the cases where the container of the work_struct may go away the moment the pending bit is cleared, it is made possible to defer the release of the structure by deferring the clearing of the pending bit. To make this work, an extra flag is introduced into the management side of the work_struct. This governs auto-release of the structure upon execution. Ordinarily, the work queue executor would release the work_struct for further scheduling or deallocation by clearing the pending bit prior to jumping to the work function. This means that, unless the driver makes some guarantee itself that the work_struct won't go away, the work function may not access anything else in the work_struct or its container lest they be deallocated.. This is a problem if the auxiliary data is taken away (as done by the last patch). However, if the pending bit is *not* cleared before jumping to the work function, then the work function *may* access the work_struct and its container with no problems. But then the work function must itself release the work_struct by calling work_release(). In most cases, automatic release is fine, so this is the default. Special initiators exist for the non-auto-release case (ending in _NAR). Signed-Off-By: David Howells <dhowells@redhat.com>
* [PATCH] Fix CPU_FREQ_GOV_ONDEMAND=y compile errorDave Jones2006-11-21
| | | | | | | | 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>
* Add "pure_initcall" for static variable initializationLinus Torvalds2006-11-20
| | | | | | | | | | | | | | | | | | | | This is a quick hack to overcome the fact that SRCU currently does not allow static initializers, and we need to sometimes initialize those things before any other initializers (even "core" ones) can do so. Currently we don't allow this at all for modules, and the only user that needs is right now is cpufreq. As reported by Thomas Gleixner: "Commit b4dfdbb3c707474a2254c5b4d7e62be31a4b7da9 ("[PATCH] cpufreq: make the transition_notifier chain use SRCU breaks cpu frequency notification users, which register the callback > on core_init level." Cc: Thomas Gleixner <tglx@timesys.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Arjan van de Ven <arjan@infradead.org> Cc: Andrew Morton <akpm@osdl.org>, Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpufreq: make the transition_notifier chain use SRCUAlan Stern2006-10-04
| | | | | | | | | | | | | | | | | | | | | | This patch (as762) changes the cpufreq_transition_notifier_list from a blocking_notifier_head to an srcu_notifier_head. This will prevent errors caused attempting to call down_read() to access the notifier chain at a time when interrupts must remain disabled, during system suspend. It's not clear to me whether this is really necessary; perhaps the chain could be made into an atomic_notifier. However a couple of the callout routines do use blocking operations, so this approach seems safer. The head of the notifier chain needs to be initialized before use; this is done by an __init routine at core_initcall time. If this turns out not to be a good choice, it can easily be changed. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Cc: "Paul E. McKenney" <paulmck@us.ibm.com> Cc: Jesse Brandeburg <jesse.brandeburg@gmail.com> Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] Fix cut-n-paste bug in suspend printkDave Jones2006-09-26
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix some more CPU hotplug locking.Dave Jones2006-09-22
| | | | | | | | | | | | | | | | | | | | | | | Lukewarm IQ detected in hotplug locking BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() [<b0134a42>] lock_cpu_hotplug+0x42/0x65 [<b02f8af1>] cpufreq_update_policy+0x25/0xad [<b0358756>] kprobe_flush_task+0x18/0x40 [<b0355aab>] schedule+0x63f/0x68b [<b01377c2>] __link_module+0x0/0x1f [<b0119e7d>] __cond_resched+0x16/0x34 [<b03560bf>] cond_resched+0x26/0x31 [<b0355b0e>] wait_for_completion+0x17/0xb1 [<f965c547>] cpufreq_stat_cpu_callback+0x13/0x20 [cpufreq_stats] [<f9670074>] cpufreq_stats_init+0x74/0x8b [cpufreq_stats] [<b0137872>] sys_init_module+0x91/0x174 [<b0102c81>] sysenter_past_esp+0x56/0x79 As there are other places that call cpufreq_update_policy without the hotplug lock, it seems better to keep the hotplug locking at the lower level for the time being until this is revamped. Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix sparse warning in ondemandDave Jones2006-09-05
| | | | | | drivers/cpufreq/cpufreq_ondemand.c:323:2: warning: Using plain integer as NULL pointer Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() staticAdrian Bunk2006-08-14
| | | | | | | This patch makes the needlessly global powersave_bias_target() static. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ][2/2] ondemand: updated add powersave_bias tunableAlexey Starikovskiy2006-08-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ondemand selects the minimum frequency that can retire a workload with negligible idle time -- ideally resulting in the highest performance/power efficiency with negligible performance impact. But on some systems and some workloads, this algorithm is more performance biased than necessary, and de-tuning it a bit to allow some performance impact can save measurable power. This patch adds a "powersave_bias" tunable to ondemand to allow it to reduce its target frequency by a specified percent. By default, the powersave_bias is 0 and has no effect. powersave_bias is in units of 0.1%, so it has an effective range of 1 through 1000, resulting in 0.1% to 100% impact. In practice, users will not be able to detect a difference between 0.1% increments, but 1.0% increments turned out to be too large. Also, the max value of 1000 (100%) would simply peg the system in its deepest power saving P-state, unless the processor really has a hardware P-state at 0Hz:-) For example, If ondemand requests 2.0GHz based on utilization, and powersave_bias=100, this code will knock 10% off the target and seek a target of 1.8GHz instead of 2.0GHz until the next sampling. If 1.8 is an exact match with an hardware frequency we use it, otherwise we average our time between the frequency next higher than 1.8 and next lower than 1.8. Note that a user or administrative program can change powersave_bias at run-time depending on how they expect the system to be used. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com> Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ][1/2] ondemand: updated tune for hardware coordinationAlexey Starikovskiy2006-08-11
| | | | | | | | | Try to make dbs_check_cpu() call on all CPUs at the same jiffy. This will help when multiple cores share P-states via Hardware Coordination. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi at intel.com> Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy at intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix typo.Dave Jones2006-08-11
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] [2/2] demand load governor modules.Jeremy Fitzhardinge2006-07-31
| | | | | | | Demand-load cpufreq governor modules if needed. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] [1/2] add __find_governor helper and clean up some error handling.Jeremy Fitzhardinge2006-07-31
| | | | | | | | | Adds a __find_governor() helper function to look up a governor by name. Also restructures some error handling to conform to the "single-exit" model which is generally preferred for kernel code. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] return error when failing to set minfreqMattia Dongili2006-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I just stumbled on this bug/feature, this is how to reproduce it: # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq # echo 450000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq # echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor # cpufreq-info -p 450000 450000 powersave # echo 1800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq ; echo $? 0 # cpufreq-info -p 450000 450000 powersave Here it is. The kernel refuses to set a min_freq higher than the max_freq but it allows a max_freq lower than min_freq (lowering min_freq also). This behaviour is pretty straightforward (but undocumented) and it doesn't return an error altough failing to accomplish the requested action (set min_freq). The problem (IMO) is basically that userspace is not allowed to set a full policy atomically while the kernel always does that thus it must enforce an ordering on operations. The attached patch returns -EINVAL if trying to increase frequencies starting from scaling_min_freq and documents the correct ordering of writes. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Dominik Brodowski <linux at dominikbrodowski.net> Signed-off-by: Dave Jones <davej@redhat.com> --
* [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizareArjan van de Ven2006-07-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch below moves the cpu hotplugging higher up in the cpufreq layering; this is needed to avoid recursive taking of the cpu hotplug lock and to otherwise detangle the mess. The new rules are: 1. you must do lock_cpu_hotplug() around the following functions: __cpufreq_driver_target __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only) __cpufreq_set_policy 2. governer methods (.governer) must NOT take the lock_cpu_hotplug() lock in any way; they are called with the lock taken already 3. if your governer spawns a thread that does things, like calling __cpufreq_driver_target, your thread must honor rule #1. 4. the policy lock and other cpufreq internal locks nest within the lock_cpu_hotplug() lock. I'm not entirely happy about how the __cpufreq_governor rule ended up (conditional locking rule depending on the argument) but basically all callers pass this as a constant so it's not too horrible. The patch also removes the cpufreq_governor() function since during the locking audit it turned out to be entirely unused (so no need to fix it) The patch works on my testbox, but it could use more testing (otoh... it can't be much worse than the current code) Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [cpufreq] ondemand: make shutdown sequence more robustLinus Torvalds2006-07-23
| | | | | | | | | | | Shutting down the ondemand policy was fraught with potential problems, causing issues for SMP suspend (which wants to hot- unplug) all but the last CPU. This should fix at least the worst problems (divide-by-zero and infinite wait for the workqueue to shut down). Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Fix cpufreq vs hotplug lockdep recursion.Dave Jones2006-07-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | [ There's some not quite baked bits in cpufreq-git right now so sending this on as a patch instead ] On Thu, 2006-07-06 at 07:58 -0700, Tom London wrote: > After installing .2356 I get this each time I boot: > ======================================================= > [ INFO: possible circular locking dependency detected ] > ------------------------------------------------------- > S06cpuspeed/1620 is trying to acquire lock: > (dbs_mutex){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24 > > but task is already holding lock: > (cpucontrol){--..}, at: [<c060d6bb>] mutex_lock+0x21/0x24 > > which lock already depends on the new lock. > make sure the cpu hotplug recursive mutex (yuck) is taken early in the cpufreq codepaths to avoid a AB-BA deadlock. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds2006-07-04
|\ | | | | | | | | | | | | | | | | * master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: Move workqueue exports to where the functions are defined. [CPUFREQ] Misc cleanups in ondemand. [CPUFREQ] Make ondemand sampling per CPU and remove the mutex usage in sampling path. [CPUFREQ] Add queue_delayed_work_on() interface for workqueues. [CPUFREQ] Remove slowdown from ondemand sampling path.
| * [CPUFREQ] Misc cleanups in ondemand.Venkatesh Pallipadi2006-06-30
| | | | | | | | | | | | | | | | | | Misc cleanups in ondemand. Should have zero functional impact. Also adding Alexey as author. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
| * [CPUFREQ] Make ondemand sampling per CPU and remove the mutex usage in ↵Venkatesh Pallipadi2006-06-30
| | | | | | | | | | | | | | | | | | | | sampling path. Make ondemand sampling per CPU and remove the mutex usage in sampling path. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
| * [CPUFREQ] Remove slowdown from ondemand sampling path.Venkatesh Pallipadi2006-06-30
| | | | | | | | | | | | | | | | | | | | | | Remove slowdown from ondemand sampling path. This reduces the code path length in dbs_check_cpu() by half. slowdown was not used by ondemand by default. If there are any user level tools that were using this tunable, they may report error now. Signed-off-by: Alexey Starikovskiy <alexey.y.starikovskiy@intel.com> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* | Remove obsolete #include <linux/config.h>Jörn Engel2006-06-30
|/ | | | | Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
* [PATCH] cpu hotplug: make cpu_notifier related notifier blocks __cpuinit onlyChandra Seetharaman2006-06-27
| | | | | | | | | | | | Make notifier_blocks associated with cpu_notifier as __cpuinitdata. __cpuinitdata makes sure that the data is init time only unless CONFIG_HOTPLUG_CPU is defined. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpu hotplug: make [un]register_cpu_notifier init time onlyChandra Seetharaman2006-06-27
| | | | | | | | | | | | | | | | CPUs come online only at init time (unless CONFIG_HOTPLUG_CPU is defined). So, cpu_notifier functionality need to be available only at init time. This patch makes register_cpu_notifier() available only at init time, unless CONFIG_HOTPLUG_CPU is defined. This patch exports register_cpu_notifier() and unregister_cpu_notifier() only if CONFIG_HOTPLUG_CPU is defined. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpu hotplug: revert init patch submitted for 2.6.17Chandra Seetharaman2006-06-27
| | | | | | | | | | | | | | | | | | | | | In 2.6.17, there was a problem with cpu_notifiers and XFS. I provided a band-aid solution to solve that problem. In the process, i undid all the changes you both were making to ensure that these notifiers were available only at init time (unless CONFIG_HOTPLUG_CPU is defined). We deferred the real fix to 2.6.18. Here is a set of patches that fixes the XFS problem cleanly and makes the cpu notifiers available only at init time (unless CONFIG_HOTPLUG_CPU is defined). If CONFIG_HOTPLUG_CPU is defined then cpu notifiers are available at run time. This patch reverts the notifier_call changes made in 2.6.17 Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] cpufreq build fixAndrew Morton2006-06-23
| | | | | | | | | | | | | drivers/cpufreq/cpufreq_ondemand.c: In function 'do_dbs_timer': drivers/cpufreq/cpufreq_ondemand.c:374: warning: implicit declaration of function 'lock_cpu_hotplug' drivers/cpufreq/cpufreq_ondemand.c:381: warning: implicit declaration of function 'unlock_cpu_hotplug' drivers/cpufreq/cpufreq_conservative.c: In function 'do_dbs_timer': drivers/cpufreq/cpufreq_conservative.c:425: warning: implicit declaration of function 'lock_cpu_hotplug' drivers/cpufreq/cpufreq_conservative.c:432: warning: implicit declaration of function 'unlock_cpu_hotplug' Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] Fix ondemand vs suspend deadlockVenkatesh Pallipadi2006-06-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rootcaused the bug to a deadlock in cpufreq and ondemand. Due to non-existent ordering between cpu_hotplug lock and dbs_mutex. Basically a race condition between cpu_down() and do_dbs_timer(). cpu_down() flow: * cpu_down() call for CPU 1 * Takes hot plug lock * Calls pre down notifier * cpufreq notifier handler calls cpufreq_driver_target() which takes cpu_hotplug lock again. OK as cpu_hotplug lock is recursive in same process context * CPU 1 goes down * Calls post down notifier * cpufreq notifier handler calls ondemand event stop which takes dbs_mutex So, cpu_hotplug lock is taken before dbs_mutex in this flow. do_dbs_timer is triggerred by a periodic timer event. It first takes dbs_mutex and then takes cpu_hotplug lock in cpufreq_driver_target(). Note the reverse order here compared to above. So, if this timer event happens at right moment during cpu_down, system will deadlok. Attached patch fixes the issue for both ondemand and conservative. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] cpufreq core {d,}printk adjustmentsJan Beulich2006-06-04
| | | | | | | Remove KERN_* suffixes from some cpufreq driver's dprintk-s. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove more freq_table reinitialisations.Dave Jones2006-05-30
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Fix another redundant initialisation in freq_tableDave Jones2006-05-30
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Remove duplicate assignment in freq_tableDave Jones2006-05-30
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] CodingStyle nits in cpufreq_stats.cDave Jones2006-05-30
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [PATCH] x86_64: Move ondemand timer into own work queueAndi Kleen2006-05-08
| | | | | | | | | | | | | | | | Taking the cpu hotplug semaphore in a normal events workqueue is unsafe because other tasks can wait for any workqueues with it hold. This results in a deadlock. Move the DBS timer into its own work queue which is not affected by other work queue flushes to avoid this. Has been acked by Venkatesh. Cc: venkatesh.pallipadi@intel.com Cc: cpufreq@lists.linux.org.uk Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] Remove __devinit and __cpuinit from notifier_call definitionsChandra Seetharaman2006-04-26
| | | | | | | | | | | | | Few of the notifier_chain_register() callers use __init in the definition of notifier_call. It is incorrect as the function definition should be available after the initializations (they do not unregister them during initializations). This patch fixes all such usages to _not_ have the notifier_call __init section. Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [CPUFREQ] drivers/cpufreq/cpufreq.c: static functions mustn't be exportedAdrian Bunk2006-04-18
| | | | | | | This patch removes the EXPORT_SYMBOL_GPL of the static function cpufreq_parse_governor(). Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] If max_freq got reduced (e.g. by _PPC) a write to sysfs ↵Thomas Renninger2006-04-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | scaling_governor let cpufreq core stuck at low max_freq for ever The previous patch had bugs (locking and refcount). This one could also be related to the latest DELL reports. But they only slip into this if a user prog (e.g. powersave daemon does when AC got (un) plugged due to a scheme change) echos something to /sys/../cpufreq/scaling_governor while the frequencies got limited by BIOS. This one works: Subject: Max freq stucks at low freq if reduced by _PPC and sysfs gov access The problem is reproducable by(if machine is limiting freqs via BIOS): - Unplugging AC -> max freq gets limited - echo ${governor} >/sys/.../cpufreq/scaling_governor (policy->user_data.max gets overridden with policy->max and will never come up again.) This patch exchanged the cpufreq_set_policy call to __cpufreq_set_policy and duplicated it's functionality but did not override user_data.max. The same happens with overridding min/max values. If freqs are limited and you override the min freq value, the max freq global value will also get stuck to the limited freq, even if BIOS allows all freqs again. Last scenario does only happen if BIOS does not reduce the frequency to the lowest value (should never happen, just for correctness...) drivers/cpufreq/cpufreq.c | 17 +++++++++++++++-- 1 files changed, 15 insertions(+), 2 deletions(-) Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Update LART site URLErik Mouw2006-04-03
| | | | | | | | | | 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>
* [CPUFREQ] Remove pointless check in conservative governor.Dave Jones2006-04-01
| | | | | | < 0 checks on unsigned variables are pointless. Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] trailing whitespace removal de-jour.Dave Jones2006-03-29
| | | | Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] extra debugging in cpufreq_add_dev()Dave Jones2006-03-29
| | | | | Snipped from an otherwise rejected patch by Jan Beulich <jbeulich@novell.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] cpufreq_conservative: keep ignore_nice_load and freq_step values ↵Mattia Dongili2006-03-28
| | | | | | | | | | when reselected Keep the value of ignore_nice_load and freq_step of the conservative governor after the governor is deselected and reselected. Signed-off-by: Mattia Dongili <malattia@linux.it> Signed-off-by: Dave Jones <davej@redhat.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/brodo/cpufreq-2.6Dave Jones2006-03-27
|\
| * [PATCH] cpufreq_ondemand: add range checkDominik Brodowski2006-03-26
| | | | | | | | | | | | | | Assert that cpufreq_target is, at least, called with the minimum frequency allowed by this policy, not something lower. It triggered problems on ARM. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_ondemand: keep ignore_nice_load value when it is reselectedEric Piel2006-03-26
| | | | | | | | | | | | | | | | | | | | | | Keep the value of ignore_nice_load of the ondemand governor even after the governor has been deselected and selected back. This is the behavior of the other exported values of the ondemand governor and it's much more user-friendly. Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_ondemand: Warn if it cannot run due to too long transition ↵Eric Piel2006-03-26
| | | | | | | | | | | | | | | | | | | | | | latency Display a warning if the ondemand governor can not be selected due to a transition latency of the cpufreq driver which is too long. Signed-off-by: Eric Piel <eric.piel@tremplin-utc.net> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: alternative initialise approachAlexander Clouter2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | Venki, author of cpufreq_ondemand, came up with a neater way to remove the initialiser code from the main loop of my code and out to the point when the governor is actually initialised. Not only does it look but it also feels cleaner, plus its simpler to understand. It also saves a bunch of pointless conditional statements in the main loop. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: make for_each_cpu() safeAlexander Clouter2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All these changes should make cpufreq_conservative safe in regards to the x86 for_each_cpu cpumask.h changes and whatnot. Whilst making it safe a number of pointless for loops related to the cpu mask's were removed. I was never comfortable with all those for loops, especially as the iteration is over the same data again and again for each CPU you had in a single poll, an O(n^2) outcome to frequency scaling. The approach I use is to assume by default no CPU's exist and it sets the requested_freq to zero as a kind of flag, the reasoning is in the source ;) If the CPU is queried and requested_freq is zero then it initialises the variable to current_freq and then continues as if nothing happened which should be the same net effect as before? Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: alter default responsivenessAlexander Clouter2006-03-26
| | | | | | | | | | | | | | | | | | | | | | The sensible approach to making conservative less responsive than ondemand :) As mentioned in patch [1/4]. We do not want conservative to shoot through all the frequencies, its point (by default) is to slowly move through them. By default its ten times less responsive. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
| * [PATCH] cpufreq_conservative: aligning of codebase with ondemandAlexander Clouter2006-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the conservative govenor was released its codebase has drifted from the the direction and updates that have been applied to the ondemand govornor. This patch addresses the lack of updates in that period and brings conservative back up to date. The resulting diff file between cpufreq_ondemand.c and cpufreq_conservative.c is now much smaller and shows more clearly the differences between the two. Another reason to do this is ages ago, knowingly, I did a piss poor attempt at making conservative less responsive by knocking up DEF_SAMPLING_RATE_LATENCY_MULTIPLIER by two orders of magnitude. I did fix this ages ago but in my dis-organisation I must have toasted the diff and left it the way it was. About two weeks ago a user contacted me saying he was having problems with the conservative governor with his AMD Athlon XP-M 2800+ as /sys/devices/system/cpu/cpu0/cpufreq/conservative showed sampling_rate_min 9950000 sampling_rate_max 1360065408 Nine seconds to decide about changing the frequency....not too responsive :) Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-27 16:27:41 -0500