1. 03 May, 2013 4 commits
    • Arnd Bergmann's avatar
      ARM: SPEAr: conditionalize l2x0 support · 6343b05f
      Arnd Bergmann authored
      
      
      If the cache controller implementation is disabled at build time,
      we must not call any functions related to it.
      
      arch/arm/mach-spear/built-in.o: In function `spear13xx_l2x0_init':
      arch/arm/mach-spear/spear13xx.c:47: undefined reference to `l2x0_init'
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarViresh Kumar <viresh.linux@gmail.com>
      6343b05f
    • Arnd Bergmann's avatar
      ARM: imx: build CPU suspend code only when needed · cb48389b
      Arnd Bergmann authored
      
      
      The ARM CPU suspend function has its own configuration symbol,
      which we need to use for conditionalizing any code calling into
      it as well.
      
      arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
      /git/arm-soc/arch/arm/mach-imx/headsmp.S:57: undefined
       reference to `cpu_resume'
      
      Cc: Sascha Hauer <kernel@pengutronix.de>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      cb48389b
    • Arnd Bergmann's avatar
      ARM: OMAP: build SMP code only for OMAP4/5 · 572b16db
      Arnd Bergmann authored
      
      
      The OMAP platform code assumes that SMP is only ever enabled when
      CONFIG_ARCH_OMAP4 or CONFIG_SOC_OMAP5 is enabled, which is not
      necessarirly true in a multiplatform configuration.
      
      arch/arm/mach-omap2/built-in.o: In function `omap4_smp_prepare_cpus':
       :(.init.text+0x413c): undefined reference to `omap_get_wakeupgen_base'
       :(.init.text+0x415c): undefined reference to `omap_secure_apis_support'
      arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
       :(.cpuinit.text+0x28): undefined reference to `omap_get_wakeupgen_base'
       :(.cpuinit.text+0x3c): undefined reference to `omap_secure_apis_support'
      arch/arm/mach-omap2/built-in.o: In function `omap4_cpu_die':
       :(.ref.text+0x8): undefined reference to `omap_get_wakeupgen_base'
       :(.ref.text+0x10): undefined reference to `omap_secure_apis_support'
       :(.ref.text+0x4c): undefined reference to `omap4_hotplug_cpu'
       :(.ref.text+0x50): undefined reference to `omap_secure_apis_support'
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      572b16db
    • Arnd Bergmann's avatar
      ARM: tegra: Tegra114 needs CPU_FREQ_TABLE · 63cc8467
      Arnd Bergmann authored
      
      
      Like the other Tegra SoCs using the same cpufreq driver, we
      have to enable CPU_FREQ_TABLE for this one.
      
      drivers/built-in.o: In function `tegra_cpu_exit':
       drivers/cpufreq/tegra-cpufreq.c:237: undefined reference to
       `cpufreq_frequency_table_cpuinfo'
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Hiroshi Doyu <hdoyu@nvidia.com>
      63cc8467
  2. 29 Apr, 2013 2 commits
    • Arnd Bergmann's avatar
      ARM: default machine descriptor for multiplatform · 883a106b
      Arnd Bergmann authored
      
      
      Since we now have default implementations for init_time and init_irq,
      the init_machine callback is the only one that is not yet optional,
      but since simple DT based platforms all have the same
      of_platform_populate function call in there, we can consolidate them
      as well, and then actually boot with a completely empty machine_desc.
      Unofortunately we cannot just default to an empty init_machine: We
      cannot call of_platform_populate before init_machine because that
      does not work in case of auxdata, and we cannot call it after
      init_machine either because the machine might need to run code
      after adding the devices.
      
      To take the final step, this adds support for booting without defining
      any machine_desc whatsoever.
      
      For the case that CONFIG_MULTIPLATFORM is enabled, it adds a
      global machine descriptor that never matches any machine but is
      used as a fallback if nothing else matches. We assume that without
      CONFIG_MULTIPLATFORM, we only want to boot on the systems that the kernel
      is built for, so we still retain the build-time warning for missing
      machine descriptors and the run-time warning when the platform does not
      match in that case.
      
      In the case that we run on a multiplatform kernel and the machine
      provides a fully populated device tree, we attempt to keep booting,
      hoping that no machine specific callbacks are necessary.
      
      Finally, this also removes the misguided "select ARCH_VEXPRESS" that
      was only added to avoid a build error for allnoconfig kernels.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Cc: "Russell King - ARM Linux" <linux@arm.linux.org.uk>
      Cc: Rob Herring <robherring2@gmail.com>
      883a106b
    • Olof Johansson's avatar
      ARM: dts: exynops4210: really add universal_c210 dts · 0682edaa
      Olof Johansson authored
      I fumbled when resolving a merge conflict on application of commit
      765d012c
      
       (ARM: dts: exynos4210: Add basic dts file for universal_c210
      board), and left out the dts source file. Here it is.
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      0682edaa
  3. 28 Apr, 2013 3 commits
  4. 11 Mar, 2013 1 commit
  5. 07 Mar, 2013 1 commit
    • Ivan Djelic's avatar
      ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations · 455bd4c4
      Ivan Djelic authored
      
      
      Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
      assumptions about the implementation of memset and similar functions.
      The current ARM optimized memset code does not return the value of
      its first argument, as is usually expected from standard implementations.
      
      For instance in the following function:
      
      void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
      {
      	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
      	waiter->magic = waiter;
      	INIT_LIST_HEAD(&waiter->list);
      }
      
      compiled as:
      
      800554d0 <debug_mutex_lock_common>:
      800554d0:       e92d4008        push    {r3, lr}
      800554d4:       e1a00001        mov     r0, r1
      800554d8:       e3a02010        mov     r2, #16 ; 0x10
      800554dc:       e3a01011        mov     r1, #17 ; 0x11
      800554e0:       eb04426e        bl      80165ea0 <memset>
      800554e4:       e1a03000        mov     r3, r0
      800554e8:       e583000c        str     r0, [r3, #12]
      800554ec:       e5830000        str     r0, [r3]
      800554f0:       e5830004        str     r0, [r3, #4]
      800554f4:       e8bd8008        pop     {r3, pc}
      
      GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
      register/memory corruptions.
      
      This patch fixes the return value of the assembly version of memset.
      It adds a 'mov' instruction and merges an additional load+store into
      existing load/store instructions.
      For ease of review, here is a breakdown of the patch into 4 simple steps:
      
      Step 1
      ======
      Perform the following substitutions:
      ip -> r8, then
      r0 -> ip,
      and insert 'mov ip, r0' as the first statement of the function.
      At this point, we have a memset() implementation returning the proper result,
      but corrupting r8 on some paths (the ones that were using ip).
      
      Step 2
      ======
      Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
      
      save r8:
      -       str     lr, [sp, #-4]!
      +       stmfd   sp!, {r8, lr}
      
      and restore r8 on both exit paths:
      -       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
      +       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
      (...)
              tst     r2, #16
              stmneia ip!, {r1, r3, r8, lr}
      -       ldr     lr, [sp], #4
      +       ldmfd   sp!, {r8, lr}
      
      Step 3
      ======
      Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
      
      save r8:
      -       stmfd   sp!, {r4-r7, lr}
      +       stmfd   sp!, {r4-r8, lr}
      
      and restore r8 on both exit paths:
              bgt     3b
      -       ldmeqfd sp!, {r4-r7, pc}
      +       ldmeqfd sp!, {r4-r8, pc}
      (...)
              tst     r2, #16
              stmneia ip!, {r4-r7}
      -       ldmfd   sp!, {r4-r7, lr}
      +       ldmfd   sp!, {r4-r8, lr}
      
      Step 4
      ======
      Rewrite register list "r4-r7, r8" as "r4-r8".
      Signed-off-by: default avatarIvan Djelic <ivan.djelic@parrot.com>
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarDirk Behme <dirk.behme@gmail.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      455bd4c4
  6. 06 Mar, 2013 2 commits
    • Stephen Boyd's avatar
      ARM: 7667/1: perf: Fix section mismatch on armpmu_init() · 44d6b1fc
      Stephen Boyd authored
      
      
      WARNING: vmlinux.o(.text+0xfb80): Section mismatch in reference
      from the function armpmu_register() to the function
      .init.text:armpmu_init()
      The function armpmu_register() references
      the function __init armpmu_init().
      This is often because armpmu_register lacks a __init
      annotation or the annotation of armpmu_init is wrong.
      
      Just drop the __init marking on armpmu_init() because
      armpmu_register() no longer has an __init marking.
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      44d6b1fc
    • Jonathan Austin's avatar
      ARM: 7666/1: decompressor: add -mno-single-pic-base for building the decompressor · b8083f86
      Jonathan Austin authored
      
      
      Before jumping to (position independent) C-code from the decompressor's
      assembler world we set-up the C environment. This setup currently does not
      set r9, which for arm-none-uclinux-uclibceabi toolchains is by default
      expected to be the PIC offset base register (IE should point to the
      beginning of the GOT).
      
      Currently, therefore, in order to build working kernels that use the
      decompressor it is necessary to use an arm-linux-gnueabi toolchain, or
      similar. uClinux toolchains cause a prefetch abort to occur at the beginning
      of the decompress_kernel function.
      
      This patch allows uClinux toolchains to build bootable zImages by forcing
      the -mno-single-pic-base option, which ensures that the location of the GOT
      is re-derived each time it is required, and r9 becomes free for use as a
      general purpose register.
      
      This has a small (4% in instruction terms) advantage over the alternative of
      setting r9 to point to the GOT before calling into the C-world.
      Signed-off-by: default avatarJonathan Austin <jonathan.austin@arm.com>
      Acked-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b8083f86
  7. 03 Mar, 2013 12 commits
  8. 01 Mar, 2013 1 commit
    • Russell King's avatar
      ARM: Fix broken commit 0cc41e4a corrupting kernel messages · ded3ef0f
      Russell King authored
      Commit 0cc41e4a
      
       (arch: remove direct definitions of KERN_<LEVEL>
      uses) is broken - not enough thought was put into changing:
      
      	.asciz	"string"
      
      to
      
      	.asciz	"string1" "string2"
      
      The problem is that each string gets _separately_ NUL terminated, so
      the result is a string containing:
      
      	"string1\0string2\0"
      
      rather than:
      
      	"string1string2\0"
      
      With our new printk levels, this ends up as - eg, KERN_DEBUG "string":
      
      	0x01 0x00 0x07 0x00 "string" 0x00
      
      which produces lots of \x01 in the kernel log.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      ded3ef0f
  9. 28 Feb, 2013 14 commits