1. 07 Mar, 2012 1 commit
  2. 21 Feb, 2012 1 commit
  3. 03 Feb, 2012 1 commit
  4. 23 Jan, 2012 1 commit
    • Will Deacon's avatar
      ARM: 7291/1: cache: assume 64-byte L1 cachelines for ARMv7 CPUs · a092f2b1
      Will Deacon authored
      
      To ensure correct alignment of cacheline-aligned data, the maximum
      cacheline size needs to be known at compile time.
      
      Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
      that there will be future ARMv7 implementations with the same line size)
      then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
      size. For CPUs with smaller caches, this will result in some harmless
      padding but will help with single zImage work and avoid hitting subtle
      bugs with misaligned data structures.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      a092f2b1
  5. 19 Jan, 2012 1 commit
  6. 11 Jan, 2012 1 commit
  7. 05 Jan, 2012 1 commit
  8. 28 Dec, 2011 2 commits
  9. 23 Dec, 2011 5 commits
  10. 19 Dec, 2011 3 commits
  11. 18 Dec, 2011 2 commits
  12. 13 Dec, 2011 2 commits
  13. 12 Dec, 2011 1 commit
    • Will Deacon's avatar
      ARM: stop: execute platform callback from cpu_stop code · 02b73e2e
      Will Deacon authored
      
      Sending IPI_CPU_STOP to a CPU causes it to execute a busy cpu_relax
      loop forever. This makes it impossible to kexec successfully on an SMP
      system since the secondary CPUs do not reset.
      
      This patch adds a callback to platform_cpu_kill, defined when
      CONFIG_HOTPLUG_CPU=y, from the ipi_cpu_stop handling code. This function
      currently just returns 1 on all platforms that define it but allows them
      to do something more sophisticated in the future.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      02b73e2e
  14. 08 Dec, 2011 1 commit
  15. 06 Dec, 2011 1 commit
    • Nicolas Pitre's avatar
      ARM: 7186/1: fix Kconfig issue with PHYS_OFFSET and !MMU · 974c0724
      Nicolas Pitre authored
      Commit 1b9f95f8
      
       (ARM: prepare for removal of a bunch of <mach/memory.h>
      files) introduced CONFIG_PHYS_OFFSET but the Kconfig hex prompt did not
      provide a default value.
      
      This has the undesired side effect of breaking a reportedly used
      trick for updating defconfigs on the fly for routine buildtesting
      across all arch and all platforms, i.e.
      
      	cp /path/to/somedefconfig .config ; yes "" | make oldconfig
      
      because the config system will endlessly loop until a valid address is
      provided.
      
      However we can't just pick a random default value since it is likely to
      be wrong for the majority of the boards as the right answer for this
      option is quite varied.  So the fact that the config system insists on
      having a proper value be entered is actually a good thing.
      
      It turns out that only at91x40_defconfig has this problem because it has
      CONFIG_MMU=n. However, in the !MMU case, there is already a CONFIG_DRAM_BASE
      value that can be used here.  So let's use that as a default in that case
      and suppress the redundant CONFIG_PHYS_OFFSET prompt.
      
      Eventually the DRAM_BASE config option could simply be replaced by
      PHYS_OFFSET directly, but that's a larger change better suited for later.
      Reported-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      974c0724
  16. 28 Nov, 2011 1 commit
  17. 21 Nov, 2011 2 commits
  18. 15 Nov, 2011 13 commits