kernel/linux.git/include/linux/cpufreq.h, branch linux-2.6.28.y

[CPUFREQ][1/6] cpufreq: Add cpu number parameter to __cpufreq_driver_getavg()

2008-10-09T17:52:43+00:00

Add a cpu parameter to __cpufreq_driver_getavg(). This is needed for software cpufreq coordination where policy->cpu may not be same as the CPU on which we want to getavg frequency. A follow-on patch will use this parameter to getavg freq from all cpus in policy->cpus. Change since last patch. Fix the offline/online and suspend/resume oops reported by Youquan Song Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-07-30T16:41:43+00:00

Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec749a3519069d9390561b5636a75c7579) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: Thomas Renninger Cc: Andi Kleen Cc: Len Brown Cc: Dave Jones Cc: Ingo Molnar Cc: Venkatesh Pallipadi Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

[CPUFREQ] cpufreq: remove CVS keywords

2008-05-19T22:17:49+00:00

This patch removes CVS keywords that weren't updated for a long time from comments. Signed-off-by: Adrian Bunk Signed-off-by: Dave Jones

[CPUFREQ] allow use of the powersave governor as the default one

2008-04-28T20:27:08+00:00

Allow use of the powersave cpufreq governor as the default one for EMBEDDED configs. Signed-off-by: Alessandro Guido Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ] expose cpufreq coordination requirements regardless of coordination mechanism

2008-04-28T20:27:08+00:00

Currently, affected_cpus shows which CPUs need to have their frequency coordinated in software. When hardware coordination is in use, the contents of this file appear the same as when no coordination is required. This can lead to some confusion among user-space programs, for example, that do not know that extra coordination is required to force a CPU core to a particular speed to control power consumption. To fix this, create a "related_cpus" attribute that always displays the coordination map regardless of whatever coordination strategy the cpufreq driver uses (sw or hw). If the cpufreq driver does not provide a value, fall back to policy->cpus. Signed-off-by: Darrick J. Wong Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ] Eliminate cpufreq_userspace scaling_setspeed deadlock

2008-02-07T03:57:58+00:00

Eliminate cpufreq_userspace scaling_setspeed deadlock. Luming Yu recently uncovered yet another cpufreq related deadlock. One thread that continuously switches the governors and the other thread that repeatedly cats the contents of cpufreq directory causes both these threads to go into a deadlock. Detailed examination of the deadlock showed the exact flow before the deadlock as: Thread 1 Thread 2 ________ ________ cats files under /sys/devices/.../cpufreq/ Set governor to userspace Adds a new sysfs entry for scaling_setspeed cats files under /sys/devices/.../cpufreq/ Set governor to performance Holds cpufreq_rw_sem in write mode Sends a STOP notify to userspace governor cat /sys/devices/.../cpufreq/scaling_setspeed Gets a handle on the above sysfs entry with sysfs_get_active Blocks while trying to get cpufreq_rw_sem in read mode Remove a sysfs entry for scaling_setspeed Blocks on sysfs_deactivate while waiting for earlier get_active (on other thread) to drain At this point both threads go into deadlock and any other thread that tries to do anything with sysfs cpufreq will also block. There seems to be no easy way to avoid this deadlock as long as cpufreq_userspace adds/removes the sysfs entry under same kobject as cpufreq. Below patch moves scaling_setspeed to cpufreq.c, keeping it always and calling back the governor on read/write. This is the cleanest fix I could think of, even though adding two callbacks in governor structure just for this seems unnecessary. Note that the change makes scaling_setspeed under /sys/.../cpufreq permanent and returns when governor is not userspace. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones

[CPUFREQ] implement !CONFIG_CPU_FREQ stub for cpufreq_unregister_notifier()

2007-10-04T22:40:57+00:00

Callsites such as arch/powerpc/oprofile/op_model_cell.c are having to open-code #ifdef CONFIG_CPU_FREQ only to be able to get at the full definition of cpufreq_unregister_notifier(), because no empty stub is available for the !CONFIG_CPU_FREQ case. Let's provide one, to be able to remove such #ifdef's from the rest of the kernel tree -- those will come in a subsequent patch. Signed-off-by: Satyam Sharma Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ] Only check for transition latency on problematic governors (kconfig fix)

2007-10-04T22:40:57+00:00

Cc: Adrian Bunk Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ] allow ondemand and conservative cpufreq governors to be used as default

2007-10-04T22:40:57+00:00

Depending on the transition latency of the HW for cpufreq switches, the ondemand or conservative governor cannot be used with certain cpufreq drivers. Still the ondemand should be the default governor on a wide range of systems. This patch allows this and lets the governor fallback to the performance governor at cpufreq driver load time, if the driver does not support fast enough frequency switching. Main benefit is that on e.g. installation or other systems without userspace support a working dynamic cpufreq support can be achieved on most systems by simply loading the cpufreq driver. This is especially essential for recent x86(_64) laptop hardware which may rely on working dynamic cpufreq OS support. Signed-off-by: Thomas Renninger Signed-off-by: Venkatesh Pallipadi Cc: Russell King Cc: Bryan Wu Cc: Andi Kleen Cc: "Luck, Tony" Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Cc: Paul Mundt Cc: "David S. Miller" Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

Revert "[PATCH] x86-64: fix x86_64-mm-sched-clock-share"

2007-09-26T22:52:17+00:00

This reverts commit 184c44d2049c4db7ef6ec65794546954da2c6a0e. As noted by Dave Jones: "Linus, please revert the above cset. It doesn't seem to be necessary (it was added to fix a miscompile in 'make allnoconfig' which doesn't seem to be repeatable with it reverted) and actively breaks the ARM SA1100 framebuffer driver." Requested-by: Dave Jones Cc: Russell King Cc: Andrew Morton Cc: Andi Kleen Signed-off-by: Linus Torvalds