We currently have a few variants of fsl-booke processors (e500v1, e500v2,
e500mc, and e200).  They all have minor differences that we had previously
been handling via ifdefs.

To move towards having this support the following changes have been made:

* PID1, PID2 only exist on e500v1 & e500v2 and should not be accessed on
  e500mc or e200.  We use MMUCFG[NPIDS] to determine which case we are
  since we only touch PID1/2 in extremely early init code.

* Not all IVORs exist on all the processors so introduce cpu_setup
  functions for each variant to setup the proper IVORs that are either
  unique or exist but have some variations between the processors
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

We're soon running out of CPU features and I need to add some new
ones for various MMU related bits, so this patch separates the MMU
features from the CPU features.  I moved over the 32-bit MMU related
ones, added base features for MMU type families, but didn't move
over any 64-bit only feature yet.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This adds supports to the "extended" DCR addressing via the indirect
mfdcrx/mtdcrx instructions supported by some 4xx cores (440H6 and
later).

I enabled the feature for now only on AMCC 460 chips.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.

Without this, all machine checks become fatal due to loss
of context when entering the exception handler.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This adds the AMCC PowerPC 405EZ chip to the cputable
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

The file arch/powerpc/kernel/sysfs.c is currently only compiled for
64-bit kernels.  It contain code to register CPU sysdevs in sysfs and
add various properties such as cache topology and raw access by root
to performance monitor counters (PMCs).  A lot of that can be re-used
as is on 32-bits.

This makes the file be built for both, with appropriate ifdef'ing
for the few bits that are really 64-bit specific, and adds some
support for the raw PMCs for 75x and 74xx processors.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Commit 9115d134 ("powerpc: Enable
AT_BASE_PLATFORM aux vector") broke boot on 32-bit powerpc systems; we
have to use PTRRELOC to initialize powerpc_base_platform this early in
boot.

Bug reported by Jon Smirl.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Stash the first platform string matched by identify_cpu() in
powerpc_base_platform, and supply that to the ELF loader for the value
of AT_BASE_PLATFORM.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

While running on a system with new hardware and a kernel where the
cpu_specs[] table does not recognize the new hardware, the identify_cpu()
routine will select the default case as it searches through cpu_specs[]
in an attempt to match the real PVR. Once the default case is selected,
non of the oprofile counters and/or fields have been set up or defined.

When identify_cpu() is called once more with the logical PVR, some of
the cpu specific fields are replaced with the exception of the oprofile
related ones. However, in the case where we have actually taken the
default case while searching for the real PVR, we need to tell
oprofile that we are now running in compatibility mode so it can pick up
the correct counters. We do this by setting the oprofile_cpu_type field
to be that taken from the cpu_specs[] for the cpu we are now emulating.

This change will detect that we are now altering the real PVR and determine
if we also need to update the oprofile_cpu_type field.
Signed-off-by: NTorez Smith <lnxtorez@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Background from Maynard Johnson:
As of POWER6, a set of 32 common events is defined that must be
supported on all future POWER processors.  The main impetus for this
compat set is the need to support partition migration, especially from
processor P(n) to processor P(n+1), where performance software that's
running in the new partition may not be knowledgeable about processor
P(n+1).  If a performance tool determines it does not support the
physical processor, but is told (via the
PPC_FEATURE_PSERIES_PERFMON_COMPAT bit) that the processor supports
the notion of the PMU compat set, then the performance tool can
surface just those events to the user of the tool.

PPC_FEATURE_PSERIES_PERFMON_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: NNathan Lynch <ntl@pobox.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Updates the cputable to include the 440 processor found in the
Xilinx Virtex5 FXT FPGA.
Signed-off-by: NJohn Linn <john.linn@xilinx.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The logic to patch CPU feature sections lives in cputable.c, but these days
it's used for CPU features as well as firmware features.  Move it into
it's own file for neatness and as preparation for some additions.

While we're moving the code, we pull the loop body logic into a separate
routine, and remove a comment which doesn't apply anymore.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

A bunch of code has hard-coded the value for a "nop" instruction, it
would be nice to have a #define for it.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Add an entry for Power7 architected mode and add "(raw)" to Power7 raw
mode to distinguish it more clearly.
Signed-off-by: NJoel Schopp <jschopp@austin.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Add a cputable entry for the POWER7 processor.

Also tell firmware that we know about POWER7.
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NJoel Schopp <jschopp@austin.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The e500 core enter DOZE/NAP power-saving modes when the core go to
cpu_idle routine.

The power management default running mode is DOZE, If the user

echo 1 > /proc/sys/kernel/powersave-nap

the system will change to NAP running mode.
Signed-off-by: NDave Liu <daveliu@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

The new e500mc core from Freescale is based on the e500v2 but with the
following changes:

* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
* Cache line size is now 64-bytes (e500v1/v2 have a 32-byte cache line)
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This reverts commit acb0142b.

AMCC has indicated that the PPC 460GT does have FPU support.  This
revert enables the FPU for those chips again.
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Commit 76bc080e ("POWERPC] Make default
cputable entries reflect selected CPU family") added default entries
for the e200 and e500 families, but missed a closing brace on those
entries, as pointed out by David Gibson.  This adds the closing braces.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Changes the cputable so that various CPU families that have an exclusive
CONFIG_ option have a more sensible default entry to use if the specific
processor hasn't been identified.

This makes the kernel more generally useful when booted on an unknown
PVR for things like new 4xx variants.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The AMCC 460GT doesn't have an FPU so let's not enable support for it.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This patch adds basic support for the AMCC 460EX/460GT PPC's to arch/powerpc.
Currently those PPC's are still based on a 440 core and *not* a 460 core.

Here some basic features of those SoC's:

460EX:
- Up to 1.2GHz, 32kB L1 I-cache and D-cache, 256kB L2-cache, FPU
- 1 * PCI (max 66MHz), 2 * PCIe (one 4-lane, one 1-lane)
- 2 * GBit Ethernet with TCP/IP acceleration
- USB 2.0 Host/Device OTG and Host interface
- SATA controller
- Optional security feature

460GT (only changes to 460EX):
- 4 * GBit Ethernet with TCP/IP acceleration
- RapidIO
- No SATA
- No USB
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

The e300 c3 and c4 variants support hardware performance monitor counters
which are identical to those found in the e500.
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Some of the more recent e300 cores have the same performance monitor
implementation as the e500.  e300 isn't book-e, so the name isn't
really appropriate.  In preparation for e300 support, rename a bunch
of fsl_booke things to say fsl_emb (Freescale Embedded Performance Monitors).
Signed-off-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This adds the 440EP revision C PVR to the CPU table.  The chip has an
FPU on it, so we also match the logical PVR
Signed-off-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This patch adds the 405EXr to the powerpc cuptable. Basically the 405EXr
is a 405EX with only one EMAC and only one PCIe interface.
Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

The e200 and e500 platforms are separated in various parts of the kernel with
ifdefs, most notably reg_booke.h and traps.c.  The new machine_check rework
requires them to be similarly separated in cputable.c to avoid compile errors.
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Correct the PowerPC 440GRx machine check callback.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This adds a cputable function pointer for the CPU-side machine
check handling. The semantic is still the same as the old one,
the one in ppc_md. overrides the one in cputable, though
ultimately we'll want to change that so the CPU gets first.

This removes CONFIG_440A which was a problem for multiplatform
kernels and instead fixes up the IVOR at runtime from a setup_cpu
function. The "A" version of the machine check also tweaks the
regs->trap value to differenciate the 2 versions at the C level.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Signed-off-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

PowerPC 440EP(x) 440GR(x) processors have the same PVR values, since
they have identical cores. However, FPU is not supported on GR(x) and
enabling APU instruction broadcast in the CCR0 register (to enable FPU)
may cause unpredictable results. There's no safe way to detect FPU
support at runtime. This patch provides a workarund for the issue.

We use a POWER6 "logical PVR approach". First, we identify all EP(x)
and GR(x) processors as GR(x) ones (which is safe). Then we check
the device tree cpu path. If we have a EP(x) processor entry,
we call identify_cpu again with PVR | 0x8. This bit is always 0
in the real PVR. This way we enable FPU only for 440EP(x).
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Signed-off-by: NStefan Roese <sr@denx.de>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Some IBM machines supply a "logical" PVR (processor version register)
value in the device tree in the cpu nodes rather than the real PVR.
This is used for instance to indicate that the processors in a POWER6
partition have been configured by the hypervisor to run in POWER5+
mode rather than POWER6 mode.  To cope with this, we call identify_cpu
a second time with the logical PVR value (the first call is with the
real PVR value in the very early setup code).

However, POWER5+ machines can also supply a logical PVR value, and use
the same value (the value that indicates a v2.04 architecture
compliant processor).  This causes problems for code that uses the
performance monitor (such as oprofile), because the PMU registers are
different in POWER6 (even in POWER5+ mode) from the real POWER5+.

This change works around this problem by taking out the PMU
information from the cputable entries for the logical PVR values, and
changing identify_cpu so that the second call to it won't overwrite
the PMU information that was established by the first call (the one
with the real PVR), but does update the other fields.  Specifically,
if the cputable entry for the logical PVR value has num_pmcs == 0,
none of the PMU-related fields get used.

So that we can create a mixed cputable entry, we now make cur_cpu_spec
point to a single static struct cpu_spec, and copy stuff from
cpu_specs[i] into it.  This has the side-effect that we can now make
cpu_specs[] be initdata.

Ultimately it would be good to move the PMU-related fields out to a
separate structure, pointed to by the cputable entries, and change
identify_cpu so that it saves the PMU info pointer, copies the whole
structure, and restores the PMU info pointer, rather than identify_cpu
having to list all the fields that are *not* PMU-related.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add a workaround for PowerPC 440EPx/GRx incorrect write to
DDR SDRAM errata. Data can be written to wrong address
in SDRAM when write pipelining enabled on plb0. We disable
it in the cpu_setup for these processors at early init.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

The PowerPC 440EP(x) FPU init is currently done in head_44x
under ifdefs. Since we should support more then one board
in the same kernel, we move FPU initialization code from head_44x
to cpu_setup_44x and add cpu_setup callbacks for 440EP(x).
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This adds cpu_setup functionality for ppc44x platform.
Low level cpu-spefic initialization routines should be
placed in cpu_setup_44x.S and a callback should be
added to cputable. The cpu_setup is invoked
by identify_cpu() function at early init.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

Make it so that SPE support can be determined at runtime.  This is similiar
to how we handle AltiVec.  This allows us to have SPE support built in and
work on processors with and without SPE.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

AMCC PPC440EPx Sequoia board support.
Signed-off-by: NValentine Barshak <vbarshak@ru.mvista.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>

This adds a new oprofile cpu type for Power 5 revision 3 chips.
The new name is ppc64/power5++ and is used so that the performance
counters can be set up correctly.
Signed-off-by: NMike Wolf <mjw@us.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

When adding the cputable entry for 440SPe Rev. B, we also need to
adjust the existing entries for 440SP Rev. A and 440SPe Rev. B so that
they look more bits of the PVR.  The 440SPe Rev. B has PVR 53421891,
which would match the current 440SP Rev. A pattern of 53xxx891.  To
distinguish between 440SP and 440SPe, we need to use the first three
digits of the PVR, which are respectively 532 and 534.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>