2005-04-16 15:20:36 -07:00
|
|
|
/*
|
2006-06-04 16:37:58 -07:00
|
|
|
* (c) 2003-2006 Advanced Micro Devices, Inc.
|
2005-04-16 15:20:36 -07:00
|
|
|
* Your use of this code is subject to the terms and conditions of the
|
|
|
|
* GNU general public license version 2. See "COPYING" or
|
|
|
|
* http://www.gnu.org/licenses/gpl.html
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct powernow_k8_data {
|
|
|
|
unsigned int cpu;
|
|
|
|
|
|
|
|
u32 numps; /* number of p-states */
|
|
|
|
u32 batps; /* number of p-states supported on battery */
|
|
|
|
|
|
|
|
/* these values are constant when the PSB is used to determine
|
|
|
|
* vid/fid pairings, but are modified during the ->target() call
|
|
|
|
* when ACPI is used */
|
|
|
|
u32 rvo; /* ramp voltage offset */
|
|
|
|
u32 irt; /* isochronous relief time */
|
|
|
|
u32 vidmvs; /* usable value calculated from mvs */
|
|
|
|
u32 vstable; /* voltage stabilization time, units 20 us */
|
|
|
|
u32 plllock; /* pll lock time, units 1 us */
|
2005-07-28 09:40:04 -07:00
|
|
|
u32 exttype; /* extended interface = 1 */
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-10-17 14:52:08 -07:00
|
|
|
/* keep track of the current fid / vid or pstate */
|
[CPUFREQ] powernow-k8: ignore out-of-range PstateStatus value
A workaround for AMD CPU family 11h erratum 311 might cause that the
P-state Status Register shows a "current P-state" which is larger than
the "current P-state limit" in P-state Current Limit Register. For the
wrong P-state value there is no ACPI _PSS object defined and
powernow-k8/cpufreq can't determine the proper CPU frequency for that
state.
As a consequence this can cause a panic during boot (potentially with
all recent kernel versions -- at least I have reproduced it with
various 2.6.27 kernels and with the current .28 series), as an
example:
powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \
)
powernow-k8: 0 : pstate 0 (2200 MHz)
powernow-k8: 1 : pstate 1 (1100 MHz)
powernow-k8: 2 : pstate 2 (600 MHz)
BUG: unable to handle kernel paging request at ffff88086e7528b8
IP: [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
PGD 202063 PUD 0
Oops: 0002 [#1] SMP
last sysfs file:
CPU 1
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16
RIP: 0010:[<ffffffff80486361>] [<ffffffff80486361>] cpufreq_stats_update+0x4a/0\
f
Synaptics claims to have extended capabilities, but I'm not able to read them.<6\
6
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0
RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c
RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080
R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10
R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000
Unable to initialize Synaptics hardware.
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0)
Stack:
ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7
ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000
ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10
Call Trace:
[<ffffffff804863c7>] ? cpufreq_stat_notifier_trans+0x51/0x83
[<ffffffff8024b46c>] ? notifier_call_chain+0x29/0x4c
[<ffffffff8024b561>] ? __srcu_notifier_call_chain+0x46/0x61
[<ffffffff8048496d>] ? cpufreq_notify_transition+0x93/0xa9
[<ffffffff8021ab8d>] ? powernowk8_target+0x1e8/0x5f3
[<ffffffff80486687>] ? cpufreq_governor_performance+0x1b/0x20
[<ffffffff80484886>] ? __cpufreq_governor+0x71/0xa8
[<ffffffff80484b21>] ? __cpufreq_set_policy+0x101/0x13e
[<ffffffff80485bcd>] ? cpufreq_add_dev+0x3f0/0x4cd
[<ffffffff8048577a>] ? handle_update+0x0/0x8
[<ffffffff803c2062>] ? sysdev_driver_register+0xb6/0x10d
[<ffffffff8056592c>] ? powernowk8_init+0x0/0x7e
[<ffffffff8048604c>] ? cpufreq_register_driver+0x8f/0x140
[<ffffffff80209056>] ? _stext+0x56/0x14f
[<ffffffff802c2234>] ? proc_register+0x122/0x17d
[<ffffffff802c23a0>] ? create_proc_entry+0x73/0x8a
[<ffffffff8025c259>] ? register_irq_proc+0x92/0xaa
[<ffffffff8025c2c8>] ? init_irq_proc+0x57/0x69
[<ffffffff807fc85f>] ? kernel_init+0x116/0x169
[<ffffffff8020cc79>] ? child_rip+0xa/0x11
[<ffffffff807fc749>] ? kernel_init+0x0/0x169
[<ffffffff8020cc6f>] ? child_rip+0x0/0x11
Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\
RIP [<ffffffff80486361>] cpufreq_stats_update+0x4a/0x5f
RSP <ffff88006fb83b20>
CR2: ffff88086e7528b8
---[ end trace 0678bac75e67a2f7 ]---
Kernel panic - not syncing: Attempted to kill init!
In short, aftereffect of the wrong P-state is that
cpufreq_stats_update() uses "-1" as index for some array in
cpufreq_stats_update (unsigned int cpu)
{
...
if (stat->time_in_state)
stat->time_in_state[stat->last_index] =
cputime64_add(stat->time_in_state[stat->last_index],
cputime_sub(cur_time, stat->last_time));
...
}
Fortunately, the wrong P-state value is returned only if the core is
in P-state 0. This fix solves the problem by detecting the
out-of-range P-state, ignoring it, and using "0" instead.
Cc: Mark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Dave Jones <davej@redhat.com>
2008-11-21 06:49:25 -07:00
|
|
|
u32 currvid;
|
|
|
|
u32 currfid;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* the powernow_table includes all frequency and vid/fid pairings:
|
|
|
|
* fid are the lower 8 bits of the index, vid are the upper 8 bits.
|
|
|
|
* frequency is in kHz */
|
|
|
|
struct cpufreq_frequency_table *powernow_table;
|
|
|
|
|
|
|
|
/* the acpi table needs to be kept. it's only available if ACPI was
|
|
|
|
* used to determine valid frequency/vid/fid states */
|
2008-08-19 13:34:59 -07:00
|
|
|
struct acpi_processor_performance acpi_data;
|
2009-02-03 17:17:45 -07:00
|
|
|
|
2006-06-04 16:37:58 -07:00
|
|
|
/* we need to keep track of associated cores, but let cpufreq
|
|
|
|
* handle hotplug events - so just point at cpufreq pol->cpus
|
|
|
|
* structure */
|
2009-01-04 06:18:06 -07:00
|
|
|
struct cpumask *available_cores;
|
2005-04-16 15:20:36 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
/* processor's cpuid instruction support */
|
|
|
|
#define CPUID_PROCESSOR_SIGNATURE 1 /* function 1 */
|
|
|
|
#define CPUID_XFAM 0x0ff00000 /* extended family */
|
|
|
|
#define CPUID_XFAM_K8 0
|
|
|
|
#define CPUID_XMOD 0x000f0000 /* extended model */
|
2007-12-14 12:00:23 -07:00
|
|
|
#define CPUID_XMOD_REV_MASK 0x000c0000
|
2007-05-13 08:55:14 -07:00
|
|
|
#define CPUID_XFAM_10H 0x00100000 /* family 0x10 */
|
2005-04-16 15:20:36 -07:00
|
|
|
#define CPUID_USE_XFAM_XMOD 0x00000f00
|
|
|
|
#define CPUID_GET_MAX_CAPABILITIES 0x80000000
|
|
|
|
#define CPUID_FREQ_VOLT_CAPABILITIES 0x80000007
|
|
|
|
#define P_STATE_TRANSITION_CAPABLE 6
|
|
|
|
|
|
|
|
/* Model Specific Registers for p-state transitions. MSRs are 64-bit. For */
|
|
|
|
/* writes (wrmsr - opcode 0f 30), the register number is placed in ecx, and */
|
|
|
|
/* the value to write is placed in edx:eax. For reads (rdmsr - opcode 0f 32), */
|
|
|
|
/* the register number is placed in ecx, and the data is returned in edx:eax. */
|
|
|
|
|
|
|
|
#define MSR_FIDVID_CTL 0xc0010041
|
|
|
|
#define MSR_FIDVID_STATUS 0xc0010042
|
|
|
|
|
|
|
|
/* Field definitions within the FID VID Low Control MSR : */
|
|
|
|
#define MSR_C_LO_INIT_FID_VID 0x00010000
|
2005-07-28 09:40:04 -07:00
|
|
|
#define MSR_C_LO_NEW_VID 0x00003f00
|
|
|
|
#define MSR_C_LO_NEW_FID 0x0000003f
|
2005-04-16 15:20:36 -07:00
|
|
|
#define MSR_C_LO_VID_SHIFT 8
|
|
|
|
|
|
|
|
/* Field definitions within the FID VID High Control MSR : */
|
2006-02-27 22:43:23 -07:00
|
|
|
#define MSR_C_HI_STP_GNT_TO 0x000fffff
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Field definitions within the FID VID Low Status MSR : */
|
2005-07-28 09:40:04 -07:00
|
|
|
#define MSR_S_LO_CHANGE_PENDING 0x80000000 /* cleared when completed */
|
|
|
|
#define MSR_S_LO_MAX_RAMP_VID 0x3f000000
|
2005-04-16 15:20:36 -07:00
|
|
|
#define MSR_S_LO_MAX_FID 0x003f0000
|
|
|
|
#define MSR_S_LO_START_FID 0x00003f00
|
|
|
|
#define MSR_S_LO_CURRENT_FID 0x0000003f
|
|
|
|
|
|
|
|
/* Field definitions within the FID VID High Status MSR : */
|
2005-07-28 09:40:04 -07:00
|
|
|
#define MSR_S_HI_MIN_WORKING_VID 0x3f000000
|
|
|
|
#define MSR_S_HI_MAX_WORKING_VID 0x003f0000
|
|
|
|
#define MSR_S_HI_START_VID 0x00003f00
|
|
|
|
#define MSR_S_HI_CURRENT_VID 0x0000003f
|
|
|
|
#define MSR_C_HI_STP_GNT_BENIGN 0x00000001
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* There are restrictions frequencies have to follow:
|
|
|
|
* - only 1 entry in the low fid table ( <=1.4GHz )
|
|
|
|
* - lowest entry in the high fid table must be >= 2 * the entry in the
|
|
|
|
* low fid table
|
|
|
|
* - lowest entry in the high fid table must be a <= 200MHz + 2 * the entry
|
|
|
|
* in the low fid table
|
2005-11-29 13:18:03 -07:00
|
|
|
* - the parts can only step at <= 200 MHz intervals, odd fid values are
|
|
|
|
* supported in revision G and later revisions.
|
2005-04-16 15:20:36 -07:00
|
|
|
* - lowest frequency must be >= interprocessor hypertransport link speed
|
|
|
|
* (only applies to MP systems obviously)
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* fids (frequency identifiers) are arranged in 2 tables - lo and hi */
|
2005-11-29 13:18:03 -07:00
|
|
|
#define LO_FID_TABLE_TOP 7 /* fid values marking the boundary */
|
2005-04-16 15:20:36 -07:00
|
|
|
#define HI_FID_TABLE_BOTTOM 8 /* between the low and high tables */
|
|
|
|
|
|
|
|
#define LO_VCOFREQ_TABLE_TOP 1400 /* corresponding vco frequency values */
|
|
|
|
#define HI_VCOFREQ_TABLE_BOTTOM 1600
|
|
|
|
|
|
|
|
#define MIN_FREQ_RESOLUTION 200 /* fids jump by 2 matching freq jumps by 200 */
|
|
|
|
|
|
|
|
#define MAX_FID 0x2a /* Spec only gives FID values as far as 5 GHz */
|
2005-07-28 09:40:04 -07:00
|
|
|
#define LEAST_VID 0x3e /* Lowest (numerically highest) useful vid value */
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
#define MIN_FREQ 800 /* Min and max freqs, per spec */
|
|
|
|
#define MAX_FREQ 5000
|
|
|
|
|
2005-11-29 13:18:03 -07:00
|
|
|
#define INVALID_FID_MASK 0xffffffc0 /* not a valid fid if these bits are set */
|
2005-07-28 09:40:04 -07:00
|
|
|
#define INVALID_VID_MASK 0xffffffc0 /* not a valid vid if these bits are set */
|
|
|
|
|
|
|
|
#define VID_OFF 0x3f
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
#define STOP_GRANT_5NS 1 /* min poss memory access latency for voltage change */
|
|
|
|
|
|
|
|
#define PLL_LOCK_CONVERSION (1000/5) /* ms to ns, then divide by clock period */
|
|
|
|
|
|
|
|
#define MAXIMUM_VID_STEPS 1 /* Current cpus only allow a single step of 25mV */
|
2007-10-19 16:13:56 -07:00
|
|
|
#define VST_UNITS_20US 20 /* Voltage Stabilization Time is in units of 20us */
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/*
|
2007-10-19 16:13:56 -07:00
|
|
|
* Most values of interest are encoded in a single field of the _PSS
|
2005-04-16 15:20:36 -07:00
|
|
|
* entries: the "control" value.
|
|
|
|
*/
|
2006-02-27 22:43:23 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#define IRT_SHIFT 30
|
|
|
|
#define RVO_SHIFT 28
|
2005-07-29 09:56:41 -07:00
|
|
|
#define EXT_TYPE_SHIFT 27
|
2005-04-16 15:20:36 -07:00
|
|
|
#define PLL_L_SHIFT 20
|
|
|
|
#define MVS_SHIFT 18
|
|
|
|
#define VST_SHIFT 11
|
|
|
|
#define VID_SHIFT 6
|
|
|
|
#define IRT_MASK 3
|
|
|
|
#define RVO_MASK 3
|
2005-07-29 09:56:41 -07:00
|
|
|
#define EXT_TYPE_MASK 1
|
2005-04-16 15:20:36 -07:00
|
|
|
#define PLL_L_MASK 0x7f
|
|
|
|
#define MVS_MASK 3
|
|
|
|
#define VST_MASK 0x7f
|
|
|
|
#define VID_MASK 0x1f
|
2006-06-08 08:33:19 -07:00
|
|
|
#define FID_MASK 0x1f
|
|
|
|
#define EXT_VID_MASK 0x3f
|
|
|
|
#define EXT_FID_MASK 0x3f
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Version 1.4 of the PSB table. This table is constructed by BIOS and is
|
|
|
|
* to tell the OS's power management driver which VIDs and FIDs are
|
|
|
|
* supported by this particular processor.
|
|
|
|
* If the data in the PSB / PST is wrong, then this driver will program the
|
|
|
|
* wrong values into hardware, which is very likely to lead to a crash.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define PSB_ID_STRING "AMDK7PNOW!"
|
|
|
|
#define PSB_ID_STRING_LEN 10
|
|
|
|
|
|
|
|
#define PSB_VERSION_1_4 0x14
|
|
|
|
|
|
|
|
struct psb_s {
|
|
|
|
u8 signature[10];
|
|
|
|
u8 tableversion;
|
|
|
|
u8 flags1;
|
|
|
|
u16 vstable;
|
|
|
|
u8 flags2;
|
|
|
|
u8 num_tables;
|
|
|
|
u32 cpuid;
|
|
|
|
u8 plllocktime;
|
|
|
|
u8 maxfid;
|
|
|
|
u8 maxvid;
|
|
|
|
u8 numps;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Pairs of fid/vid values are appended to the version 1.4 PSB table. */
|
|
|
|
struct pst_s {
|
|
|
|
u8 fid;
|
|
|
|
u8 vid;
|
|
|
|
};
|
|
|
|
|
2009-07-26 08:55:25 -07:00
|
|
|
static int core_voltage_pre_transition(struct powernow_k8_data *data,
|
|
|
|
u32 reqvid, u32 regfid);
|
2005-04-16 15:20:36 -07:00
|
|
|
static int core_voltage_post_transition(struct powernow_k8_data *data, u32 reqvid);
|
|
|
|
static int core_frequency_transition(struct powernow_k8_data *data, u32 reqfid);
|
|
|
|
|
|
|
|
static void powernow_k8_acpi_pst_values(struct powernow_k8_data *data, unsigned int index);
|
2005-05-31 19:03:46 -07:00
|
|
|
|
2006-06-04 16:37:58 -07:00
|
|
|
static int fill_powernow_table_fidvid(struct powernow_k8_data *data, struct cpufreq_frequency_table *powernow_table);
|