kernel.git/arch/x86/kernel/cpu/cpufreq, branch linux-2.6.30.y

Fix NULL ptr regression in powernow-k8

2009-10-05T15:28:00Z

commit f0adb134d8dc9993a9998dc50845ec4f6ff4fadc upstream. Fixes bugzilla #13780 From: Kurt Roeckx Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

cpumask: alloc zeroed cpumask for static cpumask_var_ts

2009-06-09T13:00:27Z

These are defined as static cpumask_var_t so if MAXSMP is not used, they are cleared already. Avoid surprises when MAXSMP is enabled. Signed-off-by: Yinghai Lu Signed-off-by: Rusty Russell

[CPUFREQ] powernow-k8: check space_id of _PCT registers to be FFH

2009-06-05T17:25:25Z

The powernow-k8 driver checks to see that the Performance Control/Status Registers are declared as FFH (functional fixed hardware) by the BIOS. However, this check got broken in the commit: 0e64a0c982c06a6b8f5e2a7f29eb108fdf257b2f [CPUFREQ] checkpatch cleanups for powernow-k8 Fix based on an original patch from Naga Chumbalkar. Signed-off-by: Naga Chumbalkar Cc: Mark Langsdorf Signed-off-by: Dave Jones

acpi-cpufreq: fix printk typo and indentation

2009-05-30T01:26:26Z

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

[CPUFREQ] powernow-k8: determine exact CPU frequency for HW Pstates

2009-05-26T16:04:51Z

Slightly modified by trenn@suse.de -> only do this on fam 10h and fam 11h. Currently powernow-k8 determines CPU frequency from ACPI PSS objects, but according to AMD family 11h BKDG this frequency is just a rounded value: "CoreFreq (MHz) = The CPU COF specified by MSRC001_00[6B:64][CpuFid] rounded to the nearest 100 Mhz." As a consequnce powernow-k8 reports wrong CPU frequency on some systems, e.g. on Turion X2 Ultra: powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 cpu cores) (version 2.20.00) powernow-k8: 0 : pstate 0 (2200 MHz) powernow-k8: 1 : pstate 1 (1100 MHz) powernow-k8: 2 : pstate 2 (600 MHz) But this is wrong as frequency for Pstate2 is 550 MHz. x86info reports it correctly: #x86info -a |grep Pstate ... Pstate-0: fid=e, did=0, vid=24 (2200MHz) Pstate-1: fid=e, did=1, vid=30 (1100MHz) Pstate-2: fid=e, did=2, vid=3c (550MHz) (current) Solution is to determine the frequency directly from Pstate MSRs instead of using rounded values from ACPI table. Signed-off-by: Andreas Herrmann Signed-off-by: Thomas Renninger Signed-off-by: Dave Jones

[CPUFREQ] powernow-k8 cleanup msg if BIOS does not export ACPI _PSS cpufreq data

2009-05-26T16:04:51Z

- Make the message shorter and easier to grep for - Use printk_once instead of WARN_ONCE (functionality of these was mixed) Signed-off-by: Thomas Renninger Cc: Langsdorf, Mark Signed-off-by: Dave Jones

[CPUFREQ] powernow-k7 build fix when ACPI=n

2009-05-26T16:04:50Z

arch/x86/kernel/cpu/cpufreq/powernow-k7.c:172: warning: 'invalidate_entry' defined but not used Reported-by: Toralf Förster Signed-off-by: Dave Jones

[CPUFREQ] add atom family to p4-clockmod

2009-05-26T16:04:50Z

Some atom procs don't do freq scaling (such as the atom 330 on my own littlefalls2 board). By adding the atom family here, we at least get the benefit of passive cooling in a thermal emergency. Not sure how to see that its actually helping any, but the driver does bind and claim its functioning on my atom 330. Signed-off-by: Jarod Wilson Signed-off-by: Dave Jones

acpi-cpufreq: Do not let get_measured perf depend on internal variable

2009-04-20T02:47:21Z

Take already available policy->cpuinfo.max_freq and get rid of acpi-cpufreq specific max_freq variable. This implies that P0 is always the highest frequency which should always be true as ACPI spec says: As a result, the zeroth entry describes the highest performance state Signed-off-by: Thomas Renninger Acked-by: Venkatesh Pallipadi Signed-off-by: Len Brown

acpi-cpufreq: style-only: add parens to math expression

2009-04-20T02:47:21Z

Signed-off-by: Thomas Renninger Signed-off-by: Len Brown