aboutsummaryrefslogtreecommitdiff
path: root/arch/sparc64/kernel/cpu.c
AgeCommit message (Collapse)Author
2008-02-28[SPARC]: Mark linux_sparc_{fpu,chips} static.David S. Miller
Caught by sparse. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-08[SPARC64]: Do not assume sun4v chips have load-twin/store-init support.David S. Miller
Check the cpu type in the OBP device tree before committing to using the optimized Niagara memcpy and memset implementation. If we don't recognize the cpu type, use a completely generic version. Signed-off-by: David S. Miller <davem@davemloft.net>
2007-08-07[SPARC64]: Fix hard-coding of cpu type output in /proc/cpuinfo on sun4v.David S. Miller
Signed-off-by: David S. Miller <davem@davemloft.net>
2006-06-30Remove obsolete #include <linux/config.h>Jörn Engel
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-20[SPARC64]: kernel/cpu.c needs asm/spitfire.hDavid S. Miller
For 'tlb_type'. Signed-off-by: David S. Miller <davem@davemloft.net>
2006-03-20[SPARC64]: Detect sun4v early in boot process.David S. Miller
We look for "SUNW,sun4v" in the 'compatible' property of the root OBP device tree node. Protect every %ver register access, to make sure it is not touched on sun4v, as %ver is hyperprivileged there. Lock kernel TLB entries using hypervisor calls instead of calls into OBP. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-11-09[SPARC64]: Use ARRAY_SIZE macroTobias Klauser
Use ARRAY_SIZE macro instead of sizeof(x)/sizeof(x[0]) and remove a duplicate of ARRAY_SIZE which is never used anyways. Signed-off-by: Tobias Klauser <tklauser@nuerscht.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-27[SPARC64]: Add missing IDs for newer cpus.David S. Miller
Also, the us3_cpufreq driver can work on Ultra-IV and IV+. They use the SAFARI bus register to control the clock divider just like Ultra-III and III+ do. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!