1. 28 3月, 2011 3 次提交
  2. 26 3月, 2011 1 次提交
  3. 14 3月, 2011 21 次提交
  4. 10 3月, 2011 1 次提交
  5. 24 2月, 2011 1 次提交
    • S
      ARM: 6759/1: smp: Select local timers vs broadcast timer support runtime · af90f10d
      Santosh Shilimkar 提交于
      The current code support of dummy timers in absence of local
      timer is compile time. This is an attempt to convert it to runtime
      so that on few SOC version if the local timers aren't supported
      kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from
      this limitation.
      
      This patch should not have any functional impact on affected
      files.
      
      Cc: Daniel Walker <dwalker@codeaurora.org>
      Cc: Bryan Huntsman <bryanh@codeaurora.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Magnus Damm <magnus.damm@gmail.com>
      Cc: Colin Cross <ccross@android.com>
      Cc: Erik Gilling <konkers@android.com>
      Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
      Cc: Linus Walleij <linus.walleij@stericsson.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      af90f10d
  6. 18 2月, 2011 1 次提交
  7. 17 2月, 2011 2 次提交
  8. 12 1月, 2011 1 次提交
  9. 11 1月, 2011 5 次提交
  10. 30 12月, 2010 1 次提交
  11. 24 12月, 2010 1 次提交
  12. 22 12月, 2010 1 次提交
  13. 20 12月, 2010 1 次提交
    • 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