linux-toradex.git/drivers/cpufreq/cpufreq.c, branch v2.6.19.2

Add "pure_initcall" for static variable initialization

2006-11-20T19:47:18+00:00

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 
Cc: Ingo Molnar 
Cc: Arjan van de Ven 
Cc: Andrew Morton ,
Signed-off-by: Linus Torvalds

[PATCH] cpufreq: make the transition_notifier chain use SRCU

2006-10-04T14:55:30+00:00

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 
Cc: "Paul E. McKenney" 
Cc: Jesse Brandeburg 
Cc: Dave Jones 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[CPUFREQ] Fix cut-n-paste bug in suspend printk

2006-09-27T03:02:34+00:00

Signed-off-by: Dave Jones

[CPUFREQ] Fix typo.

2006-08-11T21:59:28+00:00

Signed-off-by: Dave Jones

[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

[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

Remove obsolete #include

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

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