* 'fixes' of git://git.linaro.org/people/rmk/linux-arm: (31 commits)
ARM: 7304/1: ioremap: fix boundary check when reusing static mapping
ARM: 7301/1: Rename the T() macro to TUSER() to avoid namespace conflicts
ARM: 7299/1: ftrace: clear zero bit in reported IPs for Thumb-2
ARM: 7298/1: realview: fix mapping of MPCore private memory region
PCMCIA: fix sa1111 oops on remove
ARM: 7288/1: mach-sa1100: add missing module_init() call
ARM: 7297/1: smp_twd: make sure timer is stopped before registering it
ARM: 7296/1: proc-v7.S: remove HARVARD_CACHE preprocessor guards
ARM: 7295/1: cortex-a7: move proc_info out of !CONFIG_ARM_LPAE block
ARM: 7293/1: logical_cpu_map: decouple CPU mapping from SMP
ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs
ARM: 7290/1: vmlinux.lds.S: align the exception fixup table to a 4-byte boundary
ARM: 7289/1: vmlinux.lds.S: do not hardcode cacheline size as 32 bytes
MFD: ucb1x00-ts: fix resume failure
MFD: ucb1x00-core: fix gpiolib direction_output handling
MFD: ucb1x00-core: fix missing restore of io output data on resume
MFD: mcp-core: fix mcp_priv() to be more type safe
MFD: mcp-core: fix complaints from the genirq layer
Revert "ARM: sa11x0: Implement autoloading of codec and codec pdata for mcp bus."
Revert "ARM: sa1100: Refactor mcp-sa11x0 to use platform resources."
...
Fix up conflict due to arch/arm/mach-mx5/Kconfig having been merged into
mach-imx5 (commit 784a90c0a7: "ARM i.MX: Merge i.MX5 support into
mach-imx"), but the ARM_L1_CACHE_SHIFT_6 entry was moved to be driven by
the CPU_V7 logic from it in the old location in rmk's branch (commit
a092f2b153: "ARM: 7291/1: cache: assume 64-byte L1 cachelines for
ARMv7 CPUs").
arm-soc fixes for 3.3-rc:
AT91 needed reset fixes which resulted in some minor code refactoring,
it also adds a feature-removal for one of their platforms for 3.4.
The USB patches have been acked by Greg K-H.
i.MX and ux500 both have some minor fixes, nothing controversial.
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
arch/arm/mach-imx/mach-mx53_ard.c: add missing iounmap
ARM: imx: iomux-v1.h: Fix build error due to __init annotation
ARM: at91: Fix at91sam9g45 and at91cap9 reset
ARM: at91: make rstc soc independent
ARM: at91: introduce AT91_SAM9_ALT_RESET to select the at91sam9 alternative reset
ARM: at91: merge at91cap9_ddrsdr.h in at91sam9_ddrsdr.h
ARM: at91: fix cap9 ddrsdr register
ARM/USB: at91/ohci-at91: rename vbus_pin_inverted to vbus_pin_active_low
USB: at91: fix clk_get error handling
ARM: at91: removal of CAP9 SoC family
ARM: at91: fix at91rm9200 soc subtype handling
mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball
mach-ux500: enable ARM errata 764369
mach-ux500: do not override outer.inv_all
mach-ux500: musb: now musb is always in OTG mode
ARM: imx6: add missing twd_clk for imx6q clock
Since commit 576d2f2525 "ARM: add
generic ioremap optimization by reusing static mappings" ioremap()
is trying to reuse existing static mapping when possible.
The condition checking boundaries of the requested and existing
mappings didn't take in-page offset into consideration though,
which lead to obscure and hard to debug problems when requested
mapping crossed end of the static one.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'fixes-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
mach-ux500: no MMC_CAP_SD_HIGHSPEED on Snowball
mach-ux500: enable ARM errata 764369
mach-ux500: do not override outer.inv_all
mach-ux500: musb: now musb is always in OTG mode
Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
when != iounmap(e)
*if (...)
{ ... when != iounmap(e)
return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Fix the following build error found when building imx_v4_v5_defconfig:
CC arch/arm/mach-imx/mach-imx27ipcam.o
In file included from arch/arm/plat-mxc/include/mach/iomux-mx27.h:23,
from arch/arm/mach-imx/mach-imx27ipcam.c:22:
arch/arm/plat-mxc/include/mach/iomux-v1.h:99: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'imx_iomuxv1_init'
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:
Testing tracer function: PASSED
Testing dynamic ftrace: PASSED
Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!
This is because while the addresses in the mcount records do not have
the zero bit set, the IP reported by the mcount call does have it set
(because it is copied from the LR). This mismatch causes the ops
filtering in ftrace_ops_list_func() to not call the relevant tracers.
Fix this by clearing the zero bit before adjusting the LR for the mcount
instruction size. Also, combine the mov+sub into a single sub
instruction.
Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Since commit 0536bdf33f (ARM: move iotable mappings within
the vmalloc region), the RealView PB11MP cannot boot anymore.
This is caused by the way the mappings are described on this
platform (define replaced by hex values for clarity):
{ /* GIC CPU interface mapping */
.virtual = IO_ADDRESS(0x1F000100),
.pfn = __phys_to_pfn(0x1F000100),
.length = SZ_4K,
.type = MT_DEVICE,
}, { /* GIC distributor mapping */
.virtual = IO_ADDRESS(0x1F001000),
.pfn = __phys_to_pfn(0x1F001000),
.length = SZ_4K,
.type = MT_DEVICE,
}
The first mapping ends up reserving two pages, and clashes with
the second one, which triggers a BUG_ON in vm_area_add_early().
In order to solve this problem, treat the MPCore private memory
region (containing the SCU, the GIC and the TWD) as a single region,
as described in the TRM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACGDJJC.html
The EB11MP is converted the same way, even if it manages to avoid
the problem.
Tested on both PB11MP and EB11MP.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Consolidate i.MX 5 platforms to be under the new shared i.MX 3/5/6 tree.
* tag 'arm-soc-imx-move' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM i.MX: Update defconfig
ARM i.MX: Merge i.MX5 support into mach-imx
ARM i.MX5: remove unnecessary includes from board files
Fix up fairly trivial conflicts due to various changes nearby in
arch/arm/{mach,plat}-imx/{Kconfig,Makefile}
Pull request had been sent to the wrong email address, but happened
before the merge window closed. I'm merging the MX 5 consolidation,
since it apparently will help the next development window and will avoid
conflicts later as per Arnd.
The Jornada SSP driver is supposed to be initialized by a
module_init() call, but it was missed at some merge point. Since
the driver mostly pass calls through it magically works anyway,
but needs to be rectified.
Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.
The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.
Problem seen on VE (Cortex A5) and Tegra.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
On v7, we use the same cache maintenance instructions for data lines
as for unified lines. This was not the case for v6, where HARVARD_CACHE
was defined to indicate the L1 cache topology.
This patch removes the erroneous compile-time check for HARVARD_CACHE in
proc-v7.S, ensuring that we perform I-side invalidation at boot.
Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>
Cc: stable <stable@vger.kernel.org>
Acked-by: Catalin Marinas <Catalin.Marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The merging of commits 1b6ba46b ("ARM: LPAE: MMU setup for the 3-level
page table format") and b4244738 ("ARM: 7202/1: Add Cortex-A7 proc info")
during the merge window ended up putting the Cortex-A7 proc_info into a
code block guarded by !CONFIG_ARM_LPAE. This makes Cortex-A7 platforms
unbootable when LPAE is enabled.
This patch moves the proc_info structure for Cortex-A7 outside of the
guarded block.
Cc: Pawel Moll <pawel.moll@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
It turns out that the logical CPU mapping is useful even when !CONFIG_SMP
for manipulation of devices like interrupt and power controllers when
running a UP kernel on a CPU other than 0. This can happen when kexecing
a UP image from an SMP kernel.
In the future, multi-cluster systems running AMP configurations will
require something similar for mapping cluster IDs, so it makes sense to
decouple this logic in preparation for this support.
Acked-by: Yang Bai <hamo.by@gmail.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.
Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The exception fixup table is currently aligned to a 32-byte boundary.
Whilst this won't cause any problems, the exception_table_entry
structures contain only a pair of unsigned longs, so 4-byte alignment
is all that is required. If the table was walked from start to end,
cacheline alignment may bring some performance benefits, but since a
binary search is used, the access pattern is random and will not benefit
from a stricter alignment.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The linker script assumes a cacheline size of 32 bytes when aligning
the .data..cacheline_aligned and .data..percpu sections.
This patch updates the script to use L1_CACHE_BYTES, which should be set
to 64 on platforms that require it.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This reverts commit 5dd7bf59e0.
Conflicts:
scripts/mod/file2alias.c
This change is wrong on many levels. First and foremost, it causes a
regression. On boot on Assabet, which this patch gives a codec id of
'ucb1x00', it gives:
ucb1x00 ID not found: 1005
0x1005 is a valid ID for the UCB1300 device.
Secondly, this patch is way over the top in terms of complexity. The
only device which has been seen to be connected with this MCP code is
the UCB1x00 (UCB1200, UCB1300 etc) devices, and they all use the same
driver. Adding a match table, requiring the codec string to match the
hardware ID read out of the ID register, etc is completely over the top
when we can just read the hardware ID register.
As on the other sam9 we need to cleanly shutdown the DDRAM before rebooting.
On those SoC the SDRAM/DDRAM controller is different. So, the assembly code
ends up being not cleanly combined with previous at91sam9_alt_restart function.
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
