linux-stable.git/arch/arm/boot, branch v3.10.63

ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree

2014-06-16T20:42:52+00:00

commit 6e20bae8a39c40d4e03698e4160bad2d2629062b upstream.

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
a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for
NOR flash device on Openblocks AX3 board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
Cc: stable@vger.kernel.org # v3.10+
Acked-by: Ezequiel Garcia 
Acked-by: Gregory CLEMENT 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree

2014-06-16T20:42:52+00:00

commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream.

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
da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Cc: stable@vger.kernel.org # v3.10+
Acked-by: Ezequiel Garcia 
Acked-by: Gregory CLEMENT 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: i.MX53: Fix ipu register space size

2014-06-07T20:25:34+00:00

commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream.

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

Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support'
Signed-off-by: Sascha Hauer 
Acked-by: Shawn Guo 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: ensure the mdio node has a clock reference on Armada 370/XP

2014-05-06T14:55:27+00:00

commit a6e03dd451c724f785277d8ecca5d1a0b886d892 upstream.

The mvmdio driver accesses some register of the Ethernet unit. It
therefore takes a reference and enables a clock. However, on Armada
370/XP, no clock specification was given in the Device Tree, which
leads the mvmdio driver to fail when being used as a module and loaded
before the mvneta driver: it tries to access a register from a
hardware unit that isn't clocked.

Signed-off-by: Thomas Petazzoni 
Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Andrew Lunn 
Acked-by: Gregory CLEMENT 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: Keep G3D regulator always on for exynos5250-arndale

2014-05-06T14:55:26+00:00

commit bfeda827278f09f4db35877e5f1ca9c149ca2890 upstream.

Apparently, if G3D regulator is powered off, the SoC cannot enter low
power modes and just hangs. This patch fixes this by keeping the
regulator always on when the system is running, as suggested by Exynos 4
User's Manual in case of Exynos4210/4x12 SoCs (Exynos5250 UM does not
have such note, but observed behavior seems to confirm that it is true
for this SoC as well).

This fixes an issue preventing Arndale board from entering sleep mode
observed since commit

346f372f7b72a0 clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock

that landed in kernel 3.10, which has fixed the clock driver to make the
SoC actually try to enter the sleep mode.

Signed-off-by: Tomasz Figa 
Acked-by: Kyungmin Park 
Tested-by: Tushar Behera 
Signed-off-by: Kukjin Kim 
Signed-off-by: Greg Kroah-Hartman

ARM: dts: exynos5250: Fix MDMA0 clock number

2014-01-15T23:28:51+00:00

commit 8777539479abd7b3efeb691685415dc2b057d0e0 upstream.

Due to incorrect clock specified in MDMA0 node, using MDMA0 controller
could cause system failures, due to wrong clock being controlled. This
patch fixes this by specifying correct clock.

Signed-off-by: Abhilash Kesavan 
Acked-by: Mike Turquette 
[t.figa: Corrected commit message and description.]
Signed-off-by: Tomasz Figa 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable

2013-12-12T06:36:29+00:00

commit 12b69a599745fc9e203f61fbb7160b2cc5f479dd upstream.

Various Marvell datasheets advertise second PCIe unit of mv78230
flavour of Armada XP as x4/quad x1 capable. This second unit is in
fact only x1 capable. This patch fixes current mv78230 .dtsi to
reflect that, i.e. makes 1.0 the second interface (instead of 2.0
at the moment). This was successfully tested on a mv78230-based
ReadyNAS 2120 platform with a x1 device (FL1009 XHCI controller)
connected to this second interface.

Signed-off-by: Arnaud Ebalard 
Acked-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260

2013-12-12T06:36:29+00:00

commit 2163e61c92d9337e721a0d067d88ae62b52e0d3e upstream.

mv78260 flavour of Marvell Armada XP SoC has 3 PCIe units. The
two first units are both x4 and quad x1 capable. The third unit
is only x4 capable. This patch fixes mv78260 .dtsi to reflect
those capabilities.

Signed-off-by: Arnaud Ebalard 
Acked-by: Thomas Petazzoni 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: use the virtual CPU registers to access coherency registers

2013-12-12T06:36:26+00:00

commit b6dda00cddcc71d2030668bc0cc0fed758c411c2 upstream.

The Armada XP provides a mechanism called "virtual CPU registers" or
"per-CPU register banking", to access the per-CPU registers of the
current CPU, without having to worry about finding on which CPU we're
running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
current CPU registers are at 0x21000.

However, in the Device Tree node that provides the register addresses
for the coherency unit (which is responsible for ensuring coherency
between processors, and I/O coherency between processors and the
DMA-capable devices), a mistake was made: the CPU0-specific registers
were specified instead of the virtual CPU registers. This means that
the coherency barrier needed for I/O coherency was not behaving
properly when executed from a CPU different from CPU0. This patch
fixes that by using the virtual CPU registers.

Signed-off-by: Gregory CLEMENT 
Signed-off-by: Thomas Petazzoni 
Fixes: e60304f8cb7bb5 "arm: mvebu: Add hardware I/O Coherency support"
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: bcm2835: add missing #xxx-cells to I2C nodes

2013-12-04T18:55:50+00:00

commit a31ab44ef5d07c6707df4a9ad2c8affd2d62ff4b upstream.

The I2C controller node needs #address-cells and #size-cells properties,
but these are currently missing. Add them. This allows child nodes to be
parsed correctly.

Signed-off-by: Stephen Warren 
Signed-off-by: Olof Johansson 
Signed-off-by: Greg Kroah-Hartman