Commit graph

61 commits

Author SHA1 Message Date
Atsushi Nemoto 460c0422c3 [MIPS] Fix sparse warnings about too big constants.
Fix following warnings:
linux/arch/mips/kernel/setup.c:249:12: warning: constant 0xffffffff00000000 is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:209:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:227:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:283:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:299:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
    
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-06-06 00:15:19 +01:00
Ralf Baechle f088fc84f9 [MIPS] FPU affinity for MT ASE.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-04-19 04:14:28 +02:00
Dave Hansen 22a9835c35 [PATCH] unify PFN_* macros
Just about every architecture defines some macros to do operations on pfns.
 They're all virtually identical.  This patch consolidates all of them.

One minor glitch is that at least i386 uses them in a very skeletal header
file.  To keep away from #include dependency hell, I stuck the new
definitions in a new, isolated header.

Of all of the implementations, sh64 is the only one that varied by a bit.
It used some masks to ensure that any sign-extension got ripped away before
the arithmetic is done.  This has been posted to that sh64 maintainers and
the development list.

Compiles on x86, x86_64, ia64 and ppc64.

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27 08:44:48 -08:00
Ralf Baechle 8145095cd8 [MIPS] Remove CONFIG_BUILD_ELF64.
This option is no longer usable with supported compilers.  It will be
replaced by usage of -msym32 in a separate patch.
    
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-03-21 13:27:46 +00:00
Ralf Baechle 9b6695a8ad [MIPS] SMP: Fix initialization order bug.
A recent change requires cpu_possible_map to be initialized before
smp_sched_init() but most MIPS platforms were initializing their
processors in the prom_prepare_cpus callback of smp_prepare_cpus.  The
simple fix of calling prom_prepare_cpus from one of the earlier SMP
initialization hooks doesn't work well either since IPIs may require
init_IRQ() to have completed, so bit the bullet and split
prom_prepare_cpus into two initialization functions, plat_smp_setup
which is called early from setup_arch and plat_prepare_cpus called where
prom_prepare_cpus used to be called.
    
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2006-02-27 17:30:36 +00:00
Ralf Baechle ec74e361f1 Mark a few variables __read_mostly.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-10-29 19:31:46 +01:00
Ralf Baechle e50c0a8fa6 Support the MIPS32 / MIPS64 DSP ASE.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-10-29 19:31:17 +01:00
Ralf Baechle c83cfc9c94 Get rid of early_init. There's more need to make this form of
initialization actually useful and as is certainly unmergable with
upstream.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2005-10-29 19:30:18 +01:00
Ralf Baechle 875d43e72b [PATCH] mips: clean up 32/64-bit configuration
Start cleaning 32-bit vs. 64-bit configuration.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-09-05 00:06:06 -07:00
Yoichi Yuasa b4819b5937 [PATCH] mips: add MIPS-specific support for flatmem/discontigmem
2.6.12-git6 doesn't boot on some MIPS machines.  They need the support of flat
memory and discontig memory.

Signed-off-by: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 16:24:25 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
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!
2005-04-16 15:20:36 -07:00