1. 02 4月, 2013 3 次提交
    • J
      ARM: OMAP2+: Simplify system timer clock definitions · 7bdc83f7
      Jon Hunter 提交于
      In commit c59b537d (ARM: OMAP2+: Simplify dmtimer clock aliases), new
      clock aliases for dmtimers were added to simplify the code. These clock
      aliases can also be used when configuring the system timers and allow us
      to remove the current definitions, simplifying the code.
      
      Please note that for OMAP4/5 devices (unlike OMAP2/3 devices), there is
      no clock alias for "timer_sys_ck" with NULL as the device name. Therefore
      we still need to use the alias "sys_clkin_ck" for these devices.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      7bdc83f7
    • J
      ARM: OMAP2+: Remove hard-coded test on timer ID · a7990a19
      Jon Hunter 提交于
      Currently, when configuring the clock-events and clock-source timers
      for OMAP2+ devices, we check whether the timer ID is 12 before
      attempting to set the parent clock for the timer.
      
      This test was added for OMAP3 general purpose devices (no security
      features enabled) that a 12th timer available but unlike the other
      timers only has a single functional clock source. Calling
      clk_set_parent() for this 12th timer would always return an error
      because there is only one choice for a parent clock. Therefore,
      this hard-coded timer ID test was added.
      
      To avoid this timer ID test, simply check to see if the timer's current
      parent clock is the desired parent clock and only call clk_set_parent()
      if this is not the case.
      
      Also if clk_get() fails, then use PTR_ERR() to return the error code.
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      a7990a19
    • J
      ARM: OMAP2+: Display correct system timer name · e95ea43a
      Jon Hunter 提交于
      Currently on boot, when displaying the name of the gptimer used for
      clockevents and clocksource timers, the timer ID is shown. However,
      when booting with device-tree, the timer ID is not used to select a
      gptimer but a timer property. Hence, it is possible that the timer
      selected when booting with device-tree does not match the ID shown.
      Therefore, instead display the HWMOD name of the gptimer and use
      the HWMOD name as the name of clockevent and clocksource timer (if a
      gptimer is used).
      Signed-off-by: NJon Hunter <jon-hunter@ti.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      e95ea43a
  2. 14 3月, 2013 1 次提交
    • R
      ARM: OMAP: use consistent error checking · 71856843
      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>
      71856843
  3. 24 2月, 2013 9 次提交
  4. 08 2月, 2013 4 次提交
    • W
      ARM: 7641/1: memory: fix broken mmap by ensuring TASK_UNMAPPED_BASE is aligned · 79d1f5c9
      Will Deacon 提交于
      We have received multiple reports of mmap failures when running with a
      2:2 vm split. These manifest as either -EINVAL with a non page-aligned
      address (ending 0xaaa) or a SEGV, depending on the application. The
      issue is commonly observed in children of make, which appears to use
      bottom-up mmap (assumedly because it changes the stack rlimit).
      
      Further investigation reveals that this regression was triggered by
      394ef640 ("mm: use vm_unmapped_area() on arm architecture"), whereby
      TASK_UNMAPPED_BASE is no longer page-aligned for bottom-up mmap, causing
      get_unmapped_area to choke on misaligned addressed.
      
      This patch fixes the problem by defining TASK_UNMAPPED_BASE in terms of
      TASK_SIZE and explicitly aligns the result to 16M, matching the other
      end of the heap.
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Reported-by: NSteve Capper <steve.capper@arm.com>
      Reported-by: NJean-Francois Moine <moinejf@free.fr>
      Reported-by: NChristoffer Dall <cdall@cs.columbia.edu>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      79d1f5c9
    • R
      ARM: DMA mapping: fix bad atomic test · 633dc92a
      Russell King 提交于
      Realview fails to boot with this warning:
      BUG: spinlock lockup suspected on CPU#0, init/1
       lock: 0xcf8bde10, .magic: dead4ead, .owner: init/1, .owner_cpu: 0
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:cf8bde10 r5:cf83d1c0 r4:cf8bde10 r3:cf83d1c0
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c018926c>] (spin_dump+0x84/0x98)
      [<c01891e8>] (spin_dump+0x0/0x98) from [<c0189460>] (do_raw_spin_lock+0x100/0x198)
      [<c0189360>] (do_raw_spin_lock+0x0/0x198) from [<c032cbac>] (_raw_spin_lock+0x3c/0x44)
      [<c032cb70>] (_raw_spin_lock+0x0/0x44) from [<c01c9224>] (pl011_console_write+0xe8/0x11c)
      [<c01c913c>] (pl011_console_write+0x0/0x11c) from [<c002aea8>] (call_console_drivers.clone.7+0xdc/0x104)
      [<c002adcc>] (call_console_drivers.clone.7+0x0/0x104) from [<c002b320>] (console_unlock+0x2e8/0x454)
      [<c002b038>] (console_unlock+0x0/0x454) from [<c002b8b4>] (vprintk_emit+0x2d8/0x594)
      [<c002b5dc>] (vprintk_emit+0x0/0x594) from [<c0329718>] (printk+0x3c/0x44)
      [<c03296dc>] (printk+0x0/0x44) from [<c002929c>] (warn_slowpath_common+0x28/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0070ab0>] (lockdep_trace_alloc+0xd8/0xf0)
      [<c00709d8>] (lockdep_trace_alloc+0x0/0xf0) from [<c00c0850>] (kmem_cache_alloc+0x24/0x11c)
      [<c00c082c>] (kmem_cache_alloc+0x0/0x11c) from [<c00bb044>] (__get_vm_area_node.clone.24+0x7c/0x16c)
      [<c00bafc8>] (__get_vm_area_node.clone.24+0x0/0x16c) from [<c00bb7b8>] (get_vm_area_caller+0x48/0x54)
      [<c00bb770>] (get_vm_area_caller+0x0/0x54) from [<c0020064>] (__alloc_remap_buffer.clone.15+0x38/0xb8)
      [<c002002c>] (__alloc_remap_buffer.clone.15+0x0/0xb8) from [<c0020244>] (__dma_alloc+0x160/0x2c8)
      [<c00200e4>] (__dma_alloc+0x0/0x2c8) from [<c00204d8>] (arm_dma_alloc+0x88/0xa0)[<c0020450>] (arm_dma_alloc+0x0/0xa0) from [<c00beb00>] (dma_pool_alloc+0xcc/0x1a8)
      [<c00bea34>] (dma_pool_alloc+0x0/0x1a8) from [<c01a9d14>] (pl08x_fill_llis_for_desc+0x28/0x568)
      [<c01a9cec>] (pl08x_fill_llis_for_desc+0x0/0x568) from [<c01aab8c>] (pl08x_prep_slave_sg+0x258/0x3b0)
      [<c01aa934>] (pl08x_prep_slave_sg+0x0/0x3b0) from [<c01c9f74>] (pl011_dma_tx_refill+0x140/0x288)
      [<c01c9e34>] (pl011_dma_tx_refill+0x0/0x288) from [<c01ca748>] (pl011_start_tx+0xe4/0x120)
      [<c01ca664>] (pl011_start_tx+0x0/0x120) from [<c01c54a4>] (__uart_start+0x48/0x4c)
      [<c01c545c>] (__uart_start+0x0/0x4c) from [<c01c632c>] (uart_start+0x2c/0x3c)
      [<c01c6300>] (uart_start+0x0/0x3c) from [<c01c795c>] (uart_write+0xcc/0xf4)
      [<c01c7890>] (uart_write+0x0/0xf4) from [<c01b0384>] (n_tty_write+0x1c0/0x3e4)
      [<c01b01c4>] (n_tty_write+0x0/0x3e4) from [<c01acfe8>] (tty_write+0x144/0x240)
      [<c01acea4>] (tty_write+0x0/0x240) from [<c01ad17c>] (redirected_tty_write+0x98/0xac)
      [<c01ad0e4>] (redirected_tty_write+0x0/0xac) from [<c00c371c>] (vfs_write+0xbc/0x150)
      [<c00c3660>] (vfs_write+0x0/0x150) from [<c00c39c0>] (sys_write+0x4c/0x78)
      [<c00c3974>] (sys_write+0x0/0x78) from [<c0014460>] (ret_fast_syscall+0x0/0x3c)
      
      This happens because the DMA allocation code is not respecting atomic
      allocations correctly.
      
      GFP flags should not be tested for GFP_ATOMIC to determine if an
      atomic allocation is being requested.  GFP_ATOMIC is not a flag but
      a value.  The GFP bitmask flags are all prefixed with __GFP_.
      
      The rest of the kernel tests for __GFP_WAIT not being set to indicate
      an atomic allocation.  We need to do the same.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      633dc92a
    • R
      ARM: realview: ensure that we have sufficient IRQs available · e210101d
      Russell King 提交于
      Realview EB with a rev B MPcore tile results in lots of warnings at
      boot because it can't allocate enough IRQs.  Fix this by increasing
      the number of available IRQs.
      
      WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:757 gic_init_bases+0x12c/0x2ec()
      Cannot allocate irq_descs @ IRQ96, assuming pre-allocated
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002f5 r5:c042c62c r4:c044ff40 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029384>] (warn_slowpath_fmt+0x38/0x40)
      [<c002934c>] (warn_slowpath_fmt+0x0/0x40) from [<c042c62c>] (gic_init_bases+0x12c/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1c ]---
      ------------[ cut here ]------------
      WARNING: at /home/rmk/git/linux-rmk/kernel/irq/irqdomain.c:234 irq_domain_add_legacy+0x80/0x140()
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000000ea r5:c0081a38 r4:00000000 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c0081a38>] (irq_domain_add_legacy+0x80/0x140)
      [<c00819b8>] (irq_domain_add_legacy+0x0/0x140) from [<c042c64c>] (gic_init_bases+0x14c/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1d ]---
      ------------[ cut here ]------------
      WARNING: at /home/rmk/git/linux-rmk/arch/arm/common/gic.c:762 gic_init_bases+0x170/0x2ec()
      Modules linked in:
      Backtrace:
      [<c00185d8>] (dump_backtrace+0x0/0x10c) from [<c03294e8>] (dump_stack+0x18/0x1c) r6:000002fa r5:c042c670 r4:00000000 r3:c045f240
      [<c03294d0>] (dump_stack+0x0/0x1c) from [<c00292c8>] (warn_slowpath_common+0x54/0x6c)
      [<c0029274>] (warn_slowpath_common+0x0/0x6c) from [<c0029304>] (warn_slowpath_null+0x24/0x2c)
      [<c00292e0>] (warn_slowpath_null+0x0/0x2c) from [<c042c670>] (gic_init_bases+0x170/0x2ec)
      [<c042c500>] (gic_init_bases+0x0/0x2ec) from [<c042cdc8>] (gic_init_irq+0x8c/0xd8)
      [<c042cd3c>] (gic_init_irq+0x0/0xd8) from [<c042827c>] (init_IRQ+0x1c/0x24)
      [<c0428260>] (init_IRQ+0x0/0x24) from [<c04256c8>] (start_kernel+0x1a4/0x300)
      [<c0425524>] (start_kernel+0x0/0x300) from [<70008070>] (0x70008070)
      ---[ end trace 1b75b31a2719ed1e ]---
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      e210101d
    • R
      ARM: GIC: fix GIC cpumask initialization · 2bb31351
      Russell King 提交于
      Punit Agrawal reports:
      > I was trying to boot 3.8-rc5 on Realview EB 11MPCore using
      > realview-smp_defconfig as a starting point but the kernel failed to
      > progress past the log below (config attached).
      >
      > Pawel suggested I try reverting 384a2902 - "ARM: gic: use a private
      > mapping for CPU target interfaces" that you've authored. With this
      > commit reverted the kernel boots.
      >
      > I am not quite sure why the commit breaks 11MPCore but Pawel (cc'd)
      > might be able to shed light on that.
      
      Some early GIC implementations return zero for the first distributor
      CPU routing register.  This means we can't rely on that telling us
      which CPU interface we're connected to.  We know that these platforms
      implement PPIs for IRQs 29-31 - but we shouldn't assume that these
      will always be populated.
      
      So, instead, scan for a non-zero CPU routing register in the first
      32 IRQs and use that as our CPU mask.
      Reported-by: NPunit Agrawal <punit.agrawal@arm.com>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2bb31351
  5. 05 2月, 2013 1 次提交
  6. 01 2月, 2013 3 次提交
  7. 24 1月, 2013 2 次提交
  8. 23 1月, 2013 9 次提交
  9. 22 1月, 2013 4 次提交
  10. 19 1月, 2013 4 次提交