Use the hexadecimal values for the triggers to match what is done for the device
tree. This also fixes compilation issues as the defines have been moved
elsewhere.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Due a copy/paste error, the 'reg' values for the third PCIe interface
on Armada 380, and the third and fourth PCIe interfaces on Armada 385
are wrong: they are equal to the one of the second PCIe interface.

This patch fixes this by using the appropriate 'reg' values for those
PCIe interfaces.

Without this fix, the third and fourth PCIe interfaces are unusable on
those platforms.
Reported-by: NNadav Haklai <nadavh@marvell.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1400597008-4148-1-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: 0d3d96ab ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs")
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

If we fail to allocate struct platform_device pdev we
dereference it after the goto label err.

This bug was found using coccinelle.

Fixes: afa77ef3 (ARM: mx3: dynamically allocate "ipu-core" devices)
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.

Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d65 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.

Fixes: cb7094e8 (cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag)
Fixes: ff999b8a (cpuidle: OMAP4: remove timer broadcast initialization)
Cc: stable@vger.kernel.org # v3.9+
Cc: Roger Quadros <rogerq@ti.com>
Cc: Kevin Hilman <khilman@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Reported-tested-by: NRoger Quadros <rogerq@ti.com>
Reported-tested-by: NKevin Hilman <khilman@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma)
added support for handling interrupts in the omap dmaengine driver
instead of the legacy driver. Because of different handling for
interrupts this however caused omap3 to hang eventually after hitting
off-idle.

Any of the virtual 32 DMA channels can be assigned to any of the
four DMA interrupts. So commit 6ddeb6d8 made the omap dmaengine
driver to use the second DMA interrupt while keeping the legacy code
still using the first DMA interrupt.

This means we need to save and restore both IRQENABLE_L1 in addition
to IRQENABLE_L0. As there is a chance that the DSP might be using
IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until
this has been confirmed. Let's just add a comment to the code for
now.

Fixes: 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma)
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit c66d0391 broke NAND for non-DT boot on all OMAP2 and OMAP3
boards using board_nand_init(). Following error is seen at boot

[    0.154998]  (null): Unsupported NAND ECC scheme selected

For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data
must be set to OMAP_ECC_HAM1_CODE_HW to work properly.

Tested on omap3-beagle c4.

Fixes: c66d0391 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes)
Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.
Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>

G2D power domain also controls the CMU block of G2D. Since
clock registers can be accessed anytime for viewing
clk_summary, it can cause a system crash if g2d power domain
is disabled.
Signed-off-by: NArun Kumar K <arun.kk@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

MAU powerdomain provides clocks for Audio sub-system block.
This block comprises of the I2S audio controller, audio DMA
blocks and Audio sub-system clock registers.

Right now, there is no way to hook up power-domains with
clock providers.  During late boot when this power-domain
gets disabled, we get following external abort.

Unhandled fault: imprecise external abort (0x1406) at 0x00000000
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Tested-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

High speed I2C is used on Exynos5 based SoCs. Enable it.

The MMC partition for Root filesystem cannot be mounted
without this enabling HS-I2C and regulators on many boards
are connected HS-I2C bus so the regulators don't come by
default without this.

Actually, we are not able to get arndale-octa board to boot
and mount an MMC partition without this change.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Tested-by: NJavi Merino <javi.merino@arm.com>
[kgene.kim@samsung.com: modified description]
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This change places MDMA1 in disabled node for Exynos5420.
If MDMA1 region is configured with secure mode, it makes
the boot failure with the following on smdk5420 board.
("Unhandled fault: imprecise external abort (0x1406) at 0x00000000")
Thus, arndale-octa board don't need to do the same thing anymore.
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Tested-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

This patch fixes the offset of CPU boot address and changes
the parameter of smc call for SMC_CMD_CPU1BOOT command on
exynos4212.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <stable@kernel.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

Since the mvebu-soc-id code in mach-mvebu/ was introduced, several
users have noticed a regression: the PCIe card connected in the first
PCIe interface is not detected properly.

This is due to the fact that the mvebu-soc-id code enables the PCIe
clock of the first PCIe interface, reads the SoC device ID and
revision number (yes this information is made available as part of
PCIe registers), and then disables the clock. However, by doing this,
we gate the clock and therefore loose the complex PCIe configuration
that was done by the bootloader.

Unfortunately, as of today, the kernel is not capable of doing this
complex configuration by itself, so we really need to keep the PCIe
clock enabled. However, we don't want to keep it enabled
unconditionally: if the PCIe interface is not enabled or PCI support
is not compiled into the kernel, there is no reason to keep the PCIe
clock running.

This issue was discussed with Kevin Hilman, and the suggested solution
was to make the mvebu-soc-id code keep the clock enabled in case it
will be needed for PCIe. This is therefore the solution implemented in
this patch.

Long term, we hope to make the kernel more capable in terms of PCIe
configuration for this platform, which will anyway be needed to
support the compilation of the PCIe host controller driver as a
module. In the mean time however, we don't have much other choice than
to implement the currently proposed solution.
Reported-by: NNeil Greatorex <neil@fatboyfat.co.uk>
Cc: Neil Greatorex <neil@fatboyfat.co.uk>
Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Kevin Hilman <khilman@linaro.org>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399903900-29977-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: af8d1c63 ("ARM: mvebu: Add support to get the ID and the revision of a SoC")
Cc: <stable@vger.kernel.org> # 3.14+: 42a18d1c: ARM: mvebu: mvebu-soc-id: add missing clk_put() call
Cc: <stable@vger.kernel.org> # 3.14+
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The mvebu-soc-id code in mach-mvebu/ needs to enable a clock to read
the SoC device ID and revision number. To do so, it does a clk_get(),
then a clk_prepare_enable(), reads the value, and disables the clock
with clk_disable_unprepare(). However, it forgets to clk_put() the
clock. This commit fixes this issue.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1399903900-29977-2-git-send-email-thomas.petazzoni@free-electrons.com
Cc: <stable@vger.kernel.org> # 3.14+
Fixes: af8d1c63 ("ARM: mvebu: Add support to get the ID and the revision of a SoC")
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The external trigger value is 0b1101 which is 13 but 0xd.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The IPU register space is 128MB, not 2GB.

Fixes: abed9a6b 'ARM i.MX53: Add IPU support'
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NShawn Guo <shawn.guo@freescale.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 54397d85
 ("ARM: kirkwood: Relocate PCIe device tree nodes")

moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.

As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.
Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Fixes: 54397d85 ("ARM: kirkwood: Relocate PCIe device tree nodes")
Cc: <stable@vger.kernel.org> # v3.12+
Acked-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

Since the support of the GMAC has been merged, we're using it as the ethernet
controller on the A20 devices.

However, sunxi_defconfig wasn't selecting it hence breaking the NFS boot.
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

This is another great example of trainwreck engineering:

commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
added support for using EDMA on peripherals which have no direct EDMA
event mapping.

The code compiles and does not explode in your face, but that's it.

1) Reading an u16 array from an u32 device tree array simply does not
   work. Even if the function is named "edma_of_read_u32_to_s16_array".

   It merily calls of_property_read_u16_array. So the resulting 16bit
   array will have every other entry = 0.

2) The DT entry for the xbar registers related to xbar has length 0x10
   instead of the real length: 0xfd0 - 0xf90 = 0x40.

   Not a real problem as it does not cross a page boundary, but
   wrong nevertheless.

3) But none of this matters as the mapping never happens:

   After reading nonsense edma_of_read_u32_to_s16_array() invalidates
   the first array entry pair, so nobody can ever notice the
   braindamage by immediate explosion.

Seems the QA criteria for this code was solely not to explode when
someone adds edma-xbar-event-map entries to the DT. Goal achieved,
congratulations!

Not really helpful if someone wants to use edma on a device which
requires a xbar mapping.

Fix the issues by:

- annotating the device tree entry with "/bits/ 16" as documented in
  the of_property_read_u16_array kernel doc

- make the size of the xbar register mapping correct

- invalidating the end of the array and not the start

This convoluted mess wants to be completely rewritten as there is no
point to keep the xbar_chan array memory and the iomapping of the xbar
regs around forever. Marking the xbar mapped channels as used should
be done right there.

But that's a different issue and this patch is small enough to make it
work and allows a simple backport for stable.

Cc: stable@vger.kernel.org # v3.12+
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>

Commit 7b2e1277 ("ARM: OMAP3: clock:
Back-propagate rate change from cam_mclk to dpll4_m5") enabled clock
rate back-propagation from cam_mclk do dpll4_m5 on OMAP3630 only.
Perform back-propagation on other OMAP3 platforms as well.
Reported-by: NJean-Philippe François <jp.francois@cynove.com>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: <stable@kernel.org>
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

For some reason, the base address of the fifth I2C adapter in the A20 was
incorrect. Change this to the actual base address.
Reported-by: NMarcus Cooper <codekipper@gmail.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>

The kvm/mmu code shared by arm and arm64 uses kalloc() to allocate
a bounce page (if hypervisor init code crosses page boundary) and
hypervisor PGDs. The problem is that kalloc() does not guarantee
the proper alignment. In the case of the bounce page, the page sized
buffer allocated may also cross a page boundary negating the purpose
and leading to a hang during kvm initialization. Likewise the PGDs
allocated may not meet the minimum alignment requirements of the
underlying MMU. This patch uses __get_free_page() to guarantee the
worst case alignment needs of the bounce page and PGDs on both arm
and arm64.

Cc: <stable@vger.kernel.org> # 3.10+
Signed-off-by: NMark Salter <msalter@redhat.com>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

virt_to_pfn has been defined in asm/memory.h by the commit e26a9e00 "ARM: Better
virt_to_page() handling"

This will result of a compilation warning when CONFIG_XEN is enabled.

arch/arm/include/asm/xen/page.h:80:0: warning: "virt_to_pfn" redefined [enabled by default]
 #define virt_to_pfn(v)          (PFN_DOWN(__pa(v)))
 ^
In file included from arch/arm/include/asm/page.h:163:0,
                 from arch/arm/include/asm/xen/page.h:4,
                 from include/xen/page.h:4,
                 from arch/arm/xen/grant-table.c:33:

The definition in memory.h is nearly the same (it directly expand PFN_DOWN),
so we can safely drop virt_to_pfn in xen include.
Signed-off-by: NJulien Grall <julien.grall@linaro.org>
Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>

KVM currently crashes and burns on big-endian hosts, so don't allow it
to be selected until we've got that fixed.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

Commit 62e3879a (imx-drm: imx-tve: Fix DDC I2C bus property) was trying
to use 'ddc-i2c-bus' as the DDC property name (we can see that from the
commit log), but unfortunately 'i2c-ddc-bus' which is a typo was
actually used in the code.  This results in some unnecessary
inconsistency and confusions, because all the documented DDC property
in device tree bindings use 'ddc-i2c-bus'.

  Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
  Documentation/devicetree/bindings/panel/simple-panel.txt
  Documentation/devicetree/bindings/video/dvi-connector.txt

Let's fix it before the error spreads.
Signed-off-by: NShawn Guo <shawn.guo@freescale.com>
Acked-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The mmu-gather operation 'tlb_flush_mmu()' has done two things: the
actual tlb flush operation, and the batched freeing of the pages that
the TLB entries pointed at.

This splits the operation into separate phases, so that the forced
batched flushing done by zap_pte_range() can now do the actual TLB flush
while still holding the page table lock, but delay the batched freeing
of all the pages to after the lock has been dropped.

This in turn allows us to avoid a race condition between
set_page_dirty() (as called by zap_pte_range() when it finds a dirty
shared memory pte) and page_mkclean(): because we now flush all the
dirty page data from the TLB's while holding the pte lock,
page_mkclean() will be held up walking the (recently cleaned) page
tables until after the TLB entries have been flushed from all CPU's.
Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NDave Hansen <dave.hansen@intel.com>
Acked-by: NHugh Dickins <hughd@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The codec is defined both in DT and the board file. The board file
however contains platform data which is required in order that the
codec works. When the DT instantiates the codec before the board files
does, it is missing the platform data and so fails. Remove the DT node
until we have a binding which can pass the additional data.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lkml.kernel.org/r/1397565608-1830-1-git-send-email-andrew@lunn.chSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The Armada 375 SoC has a dual-port SATA interface, which is exposed on
the Armada 375 DB board. This commit therefore enables this interface
on the Armada 375 DB board.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397806908-7550-3-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

In commit 249f3822 ('ARM: mvebu: add
audio support to Armada 370 DB'), the I2C bus 0 was enabled on the
Armada 370 DB board, and an I2C codec was described as being connected
on this bus.

However, this commit forgot to define the I2C bus frequency, which
leads the i2c-mv64xxx to fail probing, as it cannot calculate the baud
rate multiplier/divisor to derive the I2C bus frequency from the core
SoC frequency. It makes audio completely unusable, as the I2C bus is
not probed, and therefore the audio codec is not probed either.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397806908-7550-2-git-send-email-thomas.petazzoni@free-electrons.comSigned-off-by: NJason Cooper <jason@lakedaemon.net>

The Armada XP GP isn't using rgmii-id connections between the MAC and
PHY, but instead a single QSGMII connection, which is a quad-SGMII
connection: a double pair of differential lines that are multiplexed
to convey the traffic of four network interfaces between a MAC and a
PHY.

Until now, the Armada XP GP was relying on the bootloader setting the
correct values in various configuration registers. With this change,
the mvneta driver can be used as a module on this platform.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazzoni@free-electrons.comTested-by: NArnaud Ebalard <arno@natisbad.org>
Tested-by: NWilly Tarreau <w@1wt.eu>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was
declared, even though the hardware actually has a 16 bits bus width
connection with the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
a7d4f818 ('ARM: mvebu: Add support for
NOR flash device on Openblocks AX3 board') which was merged in v3.10.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: a7d4f818 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
Cc: stable@vger.kernel.org # v3.10+
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP DB Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
b484ff42 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-DB board') which was merged in v3.11.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: b484ff42 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board')
Cc: stable@vger.kernel.org # v3.11+
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
da8d1b38 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: da8d1b38 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Cc: stable@vger.kernel.org # v3.10+
Acked-by: NEzequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

AM3517 inherits OMAP3 dts file, but does not have all the IPs
that are present on OMAP3. This patch disables the following
absent IPs for AM3517: Mailbox, IVA, MMU_ISP, MPU_IVA SmartReflex.

A label had to be added for IVA node in omap3.dtsi to be able to
get a reference to the node for disabling.

Otherwise we get the following warnings during booting:
platform iva.2: Cannot lookup hwmod 'iva'
platform 48094000.mailbox: Cannot lookup hwmod 'mailbox'
platform 480bd400.mmu: Cannot lookup hwmod 'mmu_isp'
platform 480c9000.smartreflex: Cannot lookup hwmod 'smartreflex_mpu_iva'
Signed-off-by: NSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description for the warnings]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The mailbox module is capable of generating two interrupts
to MPU in OMAP2420, compared to one in OMAP2430. The second
interrupt is to handle interrupts from the additional IVA
processor present only on OMAP2420.

Move the current common mailbox DT node into the SoC
specific files to allow the above differentiation. Also,
added back the interrupt-names on OMAP2420, that were
previously defined in hwmod data.

This fixes regression caused by the recent dropping of
hwmod data in favor for defining it in the .dts files.
Signed-off-by: NSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add the mailbox device DT node for OMAP5 SoC. The OMAP5 mailbox
IP is identical to that used in OMAP4.

The OMAP5 hwmod data no longer publishes the module address space,
so this patch fixes the WARN_ON backtrace associated with the
following trace during the kernel boot:
"omap_hwmod: mailbox: doesn't have mpu register target base".

Otherwise we get a warning like this:

WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2538 _init+0x1c0/0x3dc()
omap_hwmod: mailbox: doesn't have mpu register target base
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.15.0-rc2-00001-gb5e85a0 #45
[<c0015724>] (unwind_backtrace) from [<c00120f4>] (show_stack+0x10/0x14)
[<c00120f4>] (show_stack) from [<c05a1ccc>] (dump_stack+0x78/0x94)
[<c05a1ccc>] (dump_stack) from [<c0042a74>] (warn_slowpath_common+0x6c/0x8c)
[<c0042a74>] (warn_slowpath_common) from [<c0042b28>] (warn_slowpath_fmt+0x30/0x40)
[<c0042b28>] (warn_slowpath_fmt) from [<c0803b40>] (_init+0x1c0/0x3dc)
[<c0803b40>] (_init) from [<c0029c8c>] (omap_hwmod_for_each+0x34/0x5c)
[<c0029c8c>] (omap_hwmod_for_each) from [<c08042b0>] (__omap_hwmod_setup_all+0x24/0x40)
[<c08042b0>] (__omap_hwmod_setup_all) from [<c00088b8>] (do_one_initcall+0x34/0x160)
[<c00088b8>] (do_one_initcall) from [<c07f7bf4>] (kernel_init_freeable+0xfc/0x1c8)
[<c07f7bf4>] (kernel_init_freeable) from [<c059c4f4>] (kernel_init+0x8/0xe4)
[<c059c4f4>] (kernel_init) from [<c000eaa8>] (ret_from_fork+0x14/0x2c)
Signed-off-by: NSuman Anna <s-anna@ti.com>
[tony@atomide.com: updated description to for the warning]
Signed-off-by: NTony Lindgren <tony@atomide.com>

On my DRA7 system, when the kernel is built in Thumb-2 mode, the secondary CPU
(Cortex A15) fails to come up causing SMP boot on second CPU to timeout. This
seems to be because the CPU is in ARM mode once the ROM hands over control to
the kernel.  Switch to Thumb-2 mode if required once the kernel is control of
secondary CPU. On OMAP4 on the other hand, it appears to be in Thumb-2 mode on
entry so this is not required and SMP boot works as is.

Also corrected a spurious '+' and updated copyright information.

Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Nishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Do not reset GPIO5 at boot-up because GPIO5_7 is used
on AM437x GP-EVM to control VTT regulators on DDR3.
Without this some GP-EVM boards will fail to boot because
of DDR3 corruption.
Reported-by: NNishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NDave Gerlach <d-gerlach@ti.com>
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IGEPv2 board has a SMSC LAN9221i ethernet chip and not a
SMSC LAN911x connected to the GPMC. Each chip needs different
timings in order to operate correctly so is wrong to include
omap-gpmc-smsc911x.dtsi instead of omap-gpmc-smsc9221.dtsi.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
[tony@atomide.com: this is needed to avoid potential memory corruption]
Signed-off-by: NTony Lindgren <tony@atomide.com>