Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add initial mx28evk support with duart and fec0.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add initial mx23evk support with duart.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Dynamically allocate fec devices for MX28, which gets dual
fec interface.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Dynamically allocate duart devices for MX23 and MX28.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Create static memory mapping for MX23 and MX28.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add clock for MXS-based SoCs, MX23 and MX28.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

MXS-based SoCs implements iomux functions in block PINCTRL.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

MXS-based SoCs implement gpio support in block PINCTRL.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

There are 2 versions of the timrot on Freescale MXS-based SoCs.
The v1 on MX23 only gets 16 bits counter, while v2 on MX28
extends the counter to 32 bits.

The implementation uses two timers, one for clock_event and
another for clocksource. MX28 uses timrot 0 and 1, while MX23
uses 0 and 2.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

 - DEBUG_LL support, which is incompatible with multi-soc MXS image
   because of different DUART base address on MX23 and MX28
 - uncompress message support
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add Interrupt Collector (ICOLL) support for MXS-based.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

 - The mxs wdog is implemented in RTC block.
 - There is a generic software reset routine for most modules on mxs.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add helper definition and function for MXS-based.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Add core definitions for MXS-based SoC MX23 and MX28.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>

Commit 0ea12930 ("arm: return both physical and virtual addresses
from addruart") took out the test for MMU on/off but didn't switch the
ldr instructions to no longer be conditionals based on said test.

Fix that.
Signed-off-by: NOlof Johansson <olof@lixom.net>
Acked-by: NColin Cross <ccross@android.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

gic_set_cpu will directly use irq_desc[]. If CONFIG_SPARSE_IRQ is
enabled, there is no irq_desc[]. So we need use irq_to_desc(irq) to
get the descriptor for irq.
Signed-off-by: NChao Xie <chao.xie@marvell.com>
Acked-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Include sched.h to ensure sched_clock() has the notrace
annotation, and mark any functions it calls as notrace
too.
Include sched.h to ensure sched_clock() has the notrace
annotation, and mark any functions it calls as notrace
too.
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The existing code invokes the syscall with rubbish in r7,
due to what looks like an incorrect literal load idiom.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

for the epson frambuffer support it's CONFIG_FB_S1D13XXX
not CONFIG_FB_S1D135XX
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

as based on http://www.picotux.com/pt200/picotux200.pdf
these board does not have such I/O
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

to be a few more concistant with the other boards

as ek is for evaluation kit and dk for development kit
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Convert the following AT91RM9200-based boards to the new-style UART
initialization:
  - Ajeco 1ARM Single Board Computer
  - Sperry-Sun KAFA board
  - picotux 200

Remove the deprecated at91_init_serial
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NAndrew Victor <linux@maxim.org.za>

Currently, the kprobes implementation for ARM only supports the ARM
instruction set, so it only works if CONFIG_THUMB2_KERNEL is not
enabled.

Until kprobes is updated to work with Thumb-2, turning it on will
cause horrible things to happen, so this patch disables it for now.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a
result, using these directives in code sections can result in
misaligned data words when building a Thumb-2 kernel
(CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to
assume that fundamental types of word size or above are word-
aligned when accessing them from C.  If the data is not really
word-aligned, this can cause impaired performance and stray
alignment faults in some circumstances.

In general, the following rules should be applied when using
data word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned data
words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume that
fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned, this
can cause impaired performance and stray alignment faults in some
circumstances.

In general, the following rules should be applied when using data word
declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The 32-bit conditional branches in Thumb-2 have a shorter range
(+/-512K) than their ARM counterparts (+/-32MB).  The linker does
not currently generate trampolines to extend the range of these
Thumb-2 conditional branches, resulting in link errors when vmlinux
is sufficiently large, e.g.:

head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19

This patch forces the longer-range, unconditional branch encoding
by use of an explicit IT instruction.  The resulting branches are
triggered on the same conditions as before.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The code which makes up the zImage header intends to leave a
32-byte gap followed by a branch to the real entry point, a magic
number, and a word containing the absolute entry point address.

This gets messed up with with CONFIG_THUMB2_KERNEL, because the
size of the initial padding NOPs changes.

Instead, the header can be made fully compatible by restoring it to
ARM.

In the Thumb-2 case, we can replace the initial NOPs with a
sequence which switches to Thumb and jumps to the real entry point.

As a consequence, the zImage entry point is now always ARM, so no
special magic is needed any more for the uImage rules in the
Thumb-2 case.
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some instruction operand combinations are used here which are nor
permitted in Thumb-2.

In particular, most uses of pc as an operand are disallowed in
Thumb-2, and deprecated in ARM from ARMv7 onwards.

The modified code introduced by this patch should be compatible
with all architecture versions >= v3, with or without
CONFIG_THUMB2_KERNEL.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

In this specific case, we can achieve the desired alignment by
forcing a 32-bit branch instruction using the W() macro, since the
assembler location counter is already 32-bit aligned in this case.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This change limits number of GIC-originating interrupts to the
platform maximum (defined by NR_IRQS) while still initialising
all distributor registers.
Signed-off-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

About all options present in each file are activated
in the single file.
Signed-off-by: NEric Benard <eric@eukrea.com>
Tested-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

commit 6338a6aa ("ARM: 6269/1: Add 'code'
parameter for hook_fault_code()") breaks CNS3xxx build:

  CC      arch/arm/mach-cns3xxx/pcie.o
pcie.c: In function 'cns3xxx_pcie_init':
pcie.c:373: warning: passing argument 4 of 'hook_fault_code' makes integer from pointer without a cast
pcie.c:373: error: too few arguments to function 'hook_fault_code'

This commit fixes the small issue.

Cc: stable@kernel.org [36]
Signed-off-by: NAnton Vorontsov <cbouatmailru@gmail.com>

This patch fixes following warning messages when CONFIG_PM selected.

In file included from arch/arm/mach-s5pv210/mach-smdkv210.c:34:
arch/arm/plat-samsung/include/plat/pm.h:104: warning: 'struct sys_device'
declared inside parameter list
arch/arm/plat-samsung/include/plat/pm.h:104: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/plat-samsung/include/plat/pm.h:105: warning: 'struct sys_device'
declared inside parameter list

In file included from arch/arm/mach-s5pv210/mach-smdkc110.c:31:
arch/arm/plat-samsung/include/plat/pm.h:104: warning: 'struct sys_device'
declared inside parameter list
arch/arm/plat-samsung/include/plat/pm.h:104: warning: its scope is only this
definition or declaration, which is probably not what you want
arch/arm/plat-samsung/include/plat/pm.h:105: warning: 'struct sys_device'
declared inside parameter list
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: NSangbeom Kim <sbkim73@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>