1. 15 9月, 2011 1 次提交
  2. 20 7月, 2011 2 次提交
  3. 07 7月, 2011 1 次提交
    • S
      ARM: 6993/1: platsmp: Allow secondary cpu hotplug with maxcpus=1 · 7fa22bd5
      Stephen Boyd 提交于
      If an ARM system has multiple cpus in the same socket and the
      kernel is booted with maxcpus=1, secondary cpus are possible but
      not present due to how platform_smp_prepare_cpus() is called.
      Since most typical ARM processors don't actually support physical
      hotplug, initialize the present map to be equal to the possible
      map in generic ARM SMP code. Also, always call
      platform_smp_prepare_cpus() as long as max_cpus is non-zero (0
      means no SMP) to allow platform code to do any SMP setup.
      
      After applying this patch it's possible to boot an ARM system
      with maxcpus=1 on the command line and then hotplug in secondary
      cpus via sysfs. This is more in line with how x86 does things.
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: David Brown <davidb@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      7fa22bd5
  4. 23 5月, 2011 1 次提交
  5. 22 2月, 2011 1 次提交
  6. 20 12月, 2010 4 次提交
    • R
      ARM: Fix subtle race in CPU pen_release hotplug code · 3705ff6d
      Russell King 提交于
      There is a subtle race in the CPU hotplug code, where a CPU which has
      been offlined can online itself before being requested, which results
      in things going astray on the next online/offline cycle.
      
      What happens in the normal online/offline/online cycle is:
      
      	CPU0			CPU3
      	requests boot of CPU3
      	pen_release = 3
      	flush cache line
      				checks pen_release, reads 3
      				starts boot
      				pen_release = -1
      	... requests CPU3 offline ...
      				... dies ...
      				checks pen_release, reads -1
      	requests boot of CPU3
      	pen_release = 3
      	flush cache line
      				checks pen_release, reads 3
      				starts boot
      				pen_release = -1
      
      However, as the write of -1 of pen_release is not fully flushed back to
      memory, and the checking of pen_release is done with caches disabled,
      this allows CPU3 the opportunity to read the old value of pen_release:
      
      	CPU0			CPU3
      	requests boot of CPU3
      	pen_release = 3
      	flush cache line
      				checks pen_release, reads 3
      				starts boot
      				pen_release = -1
      	... requests CPU3 offline ...
      				... dies ...
      				checks pen_release, reads 3
      				starts boot
      				pen_release = -1
      	requests boot of CPU3
      	pen_release = 3
      	flush cache line
      
      Fix this by grouping the write of pen_release along with its cache line
      flushing code to ensure that any update to pen_release is always pushed
      out to physical memory.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      3705ff6d
    • R
      ARM: SMP: consolidate trace_hardirqs_off() into common SMP code · 2c0136db
      Russell King 提交于
      All platforms call trace_hardirqs_off() in their secondary startup code,
      so move this into the core SMP code - it doesn't need to be in the
      per-platform code.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2c0136db
    • R
      ARM: SMP: consolidate the common parts of smp_prepare_cpus() · 05c74a6c
      Russell King 提交于
      There is a certain amount of smp_prepare_cpus() which doesn't belong
      in the platform support code - that is, code which is invariant to the
      SMP implementation.  Move this code into arch/arm/kernel/smp.c, and
      add a platform_ prefix to the original function.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      05c74a6c
    • R
      ARM: SMP: Clean up ncores sanity checks · 8975b6c0
      Russell King 提交于
      scu_get_core_count() never returns zero cores, so we don't need to
      check and correct if ncores is zero.
      
      Tegra was missing the check against NR_CPUS, leading to a potential
      bitfield overflow if this becomes the case.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8975b6c0
  7. 15 12月, 2010 1 次提交
  8. 03 12月, 2010 1 次提交
  9. 27 8月, 2010 1 次提交
  10. 05 8月, 2010 1 次提交
  11. 02 5月, 2010 1 次提交
  12. 05 11月, 2009 1 次提交
  13. 24 7月, 2009 1 次提交
  14. 30 5月, 2009 1 次提交
  15. 28 5月, 2009 1 次提交
  16. 18 5月, 2009 4 次提交
  17. 17 5月, 2009 2 次提交
  18. 09 1月, 2009 1 次提交
  19. 01 12月, 2008 3 次提交
  20. 06 9月, 2008 1 次提交
  21. 07 8月, 2008 2 次提交
  22. 03 7月, 2008 1 次提交
  23. 01 7月, 2008 1 次提交
  24. 19 4月, 2008 2 次提交
  25. 05 2月, 2008 3 次提交
  26. 16 2月, 2007 1 次提交