1
Commit Graph

8 Commits

Author SHA1 Message Date
David Gibson
a2c70211fa [POWERPC] Compile fixes for arch/powerpc dcr code
The new dcr code does not currently compile when configured for native
DCR access on ARCH=powerpc.  This patch fixes the problems.

Signed-off-by: David Gibson <dwg@au1.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-07 14:03:23 +11:00
Kumar Gala
45d8e7aaf4 [POWERPC] Only export __mtdcr/__mfdcr if CONFIG_PPC_DCR is set
On 85xx we don't build in dcr support because the core doesn't implement the
instructions.  This caused problems when building an 85xx kernel.  Additionally
made it so we only build __mtdcr/__mfdcr if we are CONFIG_PPC_DCR_NATIVE.

The 85xx build issue wasPointed out by Dai Haruki.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
2006-12-10 23:15:47 -06:00
Josh Boyer
7da8a2e5c1 [POWERPC] 40x: Fix debug status register defines
This fixes some debug register defines on PPC 40x that were incorrect.

Signed-off-by: Josh Boyer <jdub@us.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-21 22:59:39 +10:00
Eugene Surovegin
30aacebed0 [PATCH] ppc32: add 440GX erratum 440_43 workaround
This patch adds workaround for PPC 440GX erratum 440_43. According to
this erratum spurious MachineChecks (caused by L1 cache parity) can
happen during DataTLB miss processing. We disable L1 cache parity
checking for 440GX rev.C and rev.F

Signed-off-by: Eugene Surovegin <ebs@ebshome.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-28 21:04:56 +10:00
Kumar Gala
33d9e9b56d [PATCH] ppc32: Add support for Freescale e200 (Book-E) core
The e200 core is a Book-E core (similar to e500) that has a unified L1 cache
and is not cache coherent on the bus.  The e200 core also adds a separate
exception level for debug exceptions.  Part of this patch helps to cleanup a
few cases that are true for all Freescale Book-E parts, not just e500.

Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 16:24:26 -07:00
Paul Mackerras
443a848cd3 [PATCH] ppc32: refactor FPU exception handling
Moved common FPU exception handling code out of head.S so it can be used by
several of the sub-architectures that might of a full PowerPC FPU.

Also, uses new CONFIG_PPC_FPU define to fix alignment exception handling
for floating point load/store instructions to only occur if we have a
hardware FPU.

Signed-off-by: Jason McMullan <jason.mcmullan@timesys.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-01 08:58:40 -07:00
Kumar Gala
f50b153b19 [PATCH] ppc32: Support 36-bit physical addressing on e500
To add support for 36-bit physical addressing on e500 the following changes
have been made.  The changes are generalized to support any physical address
size larger than 32-bits:

* Allow FSL Book-E parts to use a 64-bit PTE, it is 44-bits of pfn, 20-bits
  of flags.

* Introduced new CPU feature (CPU_FTR_BIG_PHYS) to allow runtime handling of
  updating hardware register (SPRN_MAS7) which holds the upper 32-bits of
  physical address that will be written into the TLB.  This is useful since
  not all e500 cores support 36-bit physical addressing.

* Currently have a pass through implementation of fixup_bigphys_addr

* Moved _PAGE_DIRTY in the 64-bit PTE case to free room for three additional
  storage attributes that may exist in future FSL Book-E cores and updated
  fault handler to copy these bits into the hardware TLBs.

Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16 15:24:22 -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