ARM: 7493/1: use generic unaligned.h
This moves ARM over to the asm-generic/unaligned.h header. This has the
benefit of better code generated especially for ARMv7 on gcc 4.7+
compilers.

As Arnd Bergmann, points out: The asm-generic version uses the struct
version for native-endian unaligned access and the byteshift version
for the opposite endianess. The current ARM version however uses the
byteshift implementation for both.

Thanks to Nicolas Pitre for the excellent analysis:

Test case:

int foo (int *x) { return get_unaligned(x); }
long long bar (long long *x) { return get_unaligned(x); }

With the current ARM version:

foo:
ldrbr3, [r0, #2]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrbr1, [r0, #1]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
ldrbr2, [r0, #0]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
movr3, r3, asl #16@ tmp154, MEM[(const u8 *)x_1(D) + 2B],
ldrbr0, [r0, #3]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orrr3, r3, r1, asl #8@, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
orrr3, r3, r2@ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
orrr0, r3, r0, asl #24@,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
bxlr@

bar:
movr2, #0@ tmp184,
ldrbr5, [r0, #6]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
ldrbr4, [r0, #5]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
ldrbip, [r0, #2]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
ldrbr1, [r0, #4]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
movr5, r5, asl #16@ tmp175, MEM[(const u8 *)x_1(D) + 6B],
ldrbr7, [r0, #1]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
orrr5, r5, r4, asl #8@, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
ldrbr6, [r0, #7]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
orrr5, r5, r1@ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
ldrbr4, [r0, #0]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
movip, ip, asl #16@ tmp188, MEM[(const u8 *)x_1(D) + 2B],
ldrbr1, [r0, #3]@ zero_extendqisi2@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
orrip, ip, r7, asl #8@, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
orrr3, r5, r6, asl #24@,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
orrip, ip, r4@ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
orrip, ip, r1, asl #24@, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
movr1, r3@,
orrr0, r2, ipc/@ tmp171, tmp184, tmp194
bxlr

In both cases the code is slightly suboptimal.  One may wonder why
wasting r2 with the constant 0 in the second case for example.  And all
the mov's could be folded in subsequent orr's, etc.

Now with the asm-generic version:

foo:
ldrr0, [r0, #0]@ unaligned@,* x
bxlr@

bar:
movr3, r0@ x, x
ldrr0, [r0, #0]@ unaligned@,* x
ldrr1, [r3, #4]@ unaligned@,
bxlr@

This is way better of course, but only because this was compiled for
ARMv7. In this case the compiler knows that the hardware can do
unaligned word access.  This isn't that obvious for foo(), but if we
remove the get_unaligned() from bar as follows:

long long bar (long long *x) {return *x; }

then the resulting code is:

bar:
ldmiar0, {r0, r1}@ x,,
bxlr@

So this proves that the presumed aligned vs unaligned cases does have
influence on the instructions the compiler may use and that the above
unaligned code results are not just an accident.

Still... this isn't fully conclusive without at least looking at the
resulting assembly fron a pre ARMv6 compilation.  Let's see with an
ARMv5 target:

foo:
ldrbr3, [r0, #0]@ zero_extendqisi2@ tmp139,* x
ldrbr1, [r0, #1]@ zero_extendqisi2@ tmp140,
ldrbr2, [r0, #2]@ zero_extendqisi2@ tmp143,
ldrbr0, [r0, #3]@ zero_extendqisi2@ tmp146,
orrr3, r3, r1, asl #8@, tmp142, tmp139, tmp140,
orrr3, r3, r2, asl #16@, tmp145, tmp142, tmp143,
orrr0, r3, r0, asl #24@,, tmp145, tmp146,
bxlr

bar:
ldrbr2, [r0, #0]@ zero_e
ldrbr7,

ldrbr6, [r0, #5]@ zero_extendqisi2@ tmp150,
ldrbr5, [r0, #2]@ ze
ldrbr4, [r0, #6]@ zero_extendqisi2@ tmp153,
ldrbr1, [r0, #7]@ z
ldrbip, [r0, #3]@ zero_extendqisi2@ tmp146,
orrr2, r2, r7, asl #8@, tmp142, tmp139, tmp140,
orrr3, r3, r6, asl #8@, tmp152, tmp149, tmp150,
orrr2, r2, r5, asl #16@, tmp145, tmp142, tmp143,
orrr3, r3, r4, asl #16@, tmp155, tmp152, tmp153,
orrr0, r2, ip, asl

Comp
couldn't do much better if I were to hand code it myself.

Signed-off-by: Rob Herring <rob.herring
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-el
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

https://github.com/faux123/jflte_xxx/commit/54c6d63215d13bd0c02f85514fd9465bfde27006
ARM: 7492/1: add strstr declaration for decompressors

With the generic unaligned.h, more kernel headers get pulled in including
dynamic_debug.h which needs strstr. As it is not really used, we only need
a declaration here.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7592/1: nommu: prevent generation of kernel unaligned memory accesses

Recent ARMv7 toolchains assume that unaligned memory accesses will not
fault and will instead be handled by the processor.

For the nommu case (without an MPU), memory will be treated as
strongly-ordered and therefore unaligned accesses may fault regardless
of the SCTLR.A setting.

This patch passes -mno-unaligned-access to GCC when compiling for nommu
targets, preventing the generation of unaligned memory access in the
kernel.

Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7593/1: nommu: do not enable DCACHE_WORD_ACCESS when
hrtimer: Consider preemption when migrating hrtimer cpu_bases

Date	Wed, 10 Apr 2013 14:07:47 -0700

When switching to a new cpu_base in switch_hrtimer_base(), we
briefly enable preemption by unlocking the cpu_base lock in two
places. During this interval it's possible for the running thread
to be swapped to a different CPU.

Consider the following example:

CPU #0                                 CPU #1
----                                   ----
hrtimer_start()                        ...
 lock_hrtimer_base()
 switch_hrtimer_base()
  this_cpu = 0;
  target_cpu_base = 0;
  raw_spin_unlock(&cpu_base->lock)
<migrate to CPU 1>
...                                    this_cpu == 0
                                       cpu == this_cpu
                                       timer->base = CPU #0
                                       timer->base != LOCAL_CPU
Since the cached this_cpu is no longer accurate, we'll skip the
hrtimer_check_target() check. Once we eventually go to program
the hardware, we'll decide not to do so since it knows the real
CPU that we're running on is not the same as the chosen base. As
a consequence, we may end up missing the hrtimer's deadline.

Fix this by updating the local CPU number each time we retake a
cpu_base lock in switch_hrtimer_base().

Another possibility is to disable preemption across the whole of
switch_hrtimer_base. This looks suboptimal since preemption
would be disabled while waiting for lock(s).

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>
hrtimer: Prevent enqueue of hrtimer on dead CPU

Date	Wed, 10 Apr 2013 14:07:48 -0700

When switching the hrtimer cpu_base, we briefly allow for
preemption to become enabled by unlocking the cpu_base lock.
During this time, the CPU corresponding to the new cpu_base
that was selected may in fact go offline. In this scenario, the
hrtimer is enqueued to a CPU that's not online, and therefore
it never fires.

As an example, consider this example:

CPU #0                          CPU #1
----                            ----
...                             hrtimer_start()
                                 lock_hrtimer_base()
                                 switch_hrtimer_base()
                                  cpu = hrtimer_get_target() -> 1
                                  spin_unlock(&cpu_base->lock)
                                <migrate thread to CPU #0>
                                <offline>
spin_lock(&new_base->lock)
this_cpu = 0
cpu != this_cpu
enqueue_hrtimer(cpu_base #1)
To prevent this scenario, verify that the CPU corresponding to
the new cpu_base is indeed online before selecting it in
hrtimer_switch_base(). If it's not online, fallback to using the
base of the current CPU.

Signed-off-by: Michael Bohan <mbohan@codeaurora.org>