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

Revert "[CPUFREQ] constify cpufreq_driver where possible."

2007-02-26T22:55:48Z

This reverts commit aeeddc1435c37fa3fc844f31d39c185b08de4158, which was half-baked and broken. It just resulted in compile errors, since cpufreq_register_driver() still changes the 'driver_data' by setting bits in the flags field. So claiming it is 'const' _really_ doesn't work. Signed-off-by: Linus Torvalds

[CPUFREQ] constify cpufreq_driver where possible.

2007-02-23T00:08:27Z

Not all cases are possible due to ->flags being set at runtime on some drivers. Signed-off-by: Dave Jones

[CPUFREQ] Rewrite lock in cpufreq to eliminate cpufreq/hotplug related issues

2007-02-11T01:01:47Z

Yet another attempt to resolve cpufreq and hotplug locking issues. Patchset has 3 patches: * Rewrite the lock infrastructure of cpufreq using a per cpu rwsem. * Minor restructuring of work callback in ondemand driver. * Use the new cpufreq rwsem infrastructure in ondemand work. This patch: Convert policy->lock to rwsem and move it to per_cpu area. This rwsem will protect against both changing/accessing policy related parameters and CPU hot plug/unplug. [malattia@linux.it: fix oops in kref_put()] Cc: Gautham R Shenoy Signed-off-by: Venkatesh Pallipadi Cc: Gautham R Shenoy Signed-off-by: Mattia Dongili Signed-off-by: Andrew Morton Signed-off-by: Dave Jones

[CPUFREQ][8/8] acpi-cpufreq: Add support for freq feedback from hardware

2006-10-15T23:57:11Z

Enable ondemand governor and acpi-cpufreq to use IA32_APERF and IA32_MPERF MSR to get active frequency feedback for the last sampling interval. This will make ondemand take right frequency decisions when hardware coordination of frequency is going on. Without APERF/MPERF, ondemand can take wrong decision at times due to underlying hardware coordination or TM2. Example: * CPU 0 and CPU 1 are hardware cooridnated. * CPU 1 running at highest frequency. * CPU 0 was running at highest freq. Now ondemand reduces it to some intermediate frequency based on utilization. * Due to underlying hardware coordination with other CPU 1, CPU 0 continues to run at highest frequency (as long as other CPU is at highest). * When ondemand samples CPU 0 again next time, without actual frequency feedback from APERF/MPERF, it will think that previous frequency change was successful and can go to wrong target frequency. This is because it thinks that utilization it has got this sampling interval is when running at intermediate frequency, rather than actual highest frequency. More information about IA32_APERF IA32_MPERF MSR: Refer to IA-32 Intel® Architecture Software Developer's Manual at http://developer.intel.com Signed-off-by: Venkatesh Pallipadi Signed-off-by: Dave Jones

[PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare

2006-07-26T14:21:40Z

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

ACPI: HW P-state coordination support

2006-06-26T04:34:43Z

Treat HW coordination as independent CPUs. This enables per-cpu monintoring of P-states http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6

2006-06-23T14:52:36Z

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (65 commits) ACPI: suppress power button event on S3 resume ACPI: resolve merge conflict between sem2mutex and processor_perflib.c ACPI: use for_each_possible_cpu() instead of for_each_cpu() ACPI: delete newly added debugging macros in processor_perflib.c ACPI: UP build fix for bugzilla-5737 Enable P-state software coordination via _PDC P-state software coordination for speedstep-centrino P-state software coordination for acpi-cpufreq P-state software coordination for ACPI core ACPI: create acpi_thermal_resume() ACPI: create acpi_fan_suspend()/acpi_fan_resume() ACPI: pass pm_message_t from acpi_device_suspend() to root_suspend() ACPI: create acpi_device_suspend()/acpi_device_resume() ACPI: replace spin_lock_irq with mutex for ec poll mode ACPI: Allow a WAN module enable/disable on a Thinkpad X60. sem2mutex: acpi, acpi_link_lock ACPI: delete unused acpi_bus_drivers_lock sem2mutex: drivers/acpi/processor_perflib.c ACPI add ia64 exports to build acpi_memhotplug as a module ACPI: asus_acpi_init(): propagate correct return value ... Manual resolve of conflicts in: arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c include/acpi/processor.h

Don't include linux/config.h from anywhere else in include/

2006-04-26T11:56:16Z

Signed-off-by: David Woodhouse

P-state software coordination for ACPI core

2006-02-09T08:21:48Z

http://bugzilla.kernel.org/show_bug.cgi?id=5737 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

[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(-)