Introduce basic support for the Freescale P1022DS reference board, based on the
Freescale BSP for this board.  This patch excludes the DIU, SSI, and MMC/SD
drivers.  Only a 36-bit DTS is provided.

Update mpc86xx_smp_defconfig and mpc85xx_defconfig to support the P1022DS.
This means enabling 64-bit physical address support, increasing the maximum
zone order to 12 (to allow the DIU driver to allocate large chunks), and
clean up the audio options to disable the deprecated OSS support.

Signed-off-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

This version uses "fsl,mpc8555..." instead of "fsl,85..." notation.

There is also an 8541 version of this board so DTS for this board
is specific to the 8555 processor.

Another patch is coming to fix-up other DTS that use old notation.

Signed-off-by: Bradley Hughes <bhughes@silicontkx.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The "fsl,85..." style compatible binding was to be deprecated
some time ago.  This patch corrects existing occurrences of
the incorrect binding.  The memory-controller and
l2-cache-controller are the only affected nodes.

Signed-off-by: Bradley Hughes <bhughes@silicontkx.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

By default ti1520 bridge expects an input clock on CLOCK pin (to control
power chip). However on this boards CLOCK should be generated by PCI1520
itself. Add a quirk that enables internal 16 KHz clock generation on
this pin.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Update PCI IRQ mapping on TQM85xx platforms: include INTC and INTD on PCI-X
slot and add INTA/INTB mapping for PCMCIA bridge.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

This patch adds support for MPC8308RDB development board from
Freescale.
Supported devices:
 DUART
 Dual Ethernet
 NOR and NAND flashes
 I2C
 USB in peripheral mode

PCIE support is broken by the commit 3da34aae ("powerpc/fsl: Support
unique MSI addresses per PCIe Root Complex"). Works after revert.

Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

This patch adds the quirk for PCIE controller found on Freescale MPC8308.
The quirk is the same as for other MPC83xx processors.

Signed-off-by: Ilya Yanok <yanok@emcraft.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The mpc85xx_mds_setup_arch() function is incomprehensible
and unmaintainable. Factor out all QE specific stuff into
mpc85xx_mds_qe_init() and mpc85xx_mds_reset_ucc_phys().

Also move QE stuff out of mpc85xx_mds_pic_init().

The diff is unreadable, but only because the code was so. ;-)
It should be better now, and less indented.

Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

P1021 processors have no dedicated ROM to store the QE microcode,
so the fimrware is stored externally, and it is U-Boot responsibility
to load it. It might be that the board is booting without QE, e.g.
currently U-Boot doesn't support QE for P1021MDS boards, which means
that QE isn't initialized, and so the board hangs early at boot.

This patch fixes the issue by marking QE as disabled and checking the
state in the probing code. U-Boot should fixup the state if it
initialized the QE.

Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

The code inside '#ifdef CONFIG_QUICC_ENGINE' makes the
mpc85xx_mds_setup_arch() return early if no QE nodes present,
and so SWIOTLB is never initialized.

This patch fixes the issue by moving SWIOTLB code above
QE.

Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

Adds support for kexec on 85xx machines for the BookE platform.
Including support for SMP machines

Based off work from Maxim Uvarov <muvarov@mvista.com>
Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>

When CPU hotplug is used, some CPUs may be offline at the time a kexec is
performed.  The subsequent kernel may expect these CPUs to be already running,
and will declare them stuck.  On pseries, there's also a soft-offline (cede)
state that CPUs may be in; this can also cause problems as the kexeced kernel
may ask RTAS if they're online -- and RTAS would say they are.  The CPU will
either appear stuck, or will cause a crash as we replace its cede loop beneath
it.

This patch kicks each present offline CPU awake before the kexec, so that
none are forever lost to these assumptions in the subsequent kernel.

Now, the behaviour is that all available CPUs that were offlined are now
online & usable after the kexec.  This mimics the behaviour of a full reboot
(on which all CPUs will be restarted).

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Tidies some typos, KERN_INFO-ise an info msg, and add a debug msg showing
when the final sequence starts.

Also adds a comment to kexec_prepare_cpus_wait() to make note of a possible
problem; the need for kexec to deal with CPUs that failed to originally start
up.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Currently we look pretty stupid when printing out a bunch of things in
prom_init.c.  eg.

  Max number of cores passed to firmware: 0x0000000000000080

So I've change this to print in decimal:

  Max number of cores passed to firmware: 128 (NR_CPUS = 256)

This required adding a prom_print_dec() function and changing some
prom_printk() calls from %x to %lu.

Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

If a CPU remove is attempted using the 'release' interface on hardware
which supports extended cede, the CPU will be put in the INACTIVE state
rather than the OFFLINE state due to the default preferred_offline_state
in that situation.  In the INACTIVE state it will fail to be removed.

This patch changes the preferred offline state to OFFLINE when an CPU is
in the ONLINE state.  After cpu_down() is called in dlpar_offline_cpu()
the CPU will be OFFLINE and CPU removal can continue.

Signed-off-by: Robert Jennings <rcj@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

This adds support for the Mac Mini's that were quietly rolled out
in 2005. Work still needs to be done to support suspend and
WakeOnLan.

Signed-off-by: Mark Crichton <crichton@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

In testing SMT disable, we have been regularly seeing the following
message:

Querying DEAD? cpu %i (%i) shows %i

This indicates the current delay in pseries_cpu_die where we wait
for the specified CPU to die, is insufficient. Usually, this does
not cause a problem, but we've seen this result in BUG_ON's going
off in the timer code when we try to migrate the timers off the
dead cpu while a timer is still running. Increasing this delay,
as is done in this patch, seems to resolve this issue.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

We already defined start_cpu_decrementer() to invoke decrementer for AP as
the following path:

start_secondary() -> secondary_cpu_time_init() -> start_cpu_decrementer()

So remove these incorrect codes introduced from commit:
e7f75ad0 powerpc/47x: Base ppc476 support

And actually we really should not enable decrementer before calling set_dec().

Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

On PowerPC we should always use generic ISA DMA API implementation
as there is simply no other implementation exist.

Without this patch, the following build error pops up:

  sound/built-in.o: In function 'snd_dma_pointer':
  (.text+0x74ae): undefined reference to 'dma_spin_lock'
  ...
  make: *** [.tmp_vmlinux1] Error 1

This is PPC_85xx, SMP and some sound drivers set to =y.

Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Acked-by: Dave Liu <daveliu@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

While testing cpu offlining, we are regularly seeing the WARN_ON go off
in xics_ipi_dispatch. It can occur when an IPI gets sent to the CPU while
it is going offline. There is already a similar WARN_ON in the handlers
for PPC_MSG_CALL_FUNCTION and PPC_MSG_CALL_FUNC_SINGLE, so the warning
is not needed in that path. The debugger handler handles this case by
simply ignoring IPIs for offline CPUs, so no warning is needed there.
And the reschedule IPI, which is what is occurring in our test environment,
can be safely ignored, so we can simply remove the WARN_ON from xics_ipi_dispatch.

Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: Neil Horman <nhorman@tuxdriver.com>

 machine_kexec.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)
Reviewed-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Fix sizes of variables so correct values are exported via /proc.
Cast variable in comparison to avoid compiler error.

Signed-off-by: Matthew McClintock <msm@freescale.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

With dynamic PACAs, the kexecing CPU's PACA won't lie within the kernel
static data and there is a chance that something may stomp it when preparing
to kexec.  This patch switches this final CPU to a static PACA just before
we pull the switch.

Signed-off-by: Matt Evans <matt@ozlabs.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The recent AMCC 405EX Rev D without Security uses a PVR value
that matches the old 405EXr Rev A/B with Security.
The 405EX Rev D without Security would be shown
incorrectly as an 405EXr. The pvr_mask of 0xffff0004
is no longer sufficient to distinguish the 405EX from 405EXr.

This patch replaces 2 entries in the cpu_specs table
and adds 8 more, each using pvr_mask of 0xffff000f
and appropriate pvr_value to distinguish the AMCC
PowerPC 405EX and 405EXr instances.
The cpu_name for these entries now includes the
Rev, in similar fashion to the 440GX.

Signed-off-by: Lee Nipper <lee.nipper@gmail.com>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

UART2 and UART3 on 460EX/GT have incorrect interrupt mappings right now.
UART2 should be 28 (0x1c) and UART3 29 (0x1d). This patch fixes this and
switches to using decimal number instead of hex, since the AppliedMicro
(AMCC) users manuals describe their inerrupt numbers in decimal.

Thanks to Fabien Proriol for pointing this out.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Fabien Proriol <Fabien.Proriol@jdsu.com>
Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

The config options for REDWOOD_[456] were commented out in the powerpc
Kconfig. The ifdefs referencing this options therefore are dead and all
references to this can be removed (Also dependencies in other KConfig
files).

Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>

They will fail to build due to the lack of mtmsrd, and wouldn't
be useful anyways

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Use the MMU config registers to scan for available direct and
indirect page sizes and print out the result. Will be needed
for future hugetlbfs implementation.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

We patch the TLB miss exception vectors to point to alternate
functions when using HW page table on BookE.

However, we were patching in a new branch in the first instruction
of the exception handler instead of the second one, thus overriding
the nop that is in the first instruction.

This cause problems when single stepping as we rely on that nop for
the single step to stop properly within the exception vector range
rather than on the target of the branch.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

We use a similar technique to ppc32: We set a thread local flag
to indicate that we are about to enter or have entered the stop
state, and have fixup code in the async interrupt entry code that
reacts to this flag to make us return to a different location
(sets NIP to LINK in our case).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
--
v2. Fix lockdep bug
    Re-mask interrupts when coming back from idle

If we are soft disabled and receive a doorbell exception we don't process
it immediately. This means we need to check on the way out of irq restore
if there are any doorbell exceptions to process.

The problem is at that point we don't know what our regs are, and that
in turn makes xmon unhappy. To workaround the problem, instead of checking
for and processing doorbells, we check for any doorbells and if there were
any we send ourselves another.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

include/asm-generic/irq_regs.h declares per-cpu irq_regs variables and
get_irq_regs() and set_irq_regs() helper functions to maintain them.
These can be used to access the proper pt_regs structure related to the
current interrupt entry (if any).

In the powerpc arch code, this is used to maintain irq regs on
decrementer and external interrupt exceptions.  However, for the
doorbell exceptions used by the msgsnd/msgrcv IPI mechanism of newer
BookE CPUs, the irq_regs are not kept up to date.

In particular this means that xmon will not work properly on SMP,
because the secondary xmon instances started by IPI will blow up when
they cannot retrieve the irq regs.

This patch fixes the problem by adding calls to maintain the irq regs
across doorbell exceptions.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Note that critical doorbells are an unimplemented stub just like
other critical or machine check handlers, since we haven't done
support for "levelled" exceptions yet.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The decrementer on BookE acts as a level interrupt and doesn't
need to be re-triggered when going negative. It doesn't go
negative anyways (unless programmed to auto-reload with a
negative value) as it stops when reaching 0.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

The doorbells use the content of the PIR register to match messages
from other CPUs. This may or may not be the same as our linux CPU
number, so using that as the "target" is no right.

Instead, we sample the PIR register at boot on every processor
and use that value subsequently when sending IPIs.

We also use a per-cpu message mask rather than a global array which
should limit cache line contention.

Note: We could use the CPU number in the device-tree instead of
the PIR register, as they are supposed to be equivalent. This
might prove useful if doorbells are to be used to kick CPUs out
of FW at boot time, thus before we can sample the PIR. This is
however not the case now and using the PIR just works.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

... where it belongs

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Our handling of debug interrupts on Book3E 64-bit is not quite
the way it should be just yet. This is a workaround to let gdb
work at least for now. We ensure that when context switching,
we set the appropriate DBCR0 value for the new task. We also
make sure that we turn off MSR[DE] within the kernel, and set
it as part of the bits that get set when going back to userspace.

In the long run, we will probably set the userspace DBCR0 on the
exception exit code path and ensure we have some proper kernel
value to set on the way into the kernel, a bit like ppc32 does,
but that will take more work.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>