Marvell MMP2 (aka ARMADA610) is a SoC based on PJ4 core. It's
ARMv6 compatible.  Support basic interrupt handler and timer,
and basic support for MMP2 based FLINT platform.
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NGavin Gu <gavin.gu@marvell.com>
Signed-off-by: NJing Xiang <jxiang@marvell.com>
Signed-off-by: NJack Ren <jack.ren@marvell.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NGavin Gu <gavin.gu@marvell.com>
Signed-off-by: NJing Xiang <jxiang@marvell.com>
Signed-off-by: NJack Ren <jack.ren@marvell.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Also remove a trailing whitespace while being there.
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Add some safety check for CONFIG_PM around zeus_power_off(). Without
it linking can fail like this:

arch/arm/mach-pxa/built-in.o: In function `zeus_power_off':
e800.c:(.text+0x2bc8): undefined reference to `pxa27x_cpu_suspend'
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Acked-by: NMarc Zyngier <maz@misterjones.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

This function gets only called from scoop_suspend() and scoop_resume() which are
only built in if we have CONFIG_PM set. Make it the same for check_scoop_reg().

This fixes the following warning:
arch/arm/common/scoop.c:143: warning: ‘check_scoop_reg’ defined but not used
Signed-off-by: NStefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEdwin Peer <epeer@tmtservices.co.za>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

IRQ_LOCOMO_* are never used elsewhere, remove these definitions. As well
as the cascade of these IRQs. IRQ_LOCOMO_*_BASE changed to IRQ_LOCOMO_*.

IRQ_LOCOMO_LT and IRQ_LOCOMO_SPI are likely to be used in a same way as
IRQ_LOCOMO_KEY.

IRQ_LOCOMO_GPIO and the demultiplex handler should really be living
somewhere else.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

It is not necessary and is over-complicated for IRQ_LOCOMO_KEY to
be a cascaded IRQ of IRQ_LOCOMO_KEY_BASE. Removed and introduced
locomokbd_{open,close} for masking/unmasking of the keyboard IRQ.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

These IRQ definitions related to LOCOMO are never referenced anywhere,
thus could be safely removed.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Cc: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Missing AC97 pin configurations are added where pxa_set_ac97_info() are
called for all pxa25x/pxa27x platforms. Where no exact configuration is
provided, use the default as in sound/arm/pxa2xx-ac97-lib.c

Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

This is really pxa27x specific and should be kept in pxa27x.c. With this
newly introduced function, the original set_resetgpio_mode() is deprecated.

Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

There are only limited possible LCD pin configurations for pxa25x
platforms, simplify this by macro.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

* Modification of Kconfig to add the Option
* 1 new file : buffalo-wxl-setup.c
This file is inspired from the db-78xx0-setup.c already present.
The following is done:
  - Configure MPP Lines for the plateform (see my patch for MPP)
This is taken from the stock kernel provided by buffalotech (the vendor)
  - GigaBit Ethernet
  - Sata
  - Uart are initiallized in a different way than on the dev board as we
have one core only.
  - USB

The kernel has been running for some days now on my plateform.
Signed-off-by: NSebastien Requiem <sebastien@kolios.dk>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

This patch is composed of two new files :

- mpp.c which is mainly inspired by the same file as in mach-kirkwood

- mpp.h that is written from the documentation provided by Marvell
http://www.marvell.com/products/processors/embedded/discovery_innovation/HW_MV78100_OpenSource.pdf

Moreover, due to some implementation problem, I have
defined some MPPX_UNUSED that offer developers the possibility
to SET MPP to some unused value (such as for Buffalo WXL).

Note: This patch doesn't support MV78200 yet (only 78100 MPP lines have
been written)
Signed-off-by: NSebastien Requiem <sebastien@kolios.dk>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

Accept SD CD and SD WP in accordance to
http://plugcomputer.org/data/docs/Sheeva-PowerPlug-V1.3-GTI-090906.pdf
on MPP 47 and 44 respectively on the eSATA SheevaPlug
Signed-off-by: NJohn Holland <john.holland@cellent-fs.de>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
--

Enable the kirkwood SATA SoC interface on the eSATA SheevaPlug.
Signed-off-by: NJohn Holland <john.holland@cellent-fs.de>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
--

Allow basic eSATA SheevaPlug board configuration and build.
Signed-off-by: NJohn Holland <john.holland@cellent-fs.de>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
--

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch fix the below build error for arm1026ej-s processor (IntegratorCP/arm1026ej-s board).
  CC      init/main.o
In file included from include/linux/highmem.h:8,
                 from include/linux/pagemap.h:10,
                 from include/linux/mempolicy.h:62,
                 from init/main.c:52:
arch/arm/include/asm/cacheflush.h:134:2: error: #error Unknown cache maintainence model
make[1]: *** [init/main.o] Erreur 1
make: *** [init] Erreur 2
Signed-off-by: NAbdoulaye Walsimou Gaye <walsimou@walsimou.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It appears the wrong GPIO registers were used
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NPaulius Zaleckas <paulius.zaleckas@gmail.com>

The 'outer_cache' variable is needed by the outer_inv_range(),
outer_clean_range() and outer_flush_range() functions, which are
declared as inline in asm/cacheflush.h.  Otherwise drivers built
as a loadable module, which access these functions, will have
an undefined symbol.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We broke "acpi=ht" in 2.6.32 by disabling MADT parsing
for acpi=disabled.  e5b8fc6a
This also broke systems which invoked acpi=ht via DMI blacklist.

acpi=ht is a really ugly hack,
but restore it for those that still use it.

http://bugzilla.kernel.org/show_bug.cgi?id=14886Signed-off-by: NLen Brown <len.brown@intel.com>

The 64-bit version of ELF_PLAT_INIT() clears TIF_IA32, but at this point
it has already been cleared by SET_PERSONALITY == set_personality_64bit.
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

05d43ed8 "x86: get rid of the insane TIF_ABI_PENDING bit" forgot about
force_personality32.  Fix.
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We realized when we broke acpi=ht
http://bugzilla.kernel.org/show_bug.cgi?id=14886
that acpi=ht is not needed on this box
and folks have been using acpi=force on it anyway.
Signed-off-by: NLen Brown <len.brown@intel.com>

This follows the parisc change to ensure that tracehook_signal_handler()
is aware of when we are single-stepping in order to ptrace_notify()
appropriately. While this was implemented for 32-bit SH, sh64 neglected
to make use of TIF_SINGLESTEP when it was folded in with the 32-bit code,
resulting in ptrace_notify() never being called.

As sh64 uses all of the other abstractions already, this simply plugs in
the thread flag in the appropriate enable/disable paths and fixes up the
tracehook notification accordingly. With this in place, sh64 is brought
in line with what 32-bit is already doing.
Reported-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Recent U-Boot commit 5ccd29c3679b3669b0bde5c501c1aa0f325a7acb caused
the "cpu-release-addr" device tree property to contain the physical RAM
location that secondary cores were spinning at.  Previously, the
"cpu-release-addr" property contained a value referencing the boot page
translation address range of 0xfffffxxx, which then indirectly accessed
RAM.

The "cpu-release-addr" is currently ioremapped and the secondary cores
kicked.  However, due to the recent change in "cpu-release-addr", it
sometimes points to a memory location in low memory that cannot be
ioremapped.  For example on a P2020-based board with 512MB of RAM the
following error occurs on bootup:

  <...>
  mpic: requesting IPIs ...
  __ioremap(): phys addr 0x1ffff000 is RAM lr c05df9a0
  Unable to handle kernel paging request for data at address 0x00000014
  Faulting instruction address: 0xc05df9b0
  Oops: Kernel access of bad area, sig: 11 [#1]
  SMP NR_CPUS=2 P2020 RDB
  Modules linked in:
  <... eventual kernel panic>

Adding logic to conditionally ioremap or access memory directly resolves
the issue.
Signed-off-by: NPeter Tyser <ptyser@xes-inc.com>
Signed-off-by: NNate Case <ncase@xes-inc.com>
Reported-by: NDipen Dudhat <B09055@freescale.com>
Tested-by: NDipen Dudhat <B09055@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

MPC85xx chips report the wrong value in feature reporting register,
and that causes the following oops:

 Unable to handle kernel paging request for data at address 0x00000c00
 Faulting instruction address: 0xc0019294
 Oops: Kernel access of bad area, sig: 11 [#1]
 MPC8569 MDS
 Modules linked in:
 [...]
 NIP [c0019294] mpic_set_irq_type+0x2f0/0x368
 LR [c0019124] mpic_set_irq_type+0x180/0x368
 Call Trace:
 [ef851d60] [c0019124] mpic_set_irq_type+0x180/0x368 (unreliable)
 [ef851d90] [c007958c] __irq_set_trigger+0x44/0xd4
 [ef851db0] [c007b550] set_irq_type+0x40/0x7c
 [ef851dc0] [c0004a60] irq_create_of_mapping+0xb4/0x114
 [ef851df0] [c0004af0] irq_of_parse_and_map+0x30/0x40
 [ef851e20] [c0405678] fsl_of_msi_probe+0x1a0/0x328
 [ef851e60] [c02e6438] of_platform_device_probe+0x5c/0x84
 [...]

This is because mpic_alloc() assigns wrong values to
mpic->isu_{size,shift,mask}, and things eventually break when
_mpic_irq_read() is trying to use them.

This patch fixes the issue by enabling MPIC_BROKEN_FRR_NIRQS quirk.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Mike Frysinger pointed out that calling tracehook_signal_handler with
stepping=0 missed testing the thread flags, resulting in not calling
ptrace_notify. Fix this by testing if we're single stepping or branch
stepping and setting the flag accordingly.

Tested, seems to work.
Reported-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>