linux/arch/arm, branch v3.0.9

ARM: mach-ux500: unlock I&D l2x0 caches before init

2011-11-11T17:36:17Z

commit 1bf6d2c1bb23533af6930581cc39b74685bc29de upstream. Apparently U8500 U-Boot versions may leave the l2x0 locked down before executing the kernel. Make sure we unlock it before we initialize the l2x0. This fixes a performance problem reported by Jan Rinze. The l2x0 core has been modified to unlock the l2x0 by default, but it will not touch the locking registers if the l2x0 was already enabled, as on the ux500, so we need this quirk to make sure it is properly turned off. Cc: Srinidhi Kasagar Cc: Rabin Vincent Cc: Adrian Bunk Reported-by: Jan Rinze Tested-by: Robert Marklund Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

plat-mxc: iomux-v3.h: implicitly enable pull-up/down when that's desired

2011-11-11T17:36:16Z

commit 6571534b600b8ca1936ff5630b9e0947f21faf16 upstream. To configure pads during the initialisation a set of special constants is used, e.g. #define MX25_PAD_FEC_MDIO__FEC_MDIO IOMUX_PAD(0x3c4, 0x1cc, 0x10, 0, 0, PAD_CTL_HYS | PAD_CTL_PUS_22K_UP) The problem is that no pull-up/down is getting activated unless both PAD_CTL_PUE (pull-up enable) and PAD_CTL_PKE (pull/keeper module enable) set. This is clearly stated in the i.MX25 datasheet and is confirmed by the measurements on hardware. This leads to some rather hard to understand bugs such as misdetecting an absent ethernet PHY (a real bug i had), unstable data transfer etc. This might affect mx25, mx35, mx50, mx51 and mx53 SoCs. It's reasonable to expect that if the pullup value is specified, the intention was to have it actually active, so we implicitly add the needed bits. Signed-off-by: Paul Fertser Signed-off-by: Sascha Hauer Signed-off-by: Greg Kroah-Hartman

ARM: 7117/1: perf: fix HW_CACHE_* events on Cortex-A9

2011-10-25T05:10:13Z

commit 29a541f6c1f6e4a85628bb86071b9e72c9f8be2c upstream. Using COHERENT_LINE_{MISS,HIT} for cache misses and references respectively is completely wrong. Instead, use the L1D events which are a better and more useful approximation despite ignoring instruction traffic. Reported-by: Alasdair Grant Reported-by: Matt Horsnell Reported-by: Michael Williams Cc: Jean Pihet Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7113/1: mm: Align bank start to MAX_ORDER_NR_PAGES

2011-10-25T05:10:13Z

commit 002ea9eefec98dada56fd5f8e432a4e8570c2a26 upstream. The VM subsystem assumes that there are valid memmap entries from the bank start aligned to MAX_ORDER_NR_PAGES. On the Ux500 we have a lot of mem=N arguments on the commandline triggering this bug several times over and causing kernel oops messages. Cc: Michael Bohan Cc: Nicolas Pitre Signed-off-by: Johan Palsson Signed-off-by: Rabin Vincent Signed-off-by: Linus Walleij Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: mach-ux500: enable fix for ARM errata 754322

2011-10-16T21:14:54Z

commit 98e87d57aab9b1594f9cc53a386fcb6f2f2ba6e2 upstream. This applies ARM errata fix 754322 for all ux500 platforms. Signed-off-by: srinidhi kasagar Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

ARM: 7099/1: futex: preserve oldval in SMP __futex_atomic_op

2011-10-03T18:41:06Z

commit df77abcafc8dc881b6c9347548651777088e4b27 upstream. The SMP implementation of __futex_atomic_op clobbers oldval with the status flag from the exclusive store. This causes it to always read as zero when performing the FUTEX_OP_CMP_* operation. This patch updates the ARM __futex_atomic_op implementations to take a tmp argument, allowing us to store the strex status flag without overwriting the register containing oldval. Reported-by: Minho Ban Reviewed-by: Nicolas Pitre Signed-off-by: Will Deacon Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: 7091/1: errata: D-cache line maintenance operation by MVA may not succeed

2011-10-03T18:41:06Z

commit f630c1bdfbf8fe423325beaf60027cfc7fd7c610 upstream. This patch implements a workaround for erratum 764369 affecting Cortex-A9 MPCore with two or more processors (all current revisions). Under certain timing circumstances, a data cache line maintenance operation by MVA targeting an Inner Shareable memory region may fail to proceed up to either the Point of Coherency or to the Point of Unification of the system. This workaround adds a DSB instruction before the relevant cache maintenance functions and sets a specific bit in the diagnostic control register of the SCU. Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Tested-by: Mark Rutland Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: dma-mapping: free allocated page if unable to map

2011-10-03T18:41:06Z

commit d8e89b47e00ee80e920761145144640aac4cf71a upstream. If the attempt to map a page for DMA fails (eg, because we're out of mapping space) then we must not hold on to the page we allocated for DMA - doing so will result in a memory leak. Reported-by: Bryan Phillippe Tested-by: Bryan Phillippe Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman

ARM: Dove: fix second SPI initialization call

2011-10-03T18:40:36Z

commit 72cc205611879525db0374d9831f84f787112b25 upstream. Commit 980f9f601a "ARM: orion: Consolidate SPI initialization." broke it by overwriting the SPI0 registration. Signed-off-by: Nicolas Pitre Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman

ARM: davinci: fix cache flush build error

2011-10-03T18:40:13Z

commit 897a6a1a14837d6d582bfd1fd7aba00be44b6469 upstream. The TNET variant of DaVinci compiles some code that it shares with other DaVinci variants, however it has a V6 CPU rather than an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all() in sleep.S will obviously fail, and we need to build with the v6_flush_kern_cache_all() call instead. This was triggered by manually altering the DaVinci config to build the TNET version. Cc: Dave Martin Cc: Arnd Bergmann Signed-off-by: Linus Walleij Signed-off-by: Sekhar Nori Signed-off-by: Greg Kroah-Hartman