linux/drivers/cpufreq, branch v2.6.16

[CPUFREQ] Whitespace/CodingStyle cleanups

2006-02-02T22:03:42Z

Signed-off-by: Dave Jones

[CPUFREQ] Check whether driver init did not initialize current freq

2006-02-02T21:56:41Z

Check whether driver init did not initialize current freq Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] cpufreq_notify_transition cleanup.

2006-01-31T23:53:55Z

Introduce caching of cpufreq_cpu_data[freqs->cpu], which allows us to make the function a lot more readable, and as a nice side-effect, it now fits in < 80 column displays again. Signed-off-by: Dave Jones

[CPUFREQ] Get rid of userspace policy struct, make userspace gov _PPC safe.

2006-01-27T18:36:49Z

Userspace governor need not to hold it's own cpufreq_policy, better make use of the global core policy. Also fixes a bug in case of frequency changes via _PPC. Old min/max values have wrongly been passed to __cpufreq_driver_target() (kind of buffered) and when max freq was available again, only the old max(normally lowest freq) was still active. Signed-off-by: Thomas Renninger Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones cpufreq_userspace.c | 53 +++++++++++++++++++++++++++------------------------- 1 files changed, 28 insertions(+), 25 deletions(-)

[CPUFREQ] _PPC frequency change issues

2006-01-26T18:49:39Z

BIOS might change frequency behind our back when BIOS changes allowed frequencies via _PPC. In this case cpufreq core got out of sync. Ask driver for current freq and notify governors about a change Signed-off-by: Thomas Renninger Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones

[CPUFREQ] Don't free held mutex in cpufreq_add_dev()

2006-01-18T21:53:46Z

Make the cpufreq code play nicely with the mutex debugging code: don't free a held mutex. Cc: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ] convert remaining cpufreq semaphore to a mutex

2006-01-18T21:53:45Z

This one fell through the automation at first because it initializes the semaphore to locked, but that's easily remedied Signed-off-by: Arjan van de Ven Signed-off-by: Dave Jones drivers/cpufreq/cpufreq.c | 37 +++++++++++++++++++------------------ include/linux/cpufreq.h | 3 ++- 2 files changed, 21 insertions(+), 19 deletions(-)

[CPUFREQ] Convert drivers/cpufreq semaphores to mutexes.

2006-01-18T21:53:45Z

Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: Arjan van de Ven Signed-off-by: Ingo Molnar Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[PATCH] Unlinline a bunch of other functions

2006-01-15T02:27:06Z

Remove the "inline" keyword from a bunch of big functions in the kernel with the goal of shrinking it by 30kb to 40kb Signed-off-by: Arjan van de Ven Signed-off-by: Ingo Molnar Acked-by: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[CPUFREQ] CPU frequency display in /proc/cpuinfo

2005-12-07T03:35:11Z

What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of changing frequency? Today the answer is: It depends. On i386: SMP kernel - It is always the boot frequency UP kernel - Scales with the frequency change and shows that was last set. On x86_64: There is one single variable cpu_khz that gets written by all the CPUs. So, the frequency set by last CPU will be seen on /proc/cpuinfo of all the CPUs in the system. What you see also depends on whether you have constant_tsc capable CPU or not. On ia64: It is always boot time frequency of a particular CPU that gets displayed. The patch below changes this to: Show the last known frequency of the particular CPU, when cpufreq is present. If cpu doesnot support changing of frequency through cpufreq, then boot frequency will be shown. The patch affects i386, x86_64 and ia64 architectures. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones