This addresses a section mismatch problem in the IM-PD1
driver in the Integrator/AP.

The IM-PD1 contains a VIC interrupt controller and therefore
the driver calls vic_init_cascaded() which is marked __init as
irqchips are simply not hot-pluggable and specifically the VIC
is assumed to initiate only on boot.

However the module driver model of the Integrator LM bus
assumes that logic tile drivers can be probed at runtime. This
is not really the case for IM-PD1: these tiles are detected at
boot and they cannot be plugged into a running system. Before
this patch it is of course possible to modprobe them later.

By first forcing the IM-PD1 to bool we make sure this driver
gets compiled into the kernel, and we know it will be probed
only at boot time when the tiles are detected, so we can tag
its probe function __init_refok as we know it won't be called
after boot now, and the section mismatch problem goes away.

As a side effect, sysfs binding from userspace becomes
impossible, so we tag the driver to suppress the bind/unbind
sysfs attributes.

Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The OpenBlocks AX3-4 has a non-DT bootloader.  It also comes with 1GB of
soldered on RAM, and a DIMM slot for expansion.

Unfortunately, atags_to_fdt() doesn't work in big-endian mode, so we see
the following failure when attempting to boot a big-endian kernel:

  686 slab pages
  17 pages shared
  0 pages swap cached
  [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
  Kernel panic - not syncing: Out of memory and no killable processes...

  CPU: 1 PID: 351 Comm: kworker/u4:0 Not tainted 3.15.0-rc8-next-20140603 #1
  [<c0215a54>] (unwind_backtrace) from [<c021160c>] (show_stack+0x10/0x14)
  [<c021160c>] (show_stack) from [<c0802500>] (dump_stack+0x78/0x94)
  [<c0802500>] (dump_stack) from [<c0800068>] (panic+0x90/0x21c)
  [<c0800068>] (panic) from [<c02b5704>] (out_of_memory+0x320/0x340)
  [<c02b5704>] (out_of_memory) from [<c02b93a0>] (__alloc_pages_nodemask+0x874/0x930)
  [<c02b93a0>] (__alloc_pages_nodemask) from [<c02d446c>] (handle_mm_fault+0x744/0x96c)
  [<c02d446c>] (handle_mm_fault) from [<c02cf250>] (__get_user_pages+0xd0/0x4c0)
  [<c02cf250>] (__get_user_pages) from [<c02f3598>] (get_arg_page+0x54/0xbc)
  [<c02f3598>] (get_arg_page) from [<c02f3878>] (copy_strings+0x278/0x29c)
  [<c02f3878>] (copy_strings) from [<c02f38bc>] (copy_strings_kernel+0x20/0x28)
  [<c02f38bc>] (copy_strings_kernel) from [<c02f4f1c>] (do_execve+0x3a8/0x4c8)
  [<c02f4f1c>] (do_execve) from [<c025ac10>] (____call_usermodehelper+0x15c/0x194)
  [<c025ac10>] (____call_usermodehelper) from [<c020e9b8>] (ret_from_fork+0x14/0x3c)
  CPU0: stopping
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.15.0-rc8-next-20140603 #1
  [<c0215a54>] (unwind_backtrace) from [<c021160c>] (show_stack+0x10/0x14)
  [<c021160c>] (show_stack) from [<c0802500>] (dump_stack+0x78/0x94)
  [<c0802500>] (dump_stack) from [<c021429c>] (handle_IPI+0x138/0x174)
  [<c021429c>] (handle_IPI) from [<c02087f0>] (armada_370_xp_handle_irq+0xb0/0xcc)
  [<c02087f0>] (armada_370_xp_handle_irq) from [<c0212100>] (__irq_svc+0x40/0x50)
  Exception stack(0xc0b6bf68 to 0xc0b6bfb0)
  bf60:                   e9fad598 00000000 00f509a3 00000000 c0b6a000 c0b724c4
  bf80: c0b72458 c0b6a000 00000000 00000000 c0b66da0 c0b6a000 00000000 c0b6bfb0
  bfa0: c027bb94 c027bb24 60000313 ffffffff
  [<c0212100>] (__irq_svc) from [<c027bb24>] (cpu_startup_entry+0x54/0x214)
  [<c027bb24>] (cpu_startup_entry) from [<c0ac5b30>] (start_kernel+0x318/0x37c)
  [<c0ac5b30>] (start_kernel) from [<00208078>] (0x208078)
  ---[ end Kernel panic - not syncing: Out of memory and no killable processes...

A similar failure will also occur if ARM_ATAG_DTB_COMPAT isn't selected.

Fix this by setting a sane default (1 GB) in the dts file.
Signed-off-by: NJason Cooper <jason@lakedaemon.net>
Tested-by: NKevin Hilman <khilman@linaro.org>
Cc: <stable@vger.kernel.org> #v3.13+
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

The only remaining driver using the samsung dmadev code is the broken
samsung-ac97 sound driver. However, as found by Russell's autobuilder,
the elaborate dependency chains around it cause problems with
circular dependencies.

This is an attempt to simplify those dependencies by making the
SAMSUNG_DMADEV option user-selectable. I also try to keep the
default settings for all related options unchanged, so we don't
introduce any regressions against earlier testing on linux-next.

In particular, all s3c64xx and s5p* platforms keep selecting the
pl330 and pl08x drivers they require, but the select statement
is now moved towards the main platform option, and it remains
optional by unselecting CONFIG_DMADEVICES.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>

The dynamic relocation that the keystone platform performs
only works if we can pick the phys offset at boot time. It's
possible that there is another solution for this, but this
is the easiest workaround. Kernels with ARM_PATCH_PHYS_VIRT
are not portable across platforms, and I see no reason why
anyone would run a kernel without ARM_PATCH_PHYS_VIRT on
keystone.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Commit d941f86f ("ARM: l2c: AM43x: add L2 cache support") enabled
the L2 cache support for the am43xx SoC, but caused a build regression
when the driver for that cache controller is disabled:

arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early':
:(.init.text+0xb20): undefined reference to `omap_l2_cache_init'

This did not happen for OMAP4, which has the same call, but enables
the l2x0 driver unconditionally. We could do the same thing for
am43xx, but it seems better to allow turning it off and make the
code work in either case.

This adds an inline wrapper for omap_l2_cache_init for the disabled
case, and removes the 'select' from OMAP4 so it becomes a user
visible option.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NTony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org

Patch to prevent warning of a buggy compiler when using clang and
the ARM_UNWIND option.

Clang defines (at least on the current trunk) GNUC, GNUC_MINOR, and
GNUC_PATCHLEVEL to 4, 2, and 1 respectively.

This version of GCC gets flagged as buggy, but it isn't actually an
issue with clang so the patch will do what it did before unless clang
is defined and then it will not report the GCC version as an issue.
Signed-off-by: NMark Charlebois <charlebm@gmail.com>
Signed-off-by: NBehan Webster <behanw@converseincode.com>

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). "static inline" is the correct choice
instead.

Author: Behan Webster <behanw@converseincode.com>
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>

This typedef is unnecessary and should just be removed.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

sam9x5 SoCs have the following errata:
 "RTC: Interrupt Mask Register cannot be used
  Interrupt Mask Register read always returns 0."

Hence we should not rely on what IMR claims about already masked IRQs
and just disable all IRQs.
Signed-off-by: NBoris BREZILLON <boris.brezillon@free-electrons.com>
Reported-by: NBryan Evenson <bevenson@melinkcorp.com>
Reviewed-by: NJohan Hovold <johan@hovold.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Cc: Bryan Evenson <bevenson@melinkcorp.com>
Cc: Andrew Victor <linux@maxim.org.za>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Mark Roszko <mark.roszko@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Russell King points out that my ARM merge (commit eb3d3ec5) was
broken wrt the arch/arm/mach-mvebu/board-v7.c file, leaving in a stale
l2x0_of_init() call (it's now handled by the DT description).

Which is kind of embarrassing, since I knew about it as it wasn't the
only file that had similar merge issues.  At least I got the other ones
right.
Reported-by: NRussell King <rmk@arm.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Laura's series removed the meminfo structure and its no longer available.
Update keystone code to remove the usage of it.
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Currently hugepage migration is available for all archs which support
pmd-level hugepage, but testing is done only for x86_64 and there're
bugs for other archs.  So to avoid breaking such archs, this patch
limits the availability strictly to x86_64 until developers of other
archs get interested in enabling this feature.

Simply disabling hugepage migration on non-x86_64 archs is not enough to
fix the reported problem where sys_move_pages() hits the BUG_ON() in
follow_page(FOLL_GET), so let's fix this by checking if hugepage
migration is supported in vma_migratable().
Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: NMichael Ellerman <mpe@ellerman.id.au>
Tested-by: NMichael Ellerman <mpe@ellerman.id.au>
Acked-by: NHugh Dickins <hughd@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Miller <davem@davemloft.net>
Cc: <stable@vger.kernel.org>	[3.12+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The prototype for mvebu_mbus_dt_init() changed around the same time
as a new caller was added to orion5x. This adds the missing argument
to make orion5x behave correctly.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Adds HDMI audio sDMA properties.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Adds HDMI audio sDMA properties.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Add the necessary DTS nodes to enable the micro-HDMI output on Parlor
board.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Alto35 expansion board has a ZIF connector for a 3.5'' LCD.
Add a common include file for this configuration, and use it
on Alto35.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Chestnut43, Gallop43 and Palo43 expansion boards have a ZIF connector
for a 4.3'' LCD. Add a common include file for this configuration, and
use it on relevant expansion boards.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Summit and Tobi expansion boards have a HDMI connector with a TFP410
encoder. Add a common include file for this configuration, and then
use it for Summit and Tobi.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.

This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it.

The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch add support for lcd display on gta04 board. Display control
is connected to spi (used spi bitbang driver).
Signed-off-by: NMarek Belisko <marek@goldelico.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

omap5-uevm has a single HDMI output. Add the necessary display
information, including pinmuxing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Add OMAP5 DSS nodes to omap5.dtsi.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Add DT data for am43x-epos-evm's LCD panel.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Add DT data for am437x-gp-evm's LCD panel.
Signed-off-by: NSathya Prakash M R <sathyap@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

Add DT data for the display subsystem for AM4372. The DSS on AM4372 is
basically OMAP3's DSS, without DSI and VENC blocks.
Signed-off-by: NSathya Prakash M R <sathyap@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>

This does the same as the previous commit, but for the S bit, which also
needs to match the initial value which the assembly code used for the
same reasons.  Again, we add a check for SMP to ensure that the page
tables are correctly setup for SMP.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove the option to provide DMA configuration as platform data,
enforce it through DT.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Roland Stigge <stigge@antcom.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Fix a long standing bug where, for ARMv6+, we don't fully ensure that
the C code sets the same cache policy as the assembly code.  This was
introduced partially by commit 11179d8c ([ARM] 4497/1: Only allow
safe cache configurations on ARMv6 and later) and also by adding SMP
support.

This patch sets the default cache policy based on the flags used by the
assembly code, and then ensures that when a cache policy command line
argument is used, we verify that on ARMv6, it matches the initial setup.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We can use the alignment_trap assembly macro here too.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

cr_no_alignment is really only used by the alignment code.  Since we no
longer change the setting of cr_alignment after boot, we can localise
this to alignment.c
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

alignment.c will not be built unless CPU_CP15 is set:

config CPU_CP15
        bool

config CPU_CP15_MMU
        bool
        select CPU_CP15

config ALIGNMENT_TRAP
        bool
        depends on CPU_CP15_MMU

So there's no point having conditionals on CPU_CP15 within this code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

adjust_cr() is not used anymore, so let's get rid of it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Keep all bits of alignment handling together.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Several places open-code this manipulation, let's consolidate this.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

memblock is now fully integrated into the kernel and is the prefered
method for tracking memory. Rather than reinvent the wheel with
meminfo, migrate to using memblock directly instead of meminfo as
an intermediate.
Acked-by: NJason Cooper <jason@lakedaemon.net>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKukjin Kim <kgene.kim@samsung.com>
Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Due to a design incompatibility between the PCIe Marvell controller
and the Cortex-A9, stressing PCIe devices with a lot of traffic
quickly causes a deadlock.

One part of the workaround for this is to have all PCIe regions mapped
as strongly-ordered (MT_UNCACHED) instead of the default
MT_DEVICE. While the arch_ioremap_caller() mechanism allows
sub-architecture code to override ioremap(), used to map PCIe memory
regions, there isn't such a mechanism to override the behavior of
pci_ioremap_io().

This commit adds the arch_pci_ioremap_mem_type variable, initialized
to MT_DEVICE by default, and that sub-architecture code can
override. We have chosen to expose a single variable rather than
offering the possibility of overriding the entire pci_ioremap_io(),
because implementing pci_ioremap_io() requires calling functions
(get_mem_type()) that are private to the arch/arm/mm/ code.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This was caught by a panic on Broadcom mobile platforms.

Note that this code is all going away with the pending l2x0 cleanup
series from Russell, but we need this here until that's landed so we
can enable exynos multiplatform.
Signed-off-by: NOlof Johansson <olof@lixom.net>

This fixes the following build errors:

/tmp/ccRbZlaA.s: Assembler messages:
/tmp/ccRbZlaA.s:69: Error: selected processor does not support ARM mode `isb '
/tmp/ccRbZlaA.s:75: Error: selected processor does not support ARM mode `isb '
/tmp/ccRbZlaA.s:76: Error: selected processor does not support ARM mode `dsb '
make[1]: *** [arch/arm/mach-exynos/hotplug.o] Error 1

/tmp/ccJEg4jw.s: Assembler messages:
/tmp/ccJEg4jw.s:454: Error: selected processor does not support ARM mode `isb'
/tmp/ccJEg4jw.s:455: Error: selected processor does not support ARM mode `dsb'
/tmp/ccJEg4jw.s:465: Error: selected processor does not support ARM mode `isb'
/tmp/ccJEg4jw.s:474: Error: selected processor does not support ARM mode `isb'
/tmp/ccJEg4jw.s:475: Error: selected processor does not support ARM mode `dsb'
/tmp/ccJEg4jw.s:516: Error: selected processor does not support ARM mode `isb'
/tmp/ccJEg4jw.s:525: Error: selected processor does not support ARM mode `isb'
/tmp/ccJEg4jw.s:526: Error: selected processor does not support ARM mode `dsb'
make[1]: *** [arch/arm/mach-exynos/mcpm-exynos.o] Error 1
Reported-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NAbhilash Kesavan <a.kesavan@samsung.com>
Tested-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>