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

ARM: 7643/1: sched: correct update_sched_clock()

2013-02-28T14:59:04+00:00

commit 7c4e9ced424be4d36df6a3e3825763e97ee97607 upstream.

If we want load epoch_cyc and epoch_ns atomically,
we should update epoch_cyc_copy first of all.
This notify reader that updating is in progress.

If we update epoch_cyc first like as current implementation,
there is subtle error case.
Look at the below example.


cyc = 9
ns = 900
cyc_copy = 9

== CASE 1 ==
           
                           write cyc = 10
read cyc = 10
read ns = 900
                           write ns = 1000
                           write cyc_copy = 10
read cyc_copy = 10

output = (10, 900)

== CASE 2 ==
           
read cyc = 9
                           write cyc = 10
                           write ns = 1000
read ns = 1000
read cyc_copy = 9
                           write cyc_copy = 10
output = (9, 1000)

If atomic read is ensured, output should be (9, 900) or (10, 1000).
But, output in example case are not.

So, change updating sequence in order to correct this problem.

Signed-off-by: Joonsoo Kim 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: samsung: fix assembly syntax for new gas

2013-02-28T14:59:04+00:00

commit 2815774bb38445006074e16251b9ef5123bdc616 upstream.

Recent assembler versions complain about extraneous
whitespace inside [] brackets. This fixes all of
these instances for the samsung platforms. We should
backport this to all kernels that might need to
be built with new binutils.

arch/arm/kernel/entry-armv.S: Assembler messages:
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]'
arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]'
arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]'
arch/arm/kernel/debug.S: Assembler messages:
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages:
arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages:
arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]'
arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]'
arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]'

Signed-off-by: Arnd Bergmann 
Acked-by: Kukjin Kim 
Cc: Ben Dooks 
Signed-off-by: Greg Kroah-Hartman

ARM: PXA3xx: program the CSMSADRCFG register

2013-02-28T14:59:04+00:00

commit d107a204154ddd79339203c2deeb7433f0cf6777 upstream.

The Chip Select Configuration Register must be programmed to 0x2 in
order to achieve the correct behavior of the Static Memory Controller.

Without this patch devices wired to DFI and accessed through SMC cannot
be accessed after resume from S2.

Do not rely on the boot loader to program the CSMSADRCFG register by
programming it in the kernel smemc module.

Signed-off-by: Igor Grinberg 
Acked-by: Eric Miao 
Signed-off-by: Haojian Zhuang 
Signed-off-by: Greg Kroah-Hartman

ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone

2013-02-04T00:24:40+00:00

commit 568dca15aa2a0f4ddee255894ec393a159f13147 upstream.

Patrik Kluba reports that the preempt count becomes invalid due
to the preempt_enable() call being unbalanced with a
preempt_disable() call in the vfp assembly routines. This happens
because preempt_enable() and preempt_disable() update preempt
counts under PREEMPT_COUNT=y but the vfp assembly routines do so
under PREEMPT=y. In a configuration where PREEMPT=n and
DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable()
call in VFP_bounce() keeps subtracting from the preempt count
until it goes negative.

Fix this by always using PREEMPT_COUNT to decided when to update
preempt counts in the ARM assembly code.

Signed-off-by: Stephen Boyd 
Reported-by: Patrik Kluba 
Tested-by: Patrik Kluba 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: at91: rm9200: remake the BGA as default version

2013-02-04T00:24:40+00:00

commit 36224d0fe0f34cdde66a381708853ebadeac799c upstream.

Make BGA as the default version as we are supposed to just have
to specify when we use the PQFP version.

Issue was existing since commit:
3e90772 (ARM: at91: fix at91rm9200 soc subtype handling).

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman

ARM: DMA: Fix struct page iterator in dma_cache_maint() to work with sparsemem

2013-02-04T00:24:40+00:00

commit 15653371c67c3fbe359ae37b720639dd4c7b42c5 upstream.

Subhash Jadavani reported this partial backtrace:
  Now consider this call stack from MMC block driver (this is on the ARMv7
  based board):

  [] (v7_dma_inv_range+0x30/0x48) from [] (dma_cache_maint_page+0x1c4/0x24c)
  [] (dma_cache_maint_page+0x1c4/0x24c) from [] (___dma_page_cpu_to_dev+0x14/0x1c)
  [] (___dma_page_cpu_to_dev+0x14/0x1c) from [] (dma_map_sg+0x3c/0x114)

This is caused by incrementing the struct page pointer, and running off
the end of the sparsemem page array.  Fix this by incrementing by pfn
instead, and convert the pfn to a struct page.

Suggested-by: James Bottomley 
Tested-by: Subhash Jadavani 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ALSA: pxa27x: fix ac97 warm reset

2013-01-17T16:50:55+00:00

commit 3b4bc7bccc7857274705b05cf81a0c72cfd0b0dd upstream.

This patch fixes some code that implements a work-around to a hardware bug in
the ac97 controller on the pxa27x.  A bug in the controller's warm reset
functionality requires that the mfp used by the controller as the AC97_nRESET
line be temporarily reconfigured as a generic output gpio (AF0) and manually
held high for the duration of the warm reset cycle.  This is what was done in
the original code, but it was broken long ago by commit fb1bf8cd
    ([ARM] pxa: introduce processor specific pxa27x_assert_ac97reset())
which changed the mfp to a GPIO input instead of a high output.

The fix requires the ac97 controller to obtain the gpio via gpio_request_one(),
with arguments that configure the gpio as an output initially driven high.

Tested on a palm treo 680 machine.  Reportedly, this broken code only prevents a
warm reset on hardware that lacks a pull-up on the line, which appears to be the
case for me.

Signed-off-by: Mike Dunn 
Signed-off-by: Igor Grinberg 
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

ARM: 7607/1: realview: fix private peripheral memory base for EB rev. B boards

2013-01-11T17:07:16+00:00

commit e6ee4b2b57a8e0d8e551031173de080b338d3969 upstream.

Commit 34ae6c96a6a7 ("ARM: 7298/1: realview: fix mapping of MPCore
private memory region") accidentally broke the definition for the base
address of the private peripheral region on revision B Realview-EB
boards.

This patch uses the correct address for REALVIEW_EB11MP_PRIV_MEM_BASE.

Acked-by: Marc Zyngier 
Tested-by: Florian Fainelli 
Signed-off-by: Will Deacon 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: missing ->mmap_sem around find_vma() in swp_emulate.c

2013-01-11T17:07:16+00:00

commit 7bf9b7bef881aac820bf1f2e9951a17b09bd7e04 upstream.

find_vma() is *not* safe when somebody else is removing vmas.  Not just
the return value might get bogus just as you are getting it (this instance
doesn't try to dereference the resulting vma), the search itself can get
buggered in rather spectacular ways.  IOW, ->mmap_sem really, really is
not optional here.

Signed-off-by: Al Viro 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: mm: use pteval_t to represent page protection values

2013-01-11T17:07:16+00:00

commit 864aa04cd02979c2c755cb28b5f4fe56039171c0 upstream.

When updating the page protection map after calculating the user_pgprot
value, the base protection map is temporarily stored in an unsigned long
type, causing truncation of the protection bits when LPAE is enabled.
This effectively means that calls to mprotect() will corrupt the upper
page attributes, clearing the XN bit unconditionally.

This patch uses pteval_t to store the intermediate protection values,
preserving the upper bits for 64-bit descriptors.

Acked-by: Nicolas Pitre 
Acked-by: Catalin Marinas 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman