diff options
author | Arnd Bergmann <arnd@arndb.de> | 2012-05-11 17:15:31 +0200 |
---|---|---|
committer | Arnd Bergmann <arnd@arndb.de> | 2012-05-11 17:15:31 +0200 |
commit | 93c6d8927fa692faef3d7d945bd4fe84b0185ad4 (patch) | |
tree | 0a971c86114656ec4e39f7789d9faeb70432c36a /arch/x86/kernel/cpu/amd.c | |
parent | ea01d31a07ae182028d2398380948f5a4ee09953 (diff) | |
parent | 50260924afd4b745bfb6e5f1caee381a1875fc31 (diff) |
Merge branch 'clk/mxs' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/clock
Shawn Guo <shawn.guo@linaro.org> writes:
mxs common clk porting for v3.5. It depends on the following two branches.
[1] git://git.linaro.org/people/mturquette/linux.git clk-next
[2] http://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/linux-arm.git clkdev
As the mxs device tree conversion will constantly touch clock files,
to save the conflicts, the updated mxs/dt branch coming later will
based on this pull-request.
* 'clk/mxs' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: mxs: remove now unused timer_clk argument from mxs_timer_init
ARM: mxs: remove old clock support
ARM: mxs: switch to common clk framework
ARM: mxs: change the lookup name for fec phy clock
ARM: mxs: request clock for timer
clk: mxs: add clock support for imx28
clk: mxs: add clock support for imx23
clk: mxs: add mxs specific clocks
Includes an update to Linux 3.4-rc6
Conflicts:
drivers/clk/Makefile
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Diffstat (limited to 'arch/x86/kernel/cpu/amd.c')
-rw-r--r-- | arch/x86/kernel/cpu/amd.c | 29 |
1 files changed, 24 insertions, 5 deletions
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c index 0a44b90602b..146bb6218ee 100644 --- a/arch/x86/kernel/cpu/amd.c +++ b/arch/x86/kernel/cpu/amd.c @@ -26,7 +26,8 @@ * contact AMD for precise details and a CPU swap. * * See http://www.multimania.com/poulot/k6bug.html - * http://www.amd.com/K6/k6docs/revgd.html + * and section 2.6.2 of "AMD-K6 Processor Revision Guide - Model 6" + * (Publication # 21266 Issue Date: August 1998) * * The following test is erm.. interesting. AMD neglected to up * the chip setting when fixing the bug but they also tweaked some @@ -94,7 +95,6 @@ static void __cpuinit init_amd_k6(struct cpuinfo_x86 *c) "system stability may be impaired when more than 32 MB are used.\n"); else printk(KERN_CONT "probably OK (after B9730xxxx).\n"); - printk(KERN_INFO "Please see http://membres.lycos.fr/poulot/k6bug.html\n"); } /* K6 with old style WHCR */ @@ -353,10 +353,11 @@ static void __cpuinit srat_detect_node(struct cpuinfo_x86 *c) node = per_cpu(cpu_llc_id, cpu); /* - * If core numbers are inconsistent, it's likely a multi-fabric platform, - * so invoke platform-specific handler + * On multi-fabric platform (e.g. Numascale NumaChip) a + * platform-specific handler needs to be called to fixup some + * IDs of the CPU. */ - if (c->phys_proc_id != node) + if (x86_cpuinit.fixup_cpu_id) x86_cpuinit.fixup_cpu_id(c, node); if (!node_online(node)) { @@ -579,6 +580,24 @@ static void __cpuinit init_amd(struct cpuinfo_x86 *c) } } + /* re-enable TopologyExtensions if switched off by BIOS */ + if ((c->x86 == 0x15) && + (c->x86_model >= 0x10) && (c->x86_model <= 0x1f) && + !cpu_has(c, X86_FEATURE_TOPOEXT)) { + u64 val; + + if (!rdmsrl_amd_safe(0xc0011005, &val)) { + val |= 1ULL << 54; + wrmsrl_amd_safe(0xc0011005, val); + rdmsrl(0xc0011005, val); + if (val & (1ULL << 54)) { + set_cpu_cap(c, X86_FEATURE_TOPOEXT); + printk(KERN_INFO FW_INFO "CPU: Re-enabling " + "disabled Topology Extensions Support\n"); + } + } + } + cpu_detect_cache_sizes(c); /* Multi core CPU? */ |