--- /dev/null
+From 58e7b1d5826ac6a64b1101d8a70162bc084a7d1e Mon Sep 17 00:00:00 2001
+From: Ludovic Desroches <ludovic.desroches@atmel.com>
+Date: Fri, 22 Nov 2013 17:08:43 +0100
+Subject: ARM: at91: sama5d3: reduce TWI internal clock frequency
+
+From: Ludovic Desroches <ludovic.desroches@atmel.com>
+
+commit 58e7b1d5826ac6a64b1101d8a70162bc084a7d1e upstream.
+
+With some devices, transfer hangs during I2C frame transmission. This issue
+disappears when reducing the internal frequency of the TWI IP. Even if it is
+indicated that internal clock max frequency is 66MHz, it seems we have
+oversampling on I2C signals making TWI believe that a transfer in progress
+is done.
+
+This fix has no impact on the I2C bus frequency.
+
+Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
+Acked-by: Wolfram Sang <wsa@the-dreams.de>
+Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
+Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-at91/sama5d3.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/arch/arm/mach-at91/sama5d3.c
++++ b/arch/arm/mach-at91/sama5d3.c
+@@ -95,19 +95,19 @@ static struct clk twi0_clk = {
+ .name = "twi0_clk",
+ .pid = SAMA5D3_ID_TWI0,
+ .type = CLK_TYPE_PERIPHERAL,
+- .div = AT91_PMC_PCR_DIV2,
++ .div = AT91_PMC_PCR_DIV8,
+ };
+ static struct clk twi1_clk = {
+ .name = "twi1_clk",
+ .pid = SAMA5D3_ID_TWI1,
+ .type = CLK_TYPE_PERIPHERAL,
+- .div = AT91_PMC_PCR_DIV2,
++ .div = AT91_PMC_PCR_DIV8,
+ };
+ static struct clk twi2_clk = {
+ .name = "twi2_clk",
+ .pid = SAMA5D3_ID_TWI2,
+ .type = CLK_TYPE_PERIPHERAL,
+- .div = AT91_PMC_PCR_DIV2,
++ .div = AT91_PMC_PCR_DIV8,
+ };
+ static struct clk mmc0_clk = {
+ .name = "mci0_clk",
--- /dev/null
+From 2ba2866f782f7f1c38abc3dd56d3295efd289264 Mon Sep 17 00:00:00 2001
+From: Balaji T K <balajitk@ti.com>
+Date: Mon, 2 Dec 2013 11:38:13 -0800
+Subject: ARM: dts: omap4-panda-common: Fix pin muxing for wl12xx
+
+From: Balaji T K <balajitk@ti.com>
+
+commit 2ba2866f782f7f1c38abc3dd56d3295efd289264 upstream.
+
+pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
+and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.
+
+Fix the following error message:
+pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
+pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x
+
+SDIO card is not detected after moving pin mux to omap4_pmx_core since
+sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.
+
+This fixes a regression where WLAN did not work after a warm reset
+or after one up/down cycle that happened when we move omap4 to boot
+using device tree only. For reference, the kernel bug is described at:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=63821
+
+Signed-off-by: Balaji T K <balajitk@ti.com>
+[tony@atomide.com: update comments to describe the regression]
+Signed-off-by: Tony Lindgren <tony@atomide.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/omap4-panda-common.dtsi | 20 ++++++++++----------
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
++++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
+@@ -239,15 +239,6 @@
+ 0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
+ >;
+ };
+-};
+-
+-&omap4_pmx_wkup {
+- led_wkgpio_pins: pinmux_leds_wkpins {
+- pinctrl-single,pins = <
+- 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
+- 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
+- >;
+- };
+
+ /*
+ * wl12xx GPIO outputs for WLAN_EN, BT_EN, FM_EN, BT_WAKEUP
+@@ -267,7 +258,7 @@
+ pinctrl-single,pins = <
+ 0x38 (PIN_INPUT | MUX_MODE3) /* gpmc_ncs2.gpio_52 */
+ 0x3a (PIN_INPUT | MUX_MODE3) /* gpmc_ncs3.gpio_53 */
+- 0x108 (PIN_OUTPUT | MUX_MODE0) /* sdmmc5_clk.sdmmc5_clk */
++ 0x108 (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_clk.sdmmc5_clk */
+ 0x10a (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_cmd.sdmmc5_cmd */
+ 0x10c (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat0.sdmmc5_dat0 */
+ 0x10e (PIN_INPUT_PULLUP | MUX_MODE0) /* sdmmc5_dat1.sdmmc5_dat1 */
+@@ -276,6 +267,15 @@
+ >;
+ };
+ };
++
++&omap4_pmx_wkup {
++ led_wkgpio_pins: pinmux_leds_wkpins {
++ pinctrl-single,pins = <
++ 0x1a (PIN_OUTPUT | MUX_MODE3) /* gpio_wk7 */
++ 0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
++ >;
++ };
++};
+
+ &i2c1 {
+ pinctrl-names = "default";
--- /dev/null
+From 67130c5464f50428aea0b4526a6729d61f9a1d53 Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Fri, 29 Nov 2013 00:54:38 +0000
+Subject: ARM: footbridge: fix EBSA285 LEDs
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit 67130c5464f50428aea0b4526a6729d61f9a1d53 upstream.
+
+- The LEDs register is write-only: it can't be read-modify-written.
+- The LEDs are write-1-for-off not 0.
+- The check for the platform was inverted.
+
+Fixes: cf6856d693dd ("ARM: mach-footbridge: retire custom LED code")
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-footbridge/ebsa285.c | 22 +++++++++++++---------
+ 1 file changed, 13 insertions(+), 9 deletions(-)
+
+--- a/arch/arm/mach-footbridge/ebsa285.c
++++ b/arch/arm/mach-footbridge/ebsa285.c
+@@ -30,21 +30,24 @@ static const struct {
+ const char *name;
+ const char *trigger;
+ } ebsa285_leds[] = {
+- { "ebsa285:amber", "heartbeat", },
+- { "ebsa285:green", "cpu0", },
++ { "ebsa285:amber", "cpu0", },
++ { "ebsa285:green", "heartbeat", },
+ { "ebsa285:red",},
+ };
+
++static unsigned char hw_led_state;
++
+ static void ebsa285_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
+ {
+ struct ebsa285_led *led = container_of(cdev,
+ struct ebsa285_led, cdev);
+
+- if (b != LED_OFF)
+- *XBUS_LEDS |= led->mask;
++ if (b == LED_OFF)
++ hw_led_state |= led->mask;
+ else
+- *XBUS_LEDS &= ~led->mask;
++ hw_led_state &= ~led->mask;
++ *XBUS_LEDS = hw_led_state;
+ }
+
+ static enum led_brightness ebsa285_led_get(struct led_classdev *cdev)
+@@ -52,18 +55,19 @@ static enum led_brightness ebsa285_led_g
+ struct ebsa285_led *led = container_of(cdev,
+ struct ebsa285_led, cdev);
+
+- return (*XBUS_LEDS & led->mask) ? LED_FULL : LED_OFF;
++ return hw_led_state & led->mask ? LED_OFF : LED_FULL;
+ }
+
+ static int __init ebsa285_leds_init(void)
+ {
+ int i;
+
+- if (machine_is_ebsa285())
++ if (!machine_is_ebsa285())
+ return -ENODEV;
+
+- /* 3 LEDS All ON */
+- *XBUS_LEDS |= XBUS_LED_AMBER | XBUS_LED_GREEN | XBUS_LED_RED;
++ /* 3 LEDS all off */
++ hw_led_state = XBUS_LED_AMBER | XBUS_LED_GREEN | XBUS_LED_RED;
++ *XBUS_LEDS = hw_led_state;
+
+ for (i = 0; i < ARRAY_SIZE(ebsa285_leds); i++) {
+ struct ebsa285_led *led;
--- /dev/null
+From 43659222e7a0113912ed02f6b2231550b3e471ac Mon Sep 17 00:00:00 2001
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+Date: Thu, 28 Nov 2013 21:55:41 +0000
+Subject: ARM: footbridge: fix VGA initialisation
+
+From: Russell King <rmk+kernel@arm.linux.org.uk>
+
+commit 43659222e7a0113912ed02f6b2231550b3e471ac upstream.
+
+It's no good setting vga_base after the VGA console has been
+initialised, because if we do that we get this:
+
+Unable to handle kernel paging request at virtual address 000b8000
+pgd = c0004000
+[000b8000] *pgd=07ffc831, *pte=00000000, *ppte=00000000
+0Internal error: Oops: 5017 [#1] ARM
+Modules linked in:
+CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0+ #49
+task: c03e2974 ti: c03d8000 task.ti: c03d8000
+PC is at vgacon_startup+0x258/0x39c
+LR is at request_resource+0x10/0x1c
+pc : [<c01725d0>] lr : [<c0022b50>] psr: 60000053
+sp : c03d9f68 ip : 000b8000 fp : c03d9f8c
+r10: 000055aa r9 : 4401a103 r8 : ffffaa55
+r7 : c03e357c r6 : c051b460 r5 : 000000ff r4 : 000c0000
+r3 : 000b8000 r2 : c03e0514 r1 : 00000000 r0 : c0304971
+Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel
+
+which is an access to the 0xb8000 without the PCI offset required to
+make it work.
+
+Fixes: cc22b4c18540 ("ARM: set vga memory base at run-time")
+Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mach-footbridge/common.c | 3 +++
+ arch/arm/mach-footbridge/dc21285.c | 2 --
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/mach-footbridge/common.c
++++ b/arch/arm/mach-footbridge/common.c
+@@ -15,6 +15,7 @@
+ #include <linux/init.h>
+ #include <linux/io.h>
+ #include <linux/spinlock.h>
++#include <video/vga.h>
+
+ #include <asm/pgtable.h>
+ #include <asm/page.h>
+@@ -196,6 +197,8 @@ void __init footbridge_map_io(void)
+ iotable_init(ebsa285_host_io_desc, ARRAY_SIZE(ebsa285_host_io_desc));
+ pci_map_io_early(__phys_to_pfn(DC21285_PCI_IO));
+ }
++
++ vga_base = PCIMEM_BASE;
+ }
+
+ void footbridge_restart(enum reboot_mode mode, const char *cmd)
+--- a/arch/arm/mach-footbridge/dc21285.c
++++ b/arch/arm/mach-footbridge/dc21285.c
+@@ -18,7 +18,6 @@
+ #include <linux/irq.h>
+ #include <linux/io.h>
+ #include <linux/spinlock.h>
+-#include <video/vga.h>
+
+ #include <asm/irq.h>
+ #include <asm/mach/pci.h>
+@@ -291,7 +290,6 @@ void __init dc21285_preinit(void)
+ int cfn_mode;
+
+ pcibios_min_mem = 0x81000000;
+- vga_base = PCIMEM_BASE;
+
+ mem_size = (unsigned int)high_memory - PAGE_OFFSET;
+ for (mem_mask = 0x00100000; mem_mask < 0x10000000; mem_mask <<= 1)
--- /dev/null
+From f39918eec72c841037f16475867dac1a2b0bfc01 Mon Sep 17 00:00:00 2001
+From: Olof Johansson <olof@lixom.net>
+Date: Tue, 3 Dec 2013 10:21:49 -0800
+Subject: ARM: multi_v7_defconfig: enable SDHCI_BCM_KONA and MMC_BLOCK_MINORS=16
+
+From: Olof Johansson <olof@lixom.net>
+
+commit f39918eec72c841037f16475867dac1a2b0bfc01 upstream.
+
+Enable MMC/SD on the Broadcom mobile platforms, and increase the block
+minors from the default 8 to 16 (since the Broadcom board by default
+has root on the 8th partition).
+
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/configs/multi_v7_defconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/configs/multi_v7_defconfig
++++ b/arch/arm/configs/multi_v7_defconfig
+@@ -132,12 +132,14 @@ CONFIG_USB_GPIO_VBUS=y
+ CONFIG_USB_ISP1301=y
+ CONFIG_USB_MXS_PHY=y
+ CONFIG_MMC=y
++CONFIG_MMC_BLOCK_MINORS=16
+ CONFIG_MMC_ARMMMCI=y
+ CONFIG_MMC_SDHCI=y
+ CONFIG_MMC_SDHCI_PLTFM=y
+ CONFIG_MMC_SDHCI_ESDHC_IMX=y
+ CONFIG_MMC_SDHCI_TEGRA=y
+ CONFIG_MMC_SDHCI_SPEAR=y
++CONFIG_MMC_SDHCI_BCM_KONA=y
+ CONFIG_MMC_OMAP=y
+ CONFIG_MMC_OMAP_HS=y
+ CONFIG_EDAC=y
--- /dev/null
+From 2163e61c92d9337e721a0d067d88ae62b52e0d3e Mon Sep 17 00:00:00 2001
+From: Arnaud Ebalard <arno@natisbad.org>
+Date: Tue, 5 Nov 2013 21:46:02 +0100
+Subject: ARM: mvebu: fix second and third PCIe unit of Armada XP mv78260
+
+From: Arnaud Ebalard <arno@natisbad.org>
+
+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 <arno@natisbad.org>
+Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-mv78260.dtsi | 109 ++++++++++++++++++++++++-------
+ 1 file changed, 85 insertions(+), 24 deletions(-)
+
+--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
++++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+@@ -48,7 +48,7 @@
+ /*
+ * MV78260 has 3 PCIe units Gen2.0: Two units can be
+ * configured as x4 or quad x1 lanes. One unit is
+- * x4/x1.
++ * x4 only.
+ */
+ pcie-controller {
+ compatible = "marvell,armada-xp-pcie";
+@@ -67,7 +67,9 @@
+ 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
+ 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
+ 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */
+- 0x82000000 0 0x82000 MBUS_ID(0xf0, 0x01) 0x82000 0 0x00002000 /* Port 3.0 registers */
++ 0x82000000 0 0x84000 MBUS_ID(0xf0, 0x01) 0x84000 0 0x00002000 /* Port 1.1 registers */
++ 0x82000000 0 0x88000 MBUS_ID(0xf0, 0x01) 0x88000 0 0x00002000 /* Port 1.2 registers */
++ 0x82000000 0 0x8c000 MBUS_ID(0xf0, 0x01) 0x8c000 0 0x00002000 /* Port 1.3 registers */
+ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+@@ -76,10 +78,18 @@
+ 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */
+ 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+ 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */
+- 0x82000000 0x9 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
+- 0x81000000 0x9 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */
+- 0x82000000 0xa 0 MBUS_ID(0x08, 0xf8) 0 1 0 /* Port 3.0 MEM */
+- 0x81000000 0xa 0 MBUS_ID(0x08, 0xf0) 0 1 0 /* Port 3.0 IO */>;
++
++ 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
++ 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */
++ 0x82000000 0x6 0 MBUS_ID(0x08, 0xd8) 0 1 0 /* Port 1.1 MEM */
++ 0x81000000 0x6 0 MBUS_ID(0x08, 0xd0) 0 1 0 /* Port 1.1 IO */
++ 0x82000000 0x7 0 MBUS_ID(0x08, 0xb8) 0 1 0 /* Port 1.2 MEM */
++ 0x81000000 0x7 0 MBUS_ID(0x08, 0xb0) 0 1 0 /* Port 1.2 IO */
++ 0x82000000 0x8 0 MBUS_ID(0x08, 0x78) 0 1 0 /* Port 1.3 MEM */
++ 0x81000000 0x8 0 MBUS_ID(0x08, 0x70) 0 1 0 /* Port 1.3 IO */
++
++ 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
++ 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */>;
+
+ pcie@1,0 {
+ device_type = "pci";
+@@ -105,8 +115,8 @@
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+- ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
+- 0x81000000 0 0 0x81000000 0x2 0 1 0>;
++ ranges = <0x82000000 0 0 0x82000000 0x2 0 1 0
++ 0x81000000 0 0 0x81000000 0x2 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &mpic 59>;
+ marvell,pcie-port = <0>;
+@@ -149,37 +159,88 @@
+ status = "disabled";
+ };
+
+- pcie@9,0 {
++ pcie@5,0 {
+ device_type = "pci";
+- assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+- reg = <0x4800 0 0 0 0>;
++ assigned-addresses = <0x82000800 0 0x80000 0 0x2000>;
++ reg = <0x2800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+- ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+- 0x81000000 0 0 0x81000000 0x9 0 1 0>;
++ ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
++ 0x81000000 0 0 0x81000000 0x5 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+- interrupt-map = <0 0 0 0 &mpic 99>;
+- marvell,pcie-port = <2>;
++ interrupt-map = <0 0 0 0 &mpic 62>;
++ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+- clocks = <&gateclk 26>;
++ clocks = <&gateclk 9>;
+ status = "disabled";
+ };
+
+- pcie@10,0 {
++ pcie@6,0 {
+ device_type = "pci";
+- assigned-addresses = <0x82000800 0 0x82000 0 0x2000>;
+- reg = <0x5000 0 0 0 0>;
++ assigned-addresses = <0x82000800 0 0x84000 0 0x2000>;
++ reg = <0x3000 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+- ranges = <0x82000000 0 0 0x82000000 0xa 0 1 0
+- 0x81000000 0 0 0x81000000 0xa 0 1 0>;
++ ranges = <0x82000000 0 0 0x82000000 0x6 0 1 0
++ 0x81000000 0 0 0x81000000 0x6 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+- interrupt-map = <0 0 0 0 &mpic 103>;
+- marvell,pcie-port = <3>;
++ interrupt-map = <0 0 0 0 &mpic 63>;
++ marvell,pcie-port = <1>;
++ marvell,pcie-lane = <1>;
++ clocks = <&gateclk 10>;
++ status = "disabled";
++ };
++
++ pcie@7,0 {
++ device_type = "pci";
++ assigned-addresses = <0x82000800 0 0x88000 0 0x2000>;
++ reg = <0x3800 0 0 0 0>;
++ #address-cells = <3>;
++ #size-cells = <2>;
++ #interrupt-cells = <1>;
++ ranges = <0x82000000 0 0 0x82000000 0x7 0 1 0
++ 0x81000000 0 0 0x81000000 0x7 0 1 0>;
++ interrupt-map-mask = <0 0 0 0>;
++ interrupt-map = <0 0 0 0 &mpic 64>;
++ marvell,pcie-port = <1>;
++ marvell,pcie-lane = <2>;
++ clocks = <&gateclk 11>;
++ status = "disabled";
++ };
++
++ pcie@8,0 {
++ device_type = "pci";
++ assigned-addresses = <0x82000800 0 0x8c000 0 0x2000>;
++ reg = <0x4000 0 0 0 0>;
++ #address-cells = <3>;
++ #size-cells = <2>;
++ #interrupt-cells = <1>;
++ ranges = <0x82000000 0 0 0x82000000 0x8 0 1 0
++ 0x81000000 0 0 0x81000000 0x8 0 1 0>;
++ interrupt-map-mask = <0 0 0 0>;
++ interrupt-map = <0 0 0 0 &mpic 65>;
++ marvell,pcie-port = <1>;
++ marvell,pcie-lane = <3>;
++ clocks = <&gateclk 12>;
++ status = "disabled";
++ };
++
++ pcie@9,0 {
++ device_type = "pci";
++ assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
++ reg = <0x4800 0 0 0 0>;
++ #address-cells = <3>;
++ #size-cells = <2>;
++ #interrupt-cells = <1>;
++ ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
++ 0x81000000 0 0 0x81000000 0x9 0 1 0>;
++ interrupt-map-mask = <0 0 0 0>;
++ interrupt-map = <0 0 0 0 &mpic 99>;
++ marvell,pcie-port = <2>;
+ marvell,pcie-lane = <0>;
+- clocks = <&gateclk 27>;
++ clocks = <&gateclk 26>;
+ status = "disabled";
+ };
+ };
--- /dev/null
+From 96039f735e290281d0c8a08fc467de2cd610543d Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Mon, 25 Nov 2013 17:26:47 +0100
+Subject: ARM: mvebu: re-enable PCIe on Armada 370 DB
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 96039f735e290281d0c8a08fc467de2cd610543d upstream.
+
+Commit 14fd8ed0a7fd19913 ("ARM: mvebu: Relocate Armada 370/XP PCIe
+device tree nodes") relocated the PCIe controller DT nodes one level
+up in the Device Tree, to reflect a more correct representation of the
+hardware introduced by the mvebu-mbus Device Tree binding.
+
+However, while most of the boards were properly adjusted accordingly,
+the Armada 370 DB board was left unchanged, and therefore, PCIe is
+seen as not enabled on this board. This patch fixes that by moving the
+PCIe controller node one level-up in armada-370-db.dts.
+
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Fixes: 14fd8ed0a7fd19913 "ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes"
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-370-db.dts | 28 ++++++++++++++--------------
+ 1 file changed, 14 insertions(+), 14 deletions(-)
+
+--- a/arch/arm/boot/dts/armada-370-db.dts
++++ b/arch/arm/boot/dts/armada-370-db.dts
+@@ -99,22 +99,22 @@
+ spi-max-frequency = <50000000>;
+ };
+ };
++ };
+
+- pcie-controller {
++ pcie-controller {
++ status = "okay";
++ /*
++ * The two PCIe units are accessible through
++ * both standard PCIe slots and mini-PCIe
++ * slots on the board.
++ */
++ pcie@1,0 {
++ /* Port 0, Lane 0 */
++ status = "okay";
++ };
++ pcie@2,0 {
++ /* Port 1, Lane 0 */
+ status = "okay";
+- /*
+- * The two PCIe units are accessible through
+- * both standard PCIe slots and mini-PCIe
+- * slots on the board.
+- */
+- pcie@1,0 {
+- /* Port 0, Lane 0 */
+- status = "okay";
+- };
+- pcie@2,0 {
+- /* Port 1, Lane 0 */
+- status = "okay";
+- };
+ };
+ };
+ };
--- /dev/null
+From 12b69a599745fc9e203f61fbb7160b2cc5f479dd Mon Sep 17 00:00:00 2001
+From: Arnaud Ebalard <arno@natisbad.org>
+Date: Tue, 5 Nov 2013 21:45:48 +0100
+Subject: ARM: mvebu: second PCIe unit of Armada XP mv78230 is only x1 capable
+
+From: Arnaud Ebalard <arno@natisbad.org>
+
+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 <arno@natisbad.org>
+Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-xp-mv78230.dtsi | 24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
++++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+@@ -47,7 +47,7 @@
+ /*
+ * MV78230 has 2 PCIe units Gen2.0: One unit can be
+ * configured as x4 or quad x1 lanes. One unit is
+- * x4/x1.
++ * x1 only.
+ */
+ pcie-controller {
+ compatible = "marvell,armada-xp-pcie";
+@@ -61,10 +61,10 @@
+
+ ranges =
+ <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Port 0.0 registers */
+- 0x82000000 0 0x42000 MBUS_ID(0xf0, 0x01) 0x42000 0 0x00002000 /* Port 2.0 registers */
+ 0x82000000 0 0x44000 MBUS_ID(0xf0, 0x01) 0x44000 0 0x00002000 /* Port 0.1 registers */
+ 0x82000000 0 0x48000 MBUS_ID(0xf0, 0x01) 0x48000 0 0x00002000 /* Port 0.2 registers */
+ 0x82000000 0 0x4c000 MBUS_ID(0xf0, 0x01) 0x4c000 0 0x00002000 /* Port 0.3 registers */
++ 0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000 /* Port 1.0 registers */
+ 0x82000000 0x1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
+ 0x81000000 0x1 0 MBUS_ID(0x04, 0xe0) 0 1 0 /* Port 0.0 IO */
+ 0x82000000 0x2 0 MBUS_ID(0x04, 0xd8) 0 1 0 /* Port 0.1 MEM */
+@@ -73,8 +73,8 @@
+ 0x81000000 0x3 0 MBUS_ID(0x04, 0xb0) 0 1 0 /* Port 0.2 IO */
+ 0x82000000 0x4 0 MBUS_ID(0x04, 0x78) 0 1 0 /* Port 0.3 MEM */
+ 0x81000000 0x4 0 MBUS_ID(0x04, 0x70) 0 1 0 /* Port 0.3 IO */
+- 0x82000000 0x9 0 MBUS_ID(0x04, 0xf8) 0 1 0 /* Port 2.0 MEM */
+- 0x81000000 0x9 0 MBUS_ID(0x04, 0xf0) 0 1 0 /* Port 2.0 IO */>;
++ 0x82000000 0x5 0 MBUS_ID(0x08, 0xe8) 0 1 0 /* Port 1.0 MEM */
++ 0x81000000 0x5 0 MBUS_ID(0x08, 0xe0) 0 1 0 /* Port 1.0 IO */>;
+
+ pcie@1,0 {
+ device_type = "pci";
+@@ -144,20 +144,20 @@
+ status = "disabled";
+ };
+
+- pcie@9,0 {
++ pcie@5,0 {
+ device_type = "pci";
+- assigned-addresses = <0x82000800 0 0x42000 0 0x2000>;
+- reg = <0x4800 0 0 0 0>;
++ assigned-addresses = <0x82000800 0 0x80000 0 0x2000>;
++ reg = <0x2800 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+- ranges = <0x82000000 0 0 0x82000000 0x9 0 1 0
+- 0x81000000 0 0 0x81000000 0x9 0 1 0>;
++ ranges = <0x82000000 0 0 0x82000000 0x5 0 1 0
++ 0x81000000 0 0 0x81000000 0x5 0 1 0>;
+ interrupt-map-mask = <0 0 0 0>;
+- interrupt-map = <0 0 0 0 &mpic 99>;
+- marvell,pcie-port = <2>;
++ interrupt-map = <0 0 0 0 &mpic 62>;
++ marvell,pcie-port = <1>;
+ marvell,pcie-lane = <0>;
+- clocks = <&gateclk 26>;
++ clocks = <&gateclk 9>;
+ status = "disabled";
+ };
+ };
--- /dev/null
+From b6dda00cddcc71d2030668bc0cc0fed758c411c2 Mon Sep 17 00:00:00 2001
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Date: Mon, 25 Nov 2013 17:26:46 +0100
+Subject: ARM: mvebu: use the virtual CPU registers to access coherency registers
+
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+
+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 <gregory.clement@free-electrons.com>
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Fixes: e60304f8cb7bb5 "arm: mvebu: Add hardware I/O Coherency support"
+Signed-off-by: Jason Cooper <jason@lakedaemon.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/armada-370-xp.dtsi | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/boot/dts/armada-370-xp.dtsi
++++ b/arch/arm/boot/dts/armada-370-xp.dtsi
+@@ -117,7 +117,7 @@
+
+ coherency-fabric@20200 {
+ compatible = "marvell,coherency-fabric";
+- reg = <0x20200 0xb0>, <0x21810 0x1c>;
++ reg = <0x20200 0xb0>, <0x21010 0x1c>;
+ };
+
+ serial@12000 {
--- /dev/null
+From c37dd677988ca50bc8bc60ab5ab053720583c168 Mon Sep 17 00:00:00 2001
+From: Aaro Koskinen <aaro.koskinen@iki.fi>
+Date: Mon, 11 Nov 2013 20:41:38 +0200
+Subject: ARM: OMAPFB: panel-sony-acx565akm: fix bad unlock balance
+
+From: Aaro Koskinen <aaro.koskinen@iki.fi>
+
+commit c37dd677988ca50bc8bc60ab5ab053720583c168 upstream.
+
+When booting Nokia N900 smartphone with v3.12 + omap2plus_defconfig
+(LOCKDEP enabled) and CONFIG_DISPLAY_PANEL_SONY_ACX565AKM enabled,
+the following BUG is seen during the boot:
+
+[ 7.302154] =====================================
+[ 7.307128] [ BUG: bad unlock balance detected! ]
+[ 7.312103] 3.12.0-los.git-2093492-00120-g5e01dc7 #3 Not tainted
+[ 7.318450] -------------------------------------
+[ 7.323425] kworker/u2:1/12 is trying to release lock (&ddata->mutex) at:
+[ 7.330657] [<c031b760>] acx565akm_enable+0x12c/0x18c
+[ 7.335998] but there are no more locks to release!
+
+Fix by removing double unlock and handling the locking completely inside
+acx565akm_panel_power_on() when doing the power on.
+
+Reported-by: Eduardo Valentin <eduardo.valentin@ti.com>
+Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/omap2/displays-new/panel-sony-acx565akm.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
++++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+@@ -526,6 +526,8 @@ static int acx565akm_panel_power_on(stru
+ struct omap_dss_device *in = ddata->in;
+ int r;
+
++ mutex_lock(&ddata->mutex);
++
+ dev_dbg(&ddata->spi->dev, "%s\n", __func__);
+
+ in->ops.sdi->set_timings(in, &ddata->videomode);
+@@ -614,10 +616,7 @@ static int acx565akm_enable(struct omap_
+ if (omapdss_device_is_enabled(dssdev))
+ return 0;
+
+- mutex_lock(&ddata->mutex);
+ r = acx565akm_panel_power_on(dssdev);
+- mutex_unlock(&ddata->mutex);
+-
+ if (r)
+ return r;
+
crypto-ccm-fix-handling-of-zero-plaintext-when-computing-mac.patch
crypto-authenc-find-proper-iv-address-in-ablkcipher-callback.patch
arm-fix-booting-low-vectors-machines.patch
+arm-footbridge-fix-vga-initialisation.patch
+arm-footbridge-fix-ebsa285-leds.patch
+arm-multi_v7_defconfig-enable-sdhci_bcm_kona-and-mmc_block_minors-16.patch
+arm-dts-omap4-panda-common-fix-pin-muxing-for-wl12xx.patch
+arm-omapfb-panel-sony-acx565akm-fix-bad-unlock-balance.patch
+arm-at91-sama5d3-reduce-twi-internal-clock-frequency.patch
+arm-mvebu-second-pcie-unit-of-armada-xp-mv78230-is-only-x1-capable.patch
+arm-mvebu-fix-second-and-third-pcie-unit-of-armada-xp-mv78260.patch
+arm-mvebu-use-the-virtual-cpu-registers-to-access-coherency-registers.patch
+arm-mvebu-re-enable-pcie-on-armada-370-db.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
