linux-toradex.git/drivers/cpufreq, branch v2.6.19

[PATCH] Fix CPU_FREQ_GOV_ONDEMAND=y compile error

2006-11-21T22:07:15+00:00

The ONDEMAND governor needs FREQ_TABLE

Signed-off-by: Mattia Dongili 
Signed-off-by: Dave Jones 
Signed-off-by: Linus Torvalds

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 some more CPU hotplug locking.

2006-09-22T23:15:23+00:00

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

[CPUFREQ] Fix sparse warning in ondemand

2006-09-05T21:15:47+00:00

drivers/cpufreq/cpufreq_ondemand.c:323:2: warning: Using plain integer as NULL pointer

Signed-off-by: Dave Jones

[CPUFREQ] make drivers/cpufreq/cpufreq_ondemand.c:powersave_bias_target() static

2006-08-14T05:18:54+00:00

This patch makes the needlessly global powersave_bias_target() static.

Signed-off-by: Adrian Bunk 
Signed-off-by: Dave Jones

[CPUFREQ][2/2] ondemand: updated add powersave_bias tunable

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

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

[CPUFREQ][1/2] ondemand: updated tune for hardware coordination

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

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

[CPUFREQ] Fix typo.

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

Signed-off-by: Dave Jones