1. 14 6月, 2017 1 次提交
  2. 25 12月, 2016 1 次提交
  3. 15 7月, 2016 1 次提交
  4. 28 6月, 2016 2 次提交
  5. 09 10月, 2015 2 次提交
  6. 03 10月, 2015 1 次提交
  7. 17 7月, 2015 1 次提交
  8. 21 11月, 2014 1 次提交
  9. 27 8月, 2014 1 次提交
  10. 19 3月, 2014 1 次提交
  11. 20 10月, 2013 1 次提交
  12. 15 7月, 2013 1 次提交
    • P
      arm: delete __cpuinit/__CPUINIT usage from all ARM users · 8bd26e3a
      Paul Gortmaker 提交于
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      This removes all the ARM uses of the __cpuinit macros from C code,
      and all __CPUINIT from assembly code.  It also had two ".previous"
      section statements that were paired off against __CPUINIT
      (aka .section ".cpuinit.text") that also get removed here.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      8bd26e3a
  13. 10 7月, 2013 1 次提交
  14. 25 6月, 2013 1 次提交
  15. 11 3月, 2013 1 次提交
  16. 04 3月, 2013 1 次提交
    • S
      ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp · 904464b9
      Shawn Guo 提交于
      When booting a SMP build kernel with nosmp on kernel cmdline, the
      following fat warning will be hit.
      
      ------------[ cut here ]------------
      WARNING: at arch/arm/kernel/smp_twd.c:345
      twd_local_timer_of_register+0x7c/0x90()
      twd_local_timer_of_register failed (-6)
      Modules linked in:
      Backtrace:
      [<80011f14>] (dump_backtrace+0x0/0x10c) from [<8044dd30>]
      (dump_stack+0x18/0x1c)
       r7:805e9f58 r6:805ba84c r5:80539331 r4:00000159
      [<8044dd18>] (dump_stack+0x0/0x1c) from [<80020fbc>]
      (warn_slowpath_common+0x54/0x6c)
      [<80020f68>] (warn_slowpath_common+0x0/0x6c) from [<80021078>]
      (warn_slowpath_fmt+0x38/0x40)
       r9:412fc09a r8:8fffffff r7:ffffffff r6:00000001 r5:80633b8c
      r4:80b32da8
      [<80021040>] (warn_slowpath_fmt+0x0/0x40) from [<805ba84]
      (twd_local_timer_of_register+0x7c/0x90)
       r3:fffffffa r2:8053934b
      [<805ba7d0>] (twd_local_timer_of_register+0x0/0x90) from [<805c0bec>]
      (imx6q_timer_init+0x18/0x4c)
       r5:80633800 r4:8053b701
      [<805c0bd4>] (imx6q_timer_init+0x0/0x4c) from [<805ba4e8>]
      (time_init+0x28/0x38)
       r5:80633800 r4:805dc0f4
      [<805ba4c0>] (time_init+0x0/0x38) from [<805b6854>]
      (start_kernel+0x1a0/0x310)
      [<805b66b4>] (start_kernel+0x0/0x310) from [<10008044>] (0x10008044)
       r8:1000406a r7:805f3f8c r6:805dc0c4 r5:805f0518 r4:10c5387d
      ---[ end trace 1b75b31a2719ed1c ]---
      
      Check (!is_smp() || !setup_max_cpus) in twd_local_timer_of_register()
      to make it be a no-op for the conditions, thus avoid above warning.
      Reported-by: NDirk Behme <dirk.behme@de.bosch.com>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      904464b9
  17. 02 2月, 2013 1 次提交
  18. 13 1月, 2013 1 次提交
  19. 07 11月, 2012 1 次提交
  20. 04 11月, 2012 2 次提交
  21. 01 11月, 2012 1 次提交
  22. 22 10月, 2012 1 次提交
  23. 20 9月, 2012 1 次提交
    • M
      ARM: 7535/1: Reprogram smp_twd based on new common clk framework notifiers · 2b25d9f6
      Mike Turquette 提交于
      Running cpufreq driver on imx6q, the following warning is seen.
      
      $ BUG: sleeping function called from invalid context at kernel/mutex.c:269
      
      <snip>
      
      stack backtrace:
      Backtrace:
      [<80011d64>] (dump_backtrace+0x0/0x10c) from [<803fc164>] (dump_stack+0x18/0x1c)
       r6:bf8142e0 r5:bf814000 r4:806ac794 r3:bf814000
      [<803fc14c>] (dump_stack+0x0/0x1c) from [<803fd444>] (print_usage_bug+0x250/0x2b
      8)
      [<803fd1f4>] (print_usage_bug+0x0/0x2b8) from [<80060f90>] (mark_lock+0x56c/0x67
      0)
      [<80060a24>] (mark_lock+0x0/0x670) from [<80061a20>] (__lock_acquire+0x98c/0x19b
      4)
      [<80061094>] (__lock_acquire+0x0/0x19b4) from [<80062f14>] (lock_acquire+0x68/0x
      7c)
      [<80062eac>] (lock_acquire+0x0/0x7c) from [<80400f28>] (mutex_lock_nested+0x78/0
      x344)
       r7:00000000 r6:bf872000 r5:805cc858 r4:805c2a04
      [<80400eb0>] (mutex_lock_nested+0x0/0x344) from [<803089ac>] (clk_get_rate+0x1c/
      0x58)
      [<80308990>] (clk_get_rate+0x0/0x58) from [<80013c48>] (twd_update_frequency+0x1
      8/0x50)
       r5:bf253d04 r4:805cadf4
      [<80013c30>] (twd_update_frequency+0x0/0x50) from [<80068e20>] (generic_smp_call
      _function_single_interrupt+0xd4/0x13c)
       r4:bf873ee0 r3:80013c30
      [<80068d4c>] (generic_smp_call_function_single_interrupt+0x0/0x13c) from [<80013
      34c>] (handle_IPI+0xc0/0x194)
       r8:00000001 r7:00000000 r6:80574e48 r5:bf872000 r4:80593958
      [<8001328c>] (handle_IPI+0x0/0x194) from [<800084e8>] (gic_handle_irq+0x58/0x60)
       r8:00000000 r7:bf873f8c r6:bf873f58 r5:80593070 r4:f4000100
      r3:00000005
      [<80008490>] (gic_handle_irq+0x0/0x60) from [<8000e124>] (__irq_svc+0x44/0x60)
      Exception stack(0xbf873f58 to 0xbf873fa0)
      3f40:                                                       00000001 00000001
      3f60: 00000000 bf814000 bf872000 805cab48 80405aa4 80597648 00000000 412fc09a
      3f80: bf872000 bf873fac bf873f70 bf873fa0 80063844 8000f1f8 20000013 ffffffff
       r6:ffffffff r5:20000013 r4:8000f1f8 r3:bf814000
      [<8000f1b8>] (default_idle+0x0/0x4c) from [<8000f428>] (cpu_idle+0x98/0x114)
      [<8000f390>] (cpu_idle+0x0/0x114) from [<803f9834>] (secondary_start_kernel+0x11
      c/0x140)
      [<803f9718>] (secondary_start_kernel+0x0/0x140) from [<103f9234>] (0x103f9234)
       r6:10c03c7d r5:0000001f r4:4f86806a r3:803f921c
      
      It looks that the warning is caused by that twd_update_frequency() gets
      called from an atomic context while it calls clk_get_rate() where a
      mutex gets held.
      
      To fix the warning, let's convert common clk users over to clk notifiers
      in place of CPUfreq notifiers.  This works out nicely for Cortex-A9
      MPcore designs that scale all CPUs at the same frequency.
      
      Platforms that have not been converted to the common clk framework and
      support CPUfreq will rely on the old mechanism.  Once these platforms
      are converted over fully then we can remove the CPUfreq-specific bits
      for good.
      Signed-off-by: NMike Turquette <mturquette@linaro.org>
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2b25d9f6
  24. 20 4月, 2012 1 次提交
  25. 16 4月, 2012 1 次提交
  26. 13 3月, 2012 4 次提交
  27. 21 2月, 2012 1 次提交
    • S
      ARM: 7336/1: smp_twd: Don't register CPUFREQ notifiers if local timers are not initialised · 910ba598
      Santosh Shilimkar 提交于
      Current ARM local timer code registers CPUFREQ notifiers even in case
      the twd_timer_setup() isn't called. That seems to be wrong and
      would eventually lead to kernel crash on the CPU frequency transitions
      on the SOCs where the local timer doesn't exist or broken because of
      hardware BUG. Fix it by testing twd_evt and *__this_cpu_ptr(twd_evt).
      
      The issue was observed with v3.3-rc3 and building an OMAP2+ kernel
      on OMAP3 SOC which doesn't have TWD.
      
      Below is the dump for reference :
      
       Unable to handle kernel paging request at virtual address 007e900
       pgd = cdc20000
       [007e9000] *pgd=00000000
       Internal error: Oops: 5 [#1] SMP
       Modules linked in:
       CPU: 0    Not tainted  (3.3.0-rc3-pm+debug+initramfs #9)
       PC is at twd_update_frequency+0x34/0x48
       LR is at twd_update_frequency+0x10/0x48
       pc : [<c001382c>]    lr : [<c0013808>]    psr: 60000093
       sp : ce311dd8  ip : 00000000  fp : 00000000
       r10: 00000000  r9 : 00000001  r8 : ce310000
       r7 : c0440458  r6 : c00137f8  r5 : 00000000  r4 : c0947a74
       r3 : 00000000  r2 : 007e9000  r1 : 00000000  r0 : 00000000
       Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment usr
       Control: 10c5387d  Table: 8dc20019  DAC: 00000015
       Process sh (pid: 599, stack limit = 0xce3102f8)
       Stack: (0xce311dd8 to 0xce312000)
       1dc0:                                                       6000c
       1de0: 00000001 00000002 00000000 00000000 00000000 00000000 00000
       1e00: ffffffff c093d8f0 00000000 ce311ebc 00000001 00000001 ce310
       1e20: c001386c c0437c4c c0e95b60 c0e95ba8 00000001 c0e95bf8 ffff4
       1e40: 00000000 00000000 c005ef74 ce310000 c0435cf0 ce311ebc 00000
       1e60: ce352b40 0007a120 c08d5108 c08ba040 c08ba040 c005f030 00000
       1e80: c08bc554 c032fe2c 0007a120 c08d4b64 ce352b40 c08d8618 ffff8
       1ea0: c08ba040 c033364c ce311ecc c0433b50 00000002 ffffffea c0330
       1ec0: 0007a120 0007a120 22222201 00000000 22222222 00000000 ce357
       1ee0: ce3d6000 cdc2aed8 ce352ba0 c0470164 00000002 c032f47c 00034
       1f00: c0331cac ce352b40 00000007 c032f6d0 ce352bbc 0003d090 c0930
       1f20: c093d8bc c03306a4 00000007 ce311f80 00000007 cdc2aec0 ce358
       1f40: ce8d20c0 00000007 b6fe5000 ce311f80 00000007 ce310000 0000c
       1f60: c000de74 ce987400 ce8d20c0 b6fe5000 00000000 00000000 0000c
       1f80: 00000000 00000000 001fbac8 00000000 00000007 001fbac8 00004
       1fa0: c000df04 c000dd60 00000007 001fbac8 00000001 b6fe5000 00000
       1fc0: 00000007 001fbac8 00000007 00000004 b6fe5000 00000000 00202
       1fe0: 00000000 beb565f8 00101ffc 00008e8c 60000010 00000001 00000
       [<c001382c>] (twd_update_frequency+0x34/0x48) from [<c008ac4c>] )
       [<c008ac4c>] (smp_call_function_single+0x17c/0x1c8) from [<c0013)
       [<c0013890>] (twd_cpufreq_transition+0x24/0x30) from [<c0437c4c>)
       [<c0437c4c>] (notifier_call_chain+0x44/0x84) from [<c005efe4>] ()
       [<c005efe4>] (__srcu_notifier_call_chain+0x70/0xa4) from [<c005f)
       [<c005f030>] (srcu_notifier_call_chain+0x18/0x20) from [<c032fe2)
       [<c032fe2c>] (cpufreq_notify_transition+0xc8/0x1b0) from [<c0333)
       [<c033364c>] (omap_target+0x1b4/0x28c) from [<c032f47c>] (__cpuf)
       [<c032f47c>] (__cpufreq_driver_target+0x50/0x64) from [<c0331d24)
       [<c0331d24>] (cpufreq_set+0x78/0x98) from [<c032f6d0>] (store_sc)
       [<c032f6d0>] (store_scaling_setspeed+0x5c/0x74) from [<c03306a4>)
       [<c03306a4>] (store+0x58/0x74) from [<c014d868>] (sysfs_write_fi)
       [<c014d868>] (sysfs_write_file+0x80/0xb4) from [<c00f2c2c>] (vfs)
       [<c00f2c2c>] (vfs_write+0xa8/0x138) from [<c00f2e9c>] (sys_write)
       [<c00f2e9c>] (sys_write+0x40/0x6c) from [<c000dd60>] (ret_fast_s)
       Code: e594300c e792210c e1a01000 e5840004 (e7930002)
       ---[ end trace 5da3b5167c1ecdda ]---
      Reported-by: NKevin Hilman <khilman@ti.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Tested-by: NKevin Hilman <khilman@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      910ba598
  28. 23 1月, 2012 1 次提交
  29. 24 12月, 2011 3 次提交
  30. 23 10月, 2011 1 次提交
  31. 12 8月, 2011 1 次提交
  32. 07 7月, 2011 1 次提交