1. 08 5月, 2013 1 次提交
  2. 07 5月, 2013 2 次提交
  3. 04 5月, 2013 2 次提交
    • T
      ARM: OMAP2+: Fix unmet direct dependencies for SERIAL_OMAP · eb16d332
      Tony Lindgren 提交于
      Commit 8a6201b9 (ARM: OMAP2+: Fix unmet direct dependencies for zoom
      for 8250 serial) fixed unmet direct dependencies for 8250, but failed
      to do the same for omap serial. This can cause the following warning:
      
      warning: (ARCH_OMAP2PLUS_TYPICAL) selects SERIAL_OMAP which has
      unmet direct dependencies (TTY && HAS_IOMEM && GENERIC_HARDIRQS &&
      ARCH_OMAP2PLUS).
      
      We should not select drivers, they should be selected by the
      user. Fix the issue by removing the select and adding them to
      omap2plus_defconfig instead.
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      eb16d332
    • A
      ARM: OMAP: build SMP code only for OMAP4/5 · 572b16db
      Arnd Bergmann 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NTony Lindgren <tony@atomide.com>
      572b16db
  4. 03 5月, 2013 2 次提交
    • R
      ARM: OMAP: use consistent error checking · c48cd659
      Russell King 提交于
      Consistently check errors using the usual method used in the kernel
      for much of its history.  For instance:
      
      int gpmc_cs_set_timings(int cs, const struct gpmc_timings *t)
      {
      	int div;
      	div = gpmc_calc_divider(t->sync_clk);
      	if (div < 0)
      		return div;
      static int gpmc_set_async_mode(int cs, struct gpmc_timings *t)
      {
      ...
      	return gpmc_cs_set_timings(cs, t);
      
      .....
      	ret = gpmc_set_async_mode(gpmc_onenand_data->cs, &t);
      	if (IS_ERR_VALUE(ret))
      		return ret;
      
      So, gpmc_cs_set_timings() thinks any negative return value is an error,
      but where we check that in higher levels, only a limited range are
      errors...
      
      There is only _one_ use of IS_ERR_VALUE() in arch/arm which is really
      appropriate, and that is in arch/arm/include/asm/syscall.h:
      
      static inline long syscall_get_error(struct task_struct *task,
      				     struct pt_regs *regs)
      {
      	unsigned long error = regs->ARM_r0;
      	return IS_ERR_VALUE(error) ? error : 0;
      }
      
      because this function really does have to differentiate between error
      return values and addresses which look like negative numbers (eg, from
      mmap()).
      
      So, here's a patch to remove them from OMAP, except for the above.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c48cd659
    • R
      ARM: cleanup: OMAP hwmod error checking · 857835c6
      Russell King 提交于
      omap_hwmod_lookup() only returns NULL on error, never an error pointer.
      Checking the returned pointer using IS_ERR_OR_NULL() is needless
      overhead.  Use a simple !ptr check instead.
      
      OMAP devices (oh->od) always have a valid platform device attached (see
      omap_device_alloc()) so there's no point validating the platform device
      pointer (we will have already oopsed long before if this is not the
      case here.)
      
      Lastly, oh->od is only ever NULL or a valid omap device pointer - 'oh'
      comes from the statically declared hwmod tables, and the pointer is
      only filled in by omap_device_alloc() at a point where the omap device
      pointer must be valid.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      857835c6
  5. 24 4月, 2013 2 次提交
    • A
      ARM: OMAP: remove unused variable · 405f5e5e
      Arnd Bergmann 提交于
      Commit 0583fe47 "ARM: convert arm/arm64 arch timer to use CLKSRC_OF init"
      has left the omap5_realtime_timer_init() function with a stale variable and
      broken whitespace. This fixes both.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      405f5e5e
    • A
      ARM: OMAP2+: add dependencies on ARCH_MULTI_V6/V7 · 4b0ed696
      Arnd Bergmann 提交于
      CONFIG_ARCH_OMAP2PLUS depends on (ARCH_MULTI_V6 || ARCH_MULTI_V7) as of
      a0694861 "ARM: OMAP2+: Enable ARCH_MULTIPLATFORM support", but the
      individual OMAP2/3/4/5 and AM33XX platforms can all be selected independent
      of what we are building for, which is a bug and prevents us from easily
      building e.g. an ARMv7-only defconfig.
      
      This makes ARCH_OMAP2 depend on ARCH_MULTI_V6 and the others depend on
      ARCH_MULTI_V7, to ensure we really only build the platforms for the
      CPUs we have enabled in the global multiplatform configuration step.
      
      Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4b0ed696
  6. 23 4月, 2013 3 次提交
  7. 22 4月, 2013 1 次提交
  8. 19 4月, 2013 1 次提交
  9. 15 4月, 2013 1 次提交
  10. 12 4月, 2013 1 次提交
    • R
      ARM: convert arm/arm64 arch timer to use CLKSRC_OF init · 0583fe47
      Rob Herring 提交于
      This converts arm and arm64 to use CLKSRC_OF DT based initialization for
      the arch timer. A new function arch_timer_arch_init is added to allow for
      arch specific setup.
      
      This has a side effect of enabling sched_clock on omap5 and exynos5. There
      should not be any reason not to use the arch timers for sched_clock.
      Signed-off-by: NRob Herring <rob.herring@calxeda.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-samsung-soc@vger.kernel.org
      Cc: linux-omap@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      0583fe47
  11. 11 4月, 2013 1 次提交
  12. 10 4月, 2013 8 次提交
  13. 09 4月, 2013 15 次提交