]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
[PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare
authorArjan van de Ven <arjan@linux.intel.com>
Wed, 26 Jul 2006 13:40:07 +0000 (15:40 +0200)
committerLinus Torvalds <torvalds@g5.osdl.org>
Wed, 26 Jul 2006 14:21:40 +0000 (07:21 -0700)
commit153d7f3fcae7ed4e19328549aa9467acdfbced10
treea7b15b844119663a276c7a99549ea5a06c16f19a
parent44eb123126d289bac398cac0232309c228386671
[PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare

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>
drivers/cpufreq/cpufreq.c
drivers/cpufreq/cpufreq_conservative.c
drivers/cpufreq/cpufreq_ondemand.c
drivers/cpufreq/cpufreq_userspace.c
include/linux/cpufreq.h