The system memory node for the OMAP2420 H4 was incorrectly defined as
start address followed by end address, instead of start address and
size. No noticable side-effects were observed but fix this for
correctness.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Instead of using cpu_is_omap..() macros in the device driver we
rely on information provided in the platform data.

The only information we need is whether the USB Host module has
a single ULPI bypass control bit for all ports or individual bypass
control bits for each port. OMAP3 REV2.1 and earlier have the former.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
[tony@atomide.com: updated to remove plat/cpu.h]
Signed-off-by: Tony Lindgren <tony@atomide.com>

The OMAP2420 H4 board was the only board using the
plat-omap/debug-devices.c code for configuring ethernet support. Now
that OMAP2420 H4 has been migrated to use the generic gpmc code for
configuring ethernet support, the debug-devices.c file is no longer
used and so remove it and its header file.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

Ethernet is not currently working on the OMAP2420 H4 board. In commit
f6049312 (ARM: OMAP: abstract debug card setup (smc, leds)) the function
h4_init_smc91x() that initialised the ethernet controller was renamed to
h4_init_debug() but was never called when initialising the board.

Adding a call to h4_init_debug() fixes ethernet support, however,
instead of using the legacy H4 code migrate the H4 to use the
gpmc_smc91x_init() function instead and remove the legacy H4 code.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4.
It is not correct for following platforms:
    2430 - gpio mux mode 3
    44xx - gpio mux mode 3
    54xx - gpio mux mode 6

Patch reserves first 3 bits in partition flags for storing gpio mux
mode in same format as stored in control pad register.
Modified OMAP_MODE_GPIO() macro to handle all possible cases of gpio mux mode.
Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4.

Signed-off-by: Oleg Matcovschi <oleg.matcovschi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined.  Before the patch, 0 was the
invalid value, but as 0 is a valid bus number, the patch changed this to
-1.

However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.

This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.

The bug exists in v3.5+ kernels.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Thomas Weber <thomas@tomweber.eu>
Cc: Thomas Weber <thomas@tomweber.eu>
Cc: <stable@vger.kernel.org> # v3.5+
Signed-off-by: Tony Lindgren <tony@atomide.com>

Sparse generates the following warnings when compiling mach-omap2/timer.c.

  CHECK   arch/arm/mach-omap2/timer.c
  arch/arm/mach-omap2/timer.c:193:13: warning: symbol 'omap_dmtimer_init'
  was not declared. Should it be static?
  arch/arm/mach-omap2/timer.c:213:12: warning: symbol
  'omap_dm_timer_get_errata' was not declared. Should it be static?

Add static to function declaration to fix warnings.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>

When compiling the kernel with configuration options ...

 # CONFIG_ARCH_OMAP2 is not set
 # CONFIG_ARCH_OMAP3 is not set
 # CONFIG_ARCH_OMAP4 is not set
 # CONFIG_SOC_OMAP5 is not set
 CONFIG_SOC_AM33XX=y

 ... the following build warning is seen.

  CC      arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:395:19: warning: ‘omap2_sync32k_clocksource_init’
  	defined but not used [-Wunused-function]

This issue was introduced by commit 6f80b3bb (ARM: OMAP2+: timer: remove
CONFIG_OMAP_32K_TIMER) where the omap2_sync32k_clocksource_init() is no
longer referenced by the timer initialisation function for the AM335x
device as it has no 32k-sync timer.

Fix this by adding the "__maybe_unused" compiler directive to the
omap2_sync32k_clocksource_init() function to indicate that this function
may be used for certain configurations.

Cc: Igor Grinberg <grinberg@compulab.co.il>

Signed-off-by: Jon Hunter <jon-hunter@ti.com>

In commit fa6d79d2 (ARM: OMAP: Add initialisation for the real-time
counter), the function realtime_counter_init() was added. However, if
the kernel configuration option CONFIG_SOC_OMAP5 is not selected then
the following compiler warning is observed.

  CC      arch/arm/mach-omap2/timer.o
  arch/arm/mach-omap2/timer.c:489:20: warning: ‘realtime_counter_init’
  defined but not used [-Wunused-function]

Commit fa6d79d2 also introduced the kernel configuration option
CONFIG_SOC_HAS_REALTIME_COUNTER. If this option is not selected then the
a stub function for realtime_counter_init() is defined.

For non-OMAP5 devices, there is no realtime counter and so
realtime_counter_init() function and stub function are not used for
these devices. Therefore, fix this warning by only allowing the kernel
configuration option CONFIG_SOC_HAS_REALTIME_COUNTER to be enabled for
OMAP5 devices.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>

Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by Santosh Shilimkar <santosh.shilimkar@ti.com>

Update the arm arch_get_unmapped_area[_topdown] functions to make use of
vm_unmapped_area() instead of implementing a brute force search.

[akpm@linux-foundation.org: remove now-unused COLOUR_ALIGN_DOWN()]
Signed-off-by: Michel Lespinasse <walken@google.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The REALVIEW EB board can host tiles with multiple cores thus needs
to be able to initialise SMP. There is, however, no .smp entry in
the MACHINE_START struct for REALVIEW_EB.

This patch adds the appropriate .smp entry to this struct.

Signed-off-by: Steve Capper <steve.capper@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The kernel can only be entered on HYP mode on CPUs which actually
support it, i.e.  >= ARMv7.  pre-v6 platform support cannot coexist
in the same kernel as support for v7 and higher, so there is no
advantage in having the HYP mode check on pre-v6 hardware.

At least one pre-v6 board is known to fail when the HYP mode check
code is present, although the exact cause remains unknown and may
be unrelated.  [1]

This patch restores the old behaviour for pre-v6 platforms, whereby
the CPSR is forced directly to SVC mode with IRQs and FIQs masked.
All kernels capable of booting on v7 hardware will retain the
check, so this should not impair functionality.

[1] http://lists.arm.linux.org.uk/lurker/message/20121130.013814.19218413.en.html


([ARM] head.S change broke platform device registration?)

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The offset must be multiplied by 4 to be sure to access the correct
32bit word in the stack scratch space.

For instance, a store at scratch memory cell #1 was generating the
following:

st	r4, [sp, #1]

While the correct code for this is:

st	r4, [sp, #4]

To reproduce the bug (assuming your system has a NIC with the mac
address 52:54:00:12:34:56):

echo 0 > /proc/sys/net/core/bpf_jit_enable
tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
	== -0x3AA" # this will capture packets as expected

echo 1 > /proc/sys/net/core/bpf_jit_enable
tcpdump -ni eth0 "ether[1] + ether[2] - ether[3] * ether[4] - ether[5] \
	== -0x3AA" # this will not.

This bug was present since the original inclusion of bpf_jit for ARM
(ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).

Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

syscall_trace_exit is currently doing things back-to-front; invoking
the audit hook *after* signalling the debugger, which presents an
opportunity for the registers to be re-written by userspace in order to
bypass auditing constaints.

This patch fixes the ordering by moving the audit code first and the
tracehook code last. On the face of it, it looks like
current_thread_info()->syscall may be incorrect for the sys_exit
tracepoint, but that's actually not an issue because it will have been
set during syscall entry and cannot have changed since then.

Reported-by: Andrew Gabbasov <Andrew_Gabbasov@mentor.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Official prototype for kzalloc is:

void *kzalloc(size_t, gfp_t);

The ARM bpf_jit code was having the assumption that it was:

void *kzalloc(gfp_t, size);

This was resulting the use of some random GFP flags depending on the
size requested and some random overflows once the really needed size
was more than the value of GFP_KERNEL.

This bug was present since the original inclusion of bpf_jit for ARM
(ddecdfce: ARM: 7259/3: net: JIT compiler for packet filters).

Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Commit b9a50f74 ("ARM: 7450/1: dcache: select DCACHE_WORD_ACCESS for
little-endian ARMv6+ CPUs") added support for word-at-time path
comparisons, relying on the ability to perform unaligned loads with
negligible performance impact in hardware.

For nommu configurations without MPU support, this is unpredictable and
so we should fall back to the byte-by-byte routines.

Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Recent ARMv7 toolchains assume that unaligned memory accesses will not
fault and will instead be handled by the processor.

For the nommu case (without an MPU), memory will be treated as
strongly-ordered and therefore unaligned accesses may fault regardless
of the SCTLR.A setting.

This patch passes -mno-unaligned-access to GCC when compiling for nommu
targets, preventing the generation of unaligned memory access in the
kernel.

Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This patch keeps disabled the strict alignment CP15 bit for
all armv6 and armv7 processor without the mmu. This behaviour
is now same as in the mmu case.

Signed-off-by: Armando Visconti <armando.visconti@st.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This is what is done for the regular interrupts in kernel/irqs/proc.c
already, before calling arch_show_interrupts().  Not doing so for the
IPIs causes the column headers not to match with the content whenever
some CPUs are offline.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

6e20a0a4
(gpio: pcf857x: enable gpio_to_irq() support)
added gpio_to_irq() support on pcf857x driver,
but it used pdata->irq.
This patch modifies driver to use client->irq instead of it.
It modifies kzm9g board platform settings,
and device probe information too.
This patch is tested on kzm9g board

Reported-by: Christian Engelmayer <christian.engelmayer@frequentis.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.

From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation):

The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.

There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
  capabilities register and
- MMC/SD clock coming out of controller > 25MHz

Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

The at91-mci driver is not needed anymore since the atmel-mci driver now
supports all Atmel devices.

Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

The current rules have the .dtb files build in a different directory
from the .dts files. The only reason for this is that it was what
PowerPC has done historically. This patch changes ARM to use the generic
dtb rule which builds .dtb files in the same directory as the source .dts.

Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: Olof Johansson <olof@lixom.net>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
[swarren: added rm command for old stale .dtb files]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>

Use the previously unused TPIDRPRW register to store percpu offsets.
TPIDRPRW is only accessible in PL1, so it can only be used in the kernel.

This replaces 2 loads with a mrc instruction for each percpu variable
access. With hackbench, the performance improvement is 1.4% on Cortex-A9
(highbank). Taking an average of 30 runs of "hackbench -l 1000" yields:

Before: 6.2191
After: 6.1348

Will Deacon reported similar delta on v6 with 11MPCore.

The asm "memory clobber" are needed here to ensure the percpu offset
gets reloaded. Testing by Will found that this would not happen in
__schedule() which is a bit of a special case as preemption is disabled
but the execution can move cores.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This passes the lm resource to register the AMBA devices on the
LM as contained within the LM resource.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This makes PINCTRL related config options visible.
Otherwise there is no way to build pinctrl drivers for MMP2, PXA168 and PXA910.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

  CC      arch/arm/mach-sunxi/sunxi.o
./arch/arm/mach-sunxi/sunxi.c: In function 'sunxi_restart':
./arch/arm/mach-sunxi/sunxi.c:55:3: error: implicit declaration of function 'mdelay' [-Werror=implicit-function-declaration]

Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>

Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.

Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.

So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.

The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.

Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.

Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.

Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.

Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.

[1] https://patchwork.kernel.org/patch/1519591/#



cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ERROR: "allnodes" [drivers/w1/masters/w1-gpio.ko] undefined!

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
[grant.likely: allnodes is too generic; rename to of_allnodes]
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Ville Syrjala <syrjala@sci.fi>

Fix 32 vs 32k typo:

arch/arm/mach-omap2/timer.c: In function 'omap4_local_timer_init':
arch/arm/mach-omap2/timer.c:633:2: error: implicit declaration of function 'omap4_sync32_timer_init' [-Werror=implicit-function-declaration]
arch/arm/mach-omap2/timer.c: At top level:
arch/arm/mach-omap2/timer.c:610:2: warning: 'omap4_sync32k_timer_init' defined but not used [-Wunused-function]

Also, mark the omap4_local_timer_init() stub as __init (and take off
the explicit inline and let the compiler do the work instead).

Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

The recent commit "ARM: EXYNOS: add support for EXYNOS5440 SoC" broke
support for exynos5250 because of_machine_is_compatible() was used too
early in the boot process.  It also probably meant that the exynos5440
failed to use the proper iotable.  Switch to use
of_flat_dt_is_compatible() in both of these cases.

The failure I was seeing in exynos5250 because of this was:
  Division by zero in kernel.
  [<80015ed4>] (unwind_backtrace+0x0/0xec) from [<8045c7a4>] (dump_stack+0x20/0x24)
  [<8045c7a4>] (dump_stack+0x20/0x24) from [<80012990>] (__div0+0x20/0x28)
  [<80012990>] (__div0+0x20/0x28) from [<8021ab04>] (Ldiv0_64+0x8/0x18)
  [<8021ab04>] (Ldiv0_64+0x8/0x18) from [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134)
  [<80068560>] (__clocksource_updatefreq_scale+0x54/0x134) from [<8006865c>] (__clocksource_register_scale+0x1c/0x54)
  [<8006865c>] (__clocksource_register_scale+0x1c/0x54) from [<80612a18>] (exynos_timer_init+0x100/0x1e8)
  [<80612a18>] (exynos_timer_init+0x100/0x1e8) from [<8060d184>] (time_init+0x28/0x38)
  [<8060d184>] (time_init+0x28/0x38) from [<8060a754>] (start_kernel+0x1e0/0x3c8)
  [<8060a754>] (start_kernel+0x1e0/0x3c8) from [<40008078>] (0x40008078)

Signed-off-by: Doug Anderson <dianders@chromium.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
[olofj: fixed two build errors, one missing include and one !CONFIG_OF failure]
Signed-off-by: Olof Johansson <olof@lixom.net>

The SP804 driver statically initialises the cpumask of the clock event
device to be cpu_all_mask, which is derived from the compile-time
constant NR_CPUS. This breaks SMP_ON_UP systems where the interrupt
controller handling the sp804 doesn't have the irq_set_affinity callback
on the irq_chip, because the common timer code fails to identify the
device as cpu-local and ends up treating it as a broadcast device
instead.

This patch fixes the problem by using cpu_possible_mask at runtime,
which will correctly represent the possible CPUs when SMP_ON_UP is being
used.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Add missing PL330 MDMA1 controller node to the device tree (DT).

[ Currently there is no problem with using 'non-secure' mdma1 address
  instead of 'secure' one on revision 0 of Exynos4210 SOC (as used by
  Universal C210 board) as this SOC revision is unsupported by DT. ]

Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Exynos4412 uses different information register for each core. This
patch adjusts the bring-up code to take that into account.

Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

Add support for using UART3 for DEBUG_LL on exynos.

[dianders: added depend on ARCH_EXYNOS.]

Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

The s3c-camif driver uses "camera" clock conn_id for the "camif-upll"
(s3c244x) and "camera" (s3c64xx) platform clock. By adding this new
clkdev entry the platform differences are isolated from the driver.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>

This patch adds default helper functions for the camera port
pin configuration. Whenever pinctrl support for s3c24xx/s3c64xx
SoCs is available these code should be removed and proper pinctrl
API should be used in the CAMIF driver.

Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>