linux-toradex.git/arch/arm, branch v3.0.99

ARM: PCI: versatile: Fix SMAP register offsets

2013-09-26T23:52:46+00:00

commit 99f2b130370b904ca5300079243fdbcafa2c708b upstream.

The SMAP register offsets in the versatile PCI controller code were
all off by four.  (This didn't have any observable bad effects
because on this board PHYS_OFFSET is zero, and (a) writing zero to
the flags register at offset 0x10 has no effect and (b) the reset
value of the SMAP register is zero anyway, so failing to write SMAP2
didn't matter.)

Signed-off-by: Peter Maydell 
Reviewed-by: Linus Walleij 
Signed-off-by: Kevin Hilman 
Signed-off-by: Greg Kroah-Hartman

ARM: 7080/1: l2x0: make sure I&D are not locked down on init

2013-08-20T15:21:01+00:00

commit bac7e6ecf60933b68af910eb4c83a775a8b20b19 upstream.

Fighting unfixed U-Boots and other beasts that may the cache in
a locked-down state when starting the kernel, we make sure to
disable all cache lock-down when initializing the l2x0 so we
are in a known state.

Reviewed-by: Santosh Shilimkar 
Reported-by: Jan Rinze 
Cc: Srinidhi Kasagar 
Cc: Rabin Vincent 
Cc: Adrian Bunk 
Cc: Rob Herring 
Cc: Catalin Marinas 
Cc: Will Deacon 
Tested-by: Robert Marklund 
Signed-off-by: Linus Walleij 
Signed-off-by: Russell King 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

ARM: 7765/1: perf: Record the user-mode PC in the call chain.

2013-07-22T01:14:41+00:00

commit c5f927a6f62196226915f12194c9d0df4e2210d7 upstream.

With this change, we no longer lose the innermost entry in the user-mode
part of the call chain.  See also the x86 port, which includes the ip.

It's possible to partially work around this problem by post-processing
the data to use the PERF_SAMPLE_IP value, but this works only if the CPU
wasn't in the kernel when the sample was taken.

Signed-off-by: Jed Davis 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

Kirkwood: Enable PCIe port 1 on QNAP TS-11x/TS-21x

2013-06-07T19:46:36+00:00

commit 99e11334dcb846f9b76fb808196c7f47aa83abb3 upstream.

Enable KW_PCIE1 on QNAP TS-11x/TS-21x devices as newer revisions
(rev 1.3) have a USB 3.0 chip from Etron on PCIe port 1.  Thanks
to Marek Vasut for identifying this issue!

Signed-off-by: Martin Michlmayr 
Tested-by: Marek Vasut 
Acked-by: Andrew Lunn 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: plat-orion: Fix num_resources and id for ge10 and ge11

2013-06-07T19:46:34+00:00

commit 2b8b2797142c7951e635c6eec5d1705ee9bc45c5 upstream.

When platform data were moved from arch/arm/mach-mv78xx0/common.c to
arch/arm/plat-orion/common.c with the commit "7e3819d ARM: orion:
Consolidate ethernet platform data", there were few typo made on
gigabit Ethernet interface ge10 and ge11. This commit writes back
their initial value, which allows to use this interfaces again.

Signed-off-by: Gregory CLEMENT 
Acked-by: Andrew Lunn 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: OMAP: RX-51: change probe order of touchscreen and panel SPI devices

2013-05-19T17:04:36+00:00

commit e65f131a14726e5f1b880a528271a52428e5b3a5 upstream.

Commit 9fdca9df (spi: omap2-mcspi: convert to module_platform_driver)
broke the SPI display/panel driver probe on RX-51/N900. The exact cause is
not fully understood, but it seems to be related to the probe order. SPI
communication to the panel driver (spi1.2) fails unless the touchscreen
(spi1.0) has been probed/initialized before. When the omap2-mcspi driver
was converted to a platform driver, it resulted in that the devices are
probed immediately after the board registers them in the order they are
listed in the board file.

Fix the issue by moving the touchscreen before the panel in the SPI
device list.

The patch fixes the following failure:

[    1.260955] acx565akm spi1.2: invalid display ID
[    1.265899] panel-acx565akm display0: acx_panel_probe panel detect error
[    1.273071] omapdss CORE error: driver probe failed: -19

Tested-by: Sebastian Reichel 
Signed-off-by: Aaro Koskinen 
Cc: Pali Rohár 
Cc: Joni Lapilainen 
Cc: Tomi Valkeinen 
Cc: Felipe Balbi 
Signed-off-by: Tony Lindgren 
Signed-off-by: Greg Kroah-Hartman

ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon

2013-04-26T04:23:48+00:00

commit cd272d1ea71583170e95dde02c76166c7f9017e6 upstream.

On Feroceon the L2 cache becomes non-coherent with the CPU
when the L1 caches are disabled. Thus the L2 needs to be invalidated
after both L1 caches are disabled.

On kexec before the starting the code for relocation the kernel,
the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon),
but after L2 cache is never invalidated, because inv_all is not set
in cache-feroceon-l2.c.
So kernel relocation and decompression may has (and usually has) errors.
Setting the function enables L2 invalidation and fixes the issue.

Signed-off-by: Illia Ragozin 
Acked-by: Jason Cooper 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer

2013-04-05T17:16:35+00:00

Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.

flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined.  Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.

Signed-off-by: Ben Hutchings 
Cc: Al Viro 
Signed-off-by: Greg Kroah-Hartman

ARM: fix scheduling while atomic warning in alignment handling code

2013-03-14T18:32:04+00:00

commit b255188f90e2bade1bd11a986dd1ca4861869f4d upstream.

Paolo Pisati reports that IPv6 triggers this warning:

BUG: scheduling while atomic: swapper/0/0/0x40000100
Modules linked in:
[] (unwind_backtrace+0x0/0xf0) from [] (__schedule_bug+0x48/0x5c)
[] (__schedule_bug+0x48/0x5c) from [] (__schedule+0x700/0x740)
[] (__schedule+0x700/0x740) from [] (__cond_resched+0x24/0x34)
[] (__cond_resched+0x24/0x34) from [] (_cond_resched+0x3c/0x44)
[] (_cond_resched+0x3c/0x44) from [] (do_alignment+0x178/0x78c)
[] (do_alignment+0x178/0x78c) from [] (do_DataAbort+0x34/0x98)
[] (do_DataAbort+0x34/0x98) from [] (__dabt_svc+0x40/0x60)
Exception stack(0xc0763d70 to 0xc0763db8)
3d60:                                     e97e805e e97e806e 2c000000 11000000
3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c
3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff
[] (__dabt_svc+0x40/0x60) from [] (__csum_ipv6_magic+0x8/0xc8)

Fix this by using probe_kernel_address() stead of __get_user().

Reported-by: Paolo Pisati 
Tested-by: Paolo Pisati 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: VFP: fix emulation of second VFP instruction

2013-03-14T18:32:03+00:00

commit 5e4ba617c1b584b2e376f31a63bd4e734109318a upstream.

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Reported-by: Martin Storsjö 
Tested-by: Martin Storsjö 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman