kernel/linux.git/drivers/cpufreq, branch linux-2.6.18.y

CPUFREQ: Fix some more CPU hotplug locking.

2006-10-13T20:23:26+00:00

[CPUFREQ] Fix some more CPU hotplug locking. Lukewarm IQ detected in hotplug locking BUG: warning at kernel/cpu.c:38/lock_cpu_hotplug() [] lock_cpu_hotplug+0x42/0x65 [] cpufreq_update_policy+0x25/0xad [] kprobe_flush_task+0x18/0x40 [] schedule+0x63f/0x68b [] __link_module+0x0/0x1f [] __cond_resched+0x16/0x34 [] cond_resched+0x26/0x31 [] wait_for_completion+0x17/0xb1 [] cpufreq_stat_cpu_callback+0x13/0x20 [cpufreq_stats] [] cpufreq_stats_init+0x74/0x8b [cpufreq_stats] [] sys_init_module+0x91/0x174 [] 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 Signed-off-by: Greg Kroah-Hartman

[CPUFREQ] [2/2] demand load governor modules.

2006-07-31T22:37:06+00:00

Demand-load cpufreq governor modules if needed. Signed-off-by: Jeremy Fitzhardinge Signed-off-by: Dave Jones

[CPUFREQ] [1/2] add __find_governor helper and clean up some error handling.

2006-07-31T22:37:06+00:00

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 Signed-off-by: Dave Jones

[CPUFREQ] return error when failing to set minfreq

2006-07-31T22:37:05+00:00

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 Signed-off-by: Dominik Brodowski Signed-off-by: Dave Jones --

[PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare

2006-07-26T14:21:40+00:00

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 Signed-off-by: Linus Torvalds

[cpufreq] ondemand: make shutdown sequence more robust

2006-07-23T19:05:00+00:00

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

[PATCH] Fix cpufreq vs hotplug lockdep recursion.

2006-07-07T16:46:45+00:00

[ 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: [] mutex_lock+0x21/0x24 > > but task is already holding lock: > (cpucontrol){--..}, at: [] 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 Signed-off-by: Dave Jones Signed-off-by: Linus Torvalds

Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq

2006-07-04T21:00:26+00:00

* 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.

Remove obsolete #include

2006-06-30T17:25:36+00:00

Signed-off-by: Jörn Engel Signed-off-by: Adrian Bunk

[CPUFREQ] Misc cleanups in ondemand.

2006-06-30T05:36:40+00:00

Misc cleanups in ondemand. Should have zero functional impact. Also adding Alexey as author. Signed-off-by: Alexey Starikovskiy Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones