kernel.git/arch/ia64/kernel/cpufreq, branch linux-2.6.28.y

[IA64] improper printk format in acpi-cpufreq

2008-07-17T18:11:17Z

When dprintk is enabled the following warnings are generated: arch/ia64/kernel/cpufreq/acpi-cpufreq.c: In function 'processor_set_pstate': arch/ia64/kernel/cpufreq/acpi-cpufreq.c:54: warning: format '%x' expects type 'unsigned int', but argumen t 3 has type 's64' arch/ia64/kernel/cpufreq/acpi-cpufreq.c: In function 'processor_get_pstate': arch/ia64/kernel/cpufreq/acpi-cpufreq.c:76: warning: format '%x' expects type 'unsigned int', but argumen t 2 has type 's64' Signed-off-by: Denis V. Lunev Signed-off-by: Tony Luck

[CPUFREQ] move policy's governor initialisation out of low-level drivers into cpufreq core

2007-10-04T22:40:57Z

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

[IA64] Fix processor_get_freq

2007-08-15T20:20:38Z

The core cpufreq code doesn't appear to understand returning -EAGAIN for the get() function of the cpufreq_driver. If PAL_GET_PSTATE returns -1, such as when running on Xen, scaling_cur_freq is happy to return 4294967285 kHz (ie. (unsigned)-11). The other drivers appear to return 0 for a failure, and doing so gives me the max frequency from scaling_cur_frequency and "" from cpuinfo_cur_frequency. I believe that's the desired behavior. Signed-off-by: Alex Williamson Acked-by: Venkatesh Pallipadi Signed-off-by: Tony Luck

ACPI: replace kmalloc+memset with kzalloc

2006-12-20T21:54:54Z

Signed-off-by: Andrew Morton Signed-off-by: Len Brown

[PATCH] Add support for type argument in PAL_GET_PSTATE

2006-12-07T19:21:55Z

PAL_GET_PSTATE accepts a type argument to return different kinds of frequency information. Refer: Intel Itanium�Architecture Software Developer's Manual - Volume 2: System Architecture, Revision 2.2 (http://developer.intel.com/design/itanium/manuals/245318.htm) Add the support for type argument and use Instantaneous frequency in the acpi driver. Also fix a bug, where in return value of PAL_GET_PSTATE was getting compared with 'control' bits instead of 'status' bits. Signed-off-by: Venkatesh Pallipadi Signed-off-by: Tony Luck

Remove obsolete #include

2006-06-30T17:25:36Z

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

[ACPI] IA64 ZX1 buildfix for _PDC patch

2005-12-05T22:24:45Z

http://bugzilla.kernel.org/show_bug.cgi?id=5483 ZX1 config doesn't include cpufreq, so move move acpi-processor.c up out of ia64/cpufreq directory. no functional changes Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

[ACPI] Avoid BIOS inflicted crashes by evaluating _PDC only once

2005-12-01T06:30:35Z

Linux invokes the AML _PDC method (Processor Driver Capabilities) to tell the BIOS what features it can handle. While the ACPI spec says nothing about the OS invoking _PDC multiple times, doing so with changing bits seems to hopelessly confuse the BIOS on multiple platforms up to and including crashing the system. Factor out the _PDC invocation so Linux invokes it only once. http://bugzilla.kernel.org/show_bug.cgi?id=5483 Signed-off-by: Venkatesh Pallipadi Signed-off-by: Len Brown

[IA64] Add ACPI based P-state support

2005-08-26T22:09:24Z

Patch to support P-state transitions on ia64. This driver is based on ACPI, and uses the ACPI processor driver interface to find out the P-state support information for the processor. This driver plugs into generic cpufreq infrastructure. Once this driver is loaded successfully, ondemand/userspace governor can be used to change the CPU frequency dynamically based on load or on request from userspace process. Refer : ACPI specification - http://www.acpi.info P-state related PAL calls - http://developer.intel.com/design/itanium/downloads/24869909.pdf Signed-off-by: Venkatesh Pallipadi Signed-off-by: Tony Luck