1. 16 9月, 2012 2 次提交
    • R
      ARM: Fix build warning in arch/arm/mm/alignment.c · a761cebf
      Russell King 提交于
      Fix this harmless build warning:
      
      arch/arm/mm/alignment.c: In function 'do_alignment':
      arch/arm/mm/alignment.c:749:21: warning: 'offset.un' may be used uninitialized in this function
      
      This is caused by the compiler not being able to properly analyse the
      code to prove that offset.un is assigned in every case.  The case it
      struggles with is where we assign the handler from the Thumb parser -
      do_alignment_t32_to_handler().  As this starts by zeroing this variable
      via a pointer, move it into the calling function.  This fixes the
      warning.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a761cebf
    • R
      ARM: Add irqtime accounting support · a42c3629
      Russell King 提交于
      Add support for irq time accounting.  This commit prepares ARM by adding
      the call to enable_sched_clock_irqtime() in sched_clock().  We introduce
      a new kernel parameter - irqtime - which takes an integer.  -1 for auto,
      0 for disabled, and 1 for enabled.  Auto mode selects IRQ accounting if
      we have a sched_clock() tick rate greater than 1MHz.
      
      Frederic Weisbecker is working on a patch set which moves the
      IRQ_TIME_ACCOUNTING into arch/, so that part is not incorporated into
      this patch; this facility becomes available on ARM only when both this
      patch and Frederic's patches are merged.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a42c3629
  2. 02 9月, 2012 1 次提交
  3. 25 8月, 2012 7 次提交
    • W
      ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors · 195bbcac
      Will Deacon 提交于
      Data aborts taken to hyp mode do not provide a valid instruction
      syndrome field in the HSR if the faulting instruction is a memory
      access using a writeback addressing mode.
      
      For hypervisors emulating MMIO accesses to virtual peripherals, taking
      such an exception requires disassembling the faulting instruction in
      order to determine the behaviour of the access. Since this requires
      manually walking the two stages of translation, the world must be
      stopped to prevent races against page aging in the guest, where the
      first-stage translation is invalidated after the hypervisor has
      translated to an IPA and the physical page is reused for something else.
      
      This patch avoids taking this heavy performance penalty when running
      Linux as a guest by ensuring that our I/O accessors do not make use of
      writeback addressing modes.
      
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      195bbcac
    • S
    • W
      ARM: 7495/1: mutex: use generic atomic_dec-based implementation for ARMv6+ · 08928e7a
      Will Deacon 提交于
      Commit a76d7bd9 ("ARM: 7467/1: mutex: use generic xchg-based
      implementation for ARMv6+") removed the barrier-less, ARM-specific
      mutex implementation in favour of the generic xchg-based code.
      
      Since then, a bug was uncovered in the xchg code when running on SMP
      platforms, due to interactions between the locking paths and the
      MUTEX_SPIN_ON_OWNER code. This was fixed in 0bce9c46 ("mutex: place
      lock in contended state after fastpath_lock failure"), however, the
      atomic_dec-based mutex algorithm is now marginally more efficient for
      ARM (~0.5% improvement in hackbench scores on dual A15).
      
      This patch moves ARMv6+ platforms to the atomic_dec-based mutex code.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      08928e7a
    • R
      ARM: 7494/1: use generic termios.h · e780c452
      Rob Herring 提交于
      As pointed out by Arnd Bergmann, this fixes a couple of issues but will
      increase code size:
      
      The original macro user_termio_to_kernel_termios was not endian safe. It
      used an unsigned short ptr to access the low bits in a 32-bit word.
      
      Both user_termio_to_kernel_termios and kernel_termios_to_user_termio are
      missing error checking on put_user/get_user and copy_to/from_user.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e780c452
    • R
      ARM: 7493/1: use generic unaligned.h · d25c881a
      Rob Herring 提交于
      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:
      	ldrb	r3, [r0, #2]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
      	ldrb	r1, [r0, #1]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
      	ldrb	r2, [r0, #0]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
      	mov	r3, r3, asl #16	@ tmp154, MEM[(const u8 *)x_1(D) + 2B],
      	ldrb	r0, [r0, #3]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
      	orr	r3, r3, r1, asl #8	@, tmp155, tmp154, MEM[(const u8 *)x_1(D) + 1B],
      	orr	r3, r3, r2	@ tmp157, tmp155, MEM[(const u8 *)x_1(D)]
      	orr	r0, r3, r0, asl #24	@,, tmp157, MEM[(const u8 *)x_1(D) + 3B],
      	bx	lr	@
      
      bar:
      	stmfd	sp!, {r4, r5, r6, r7}	@,
      	mov	r2, #0	@ tmp184,
      	ldrb	r5, [r0, #6]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 6B], MEM[(const u8 *)x_1(D) + 6B]
      	ldrb	r4, [r0, #5]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 5B], MEM[(const u8 *)x_1(D) + 5B]
      	ldrb	ip, [r0, #2]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 2B], MEM[(const u8 *)x_1(D) + 2B]
      	ldrb	r1, [r0, #4]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 4B], MEM[(const u8 *)x_1(D) + 4B]
      	mov	r5, r5, asl #16	@ tmp175, MEM[(const u8 *)x_1(D) + 6B],
      	ldrb	r7, [r0, #1]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 1B], MEM[(const u8 *)x_1(D) + 1B]
      	orr	r5, r5, r4, asl #8	@, tmp176, tmp175, MEM[(const u8 *)x_1(D) + 5B],
      	ldrb	r6, [r0, #7]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 7B], MEM[(const u8 *)x_1(D) + 7B]
      	orr	r5, r5, r1	@ tmp178, tmp176, MEM[(const u8 *)x_1(D) + 4B]
      	ldrb	r4, [r0, #0]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D)], MEM[(const u8 *)x_1(D)]
      	mov	ip, ip, asl #16	@ tmp188, MEM[(const u8 *)x_1(D) + 2B],
      	ldrb	r1, [r0, #3]	@ zero_extendqisi2	@ MEM[(const u8 *)x_1(D) + 3B], MEM[(const u8 *)x_1(D) + 3B]
      	orr	ip, ip, r7, asl #8	@, tmp189, tmp188, MEM[(const u8 *)x_1(D) + 1B],
      	orr	r3, r5, r6, asl #24	@,, tmp178, MEM[(const u8 *)x_1(D) + 7B],
      	orr	ip, ip, r4	@ tmp191, tmp189, MEM[(const u8 *)x_1(D)]
      	orr	ip, ip, r1, asl #24	@, tmp194, tmp191, MEM[(const u8 *)x_1(D) + 3B],
      	mov	r1, r3	@,
      	orr	r0, r2, ip	@ tmp171, tmp184, tmp194
      	ldmfd	sp!, {r4, r5, r6, r7}
      	bx	lr
      
      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:
      	ldr	r0, [r0, #0]	@ unaligned	@,* x
      	bx	lr	@
      
      bar:
      	mov	r3, r0	@ x, x
      	ldr	r0, [r0, #0]	@ unaligned	@,* x
      	ldr	r1, [r3, #4]	@ unaligned	@,
      	bx	lr	@
      
      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:
      	ldmia	r0, {r0, r1}	@ x,,
      	bx	lr	@
      
      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:
      	ldrb	r3, [r0, #0]	@ zero_extendqisi2	@ tmp139,* x
      	ldrb	r1, [r0, #1]	@ zero_extendqisi2	@ tmp140,
      	ldrb	r2, [r0, #2]	@ zero_extendqisi2	@ tmp143,
      	ldrb	r0, [r0, #3]	@ zero_extendqisi2	@ tmp146,
      	orr	r3, r3, r1, asl #8	@, tmp142, tmp139, tmp140,
      	orr	r3, r3, r2, asl #16	@, tmp145, tmp142, tmp143,
      	orr	r0, r3, r0, asl #24	@,, tmp145, tmp146,
      	bx	lr	@
      
      bar:
      	stmfd	sp!, {r4, r5, r6, r7}	@,
      	ldrb	r2, [r0, #0]	@ zero_extendqisi2	@ tmp139,* x
      	ldrb	r7, [r0, #1]	@ zero_extendqisi2	@ tmp140,
      	ldrb	r3, [r0, #4]	@ zero_extendqisi2	@ tmp149,
      	ldrb	r6, [r0, #5]	@ zero_extendqisi2	@ tmp150,
      	ldrb	r5, [r0, #2]	@ zero_extendqisi2	@ tmp143,
      	ldrb	r4, [r0, #6]	@ zero_extendqisi2	@ tmp153,
      	ldrb	r1, [r0, #7]	@ zero_extendqisi2	@ tmp156,
      	ldrb	ip, [r0, #3]	@ zero_extendqisi2	@ tmp146,
      	orr	r2, r2, r7, asl #8	@, tmp142, tmp139, tmp140,
      	orr	r3, r3, r6, asl #8	@, tmp152, tmp149, tmp150,
      	orr	r2, r2, r5, asl #16	@, tmp145, tmp142, tmp143,
      	orr	r3, r3, r4, asl #16	@, tmp155, tmp152, tmp153,
      	orr	r0, r2, ip, asl #24	@,, tmp145, tmp146,
      	orr	r1, r3, r1, asl #24	@,, tmp155, tmp156,
      	ldmfd	sp!, {r4, r5, r6, r7}
      	bx	lr
      
      Compared to the initial results, this is really nicely optimized and I
      couldn't do much better if I were to hand code it myself.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d25c881a
    • R
      ARM: 7492/1: add strstr declaration for decompressors · ef1c2096
      Rob Herring 提交于
      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: NRob Herring <rob.herring@calxeda.com>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ef1c2096
    • R
      ARM: 7491/1: use generic version of identical asm headers · 4a8052d8
      Rob Herring 提交于
      Inspired by the AArgh64 claim that it should be separate from ARM and one
      reason was being able to use more asm-generic headers. Doing a diff of
      arch/arm/include/asm and include/asm-generic there are numerous asm
      headers which are functionally identical to their asm-generic counterparts.
      Delete the ARM version and use the generic ones.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4a8052d8
  4. 13 8月, 2012 1 次提交
  5. 11 8月, 2012 1 次提交
  6. 03 8月, 2012 5 次提交
  7. 02 8月, 2012 10 次提交
  8. 01 8月, 2012 13 次提交