1. 16 2月, 2011 1 次提交
  2. 15 1月, 2011 1 次提交
  3. 12 1月, 2011 1 次提交
  4. 24 12月, 2010 3 次提交
  5. 05 12月, 2010 1 次提交
  6. 08 10月, 2010 2 次提交
  7. 05 10月, 2010 2 次提交
    • W
      ARM: 6385/1: setup: detect aliasing I-cache when D-cache is non-aliasing · 8925ec4c
      Will Deacon 提交于
      Currently, the Kernel assumes that if a CPU has a non-aliasing D-cache
      then the I-cache is also non-aliasing. This may not be true on ARM cores
      from v6 onwards, which may have aliasing I-caches but non-aliasing
      D-caches.
      
      This patch adds a cpu_has_aliasing_icache function, which is called from
      cacheid_init and adds CACHEID_VIPT_I_ALIASING to the cacheid when
      appropriate. A utility macro, icache_is_vipt_aliasing(), is also
      provided.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8925ec4c
    • R
      ARM: Allow SMP kernels to boot on UP systems · f00ec48f
      Russell King 提交于
      UP systems do not implement all the instructions that SMP systems have,
      so in order to boot a SMP kernel on a UP system, we need to rewrite
      parts of the kernel.
      
      Do this using an 'alternatives' scheme, where the kernel code and data
      is modified prior to initialization to replace the SMP instructions,
      thereby rendering the problematical code ineffectual.  We use the linker
      to generate a list of 32-bit word locations and their replacement values,
      and run through these replacements when we detect a UP system.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f00ec48f
  8. 27 7月, 2010 2 次提交
  9. 16 7月, 2010 1 次提交
  10. 09 7月, 2010 4 次提交
  11. 07 7月, 2010 1 次提交
  12. 25 5月, 2010 1 次提交
  13. 19 2月, 2010 1 次提交
  14. 16 2月, 2010 3 次提交
  15. 16 9月, 2009 1 次提交
  16. 24 7月, 2009 1 次提交
  17. 03 3月, 2009 1 次提交
  18. 19 2月, 2009 1 次提交
  19. 12 2月, 2009 1 次提交
  20. 01 12月, 2008 1 次提交
  21. 28 11月, 2008 1 次提交
    • N
      [ARM] rationalize memory configuration code some more · 4b5f32ce
      Nicolas Pitre 提交于
      Currently there are two instances of struct meminfo: one in
      kernel/setup.c marked __initdata, and another in mm/init.c with
      permanent storage.  Let's keep only the later to directly populate
      the permanent version from arm_add_memory().
      
      Also move common validation tests between the MMU and non-MMU cases
      into arm_add_memory() to remove some duplication.  Protection against
      overflowing the membank array is also moved in there in order to cover
      the kernel cmdline parsing path as well.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4b5f32ce
  22. 06 11月, 2008 2 次提交
  23. 03 10月, 2008 1 次提交
  24. 01 10月, 2008 1 次提交
  25. 25 9月, 2008 3 次提交
    • R
      [ARM] Print details relevant to how we handle the cache · 2b4ae1f1
      Russell King 提交于
      This replaces the original cache type decoding printks.  We now
      indicate how we're treating the cache which we found, rather
      than what we found.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2b4ae1f1
    • R
      [ARM] Introduce new bitmask based cache type macros · c0e95878
      Russell King 提交于
      Rather than trying to (inaccurately) decode the cache type from the
      registers each time we need to decide what type of cache we have,
      use a bitmask initialized early during boot.
      
      Since the setup is a one-off initialization, we can be a little more
      clever and take account of the CPU architecture as well.
      
      Note that we continue to achieve the compactness on optimised kernels
      by forcing tests to always-false or always-true as appropriate, thereby
      allowing the compiler to do build-time code elimination.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c0e95878
    • R
      [ARM] Remove cache type printks · 90f1e084
      Russell King 提交于
      The cache type register found in ARMv5 and later CPUs changes format
      and meaning depending on the CPU architecture version.  Currently,
      this code:
      a) doesn't work for everything - Xscale's are identified as
         'unknown 5'.
      b) is not able to tell whether the caches are VIVT or VIPT from the
         cache type.
      c) prints rubbish on some ARMv6 and ARMv7+ CPUs.
      
      The two solutions to this are:
      1. Add yet more code to decode and print the various different register
         formats.
      2. Remove the code altogther.
      
      The code only exists to decode and print the cache parameters.
      Increasing the complexity of it just for the sake of a few prinks
      isn't worth it.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      90f1e084
  26. 06 9月, 2008 2 次提交