1. 14 11月, 2013 1 次提交
  2. 29 10月, 2013 1 次提交
  3. 20 10月, 2013 2 次提交
  4. 11 10月, 2013 1 次提交
    • S
      ARM: mm: Correct virt_to_phys patching for 64 bit physical addresses · f52bb722
      Sricharan R 提交于
      The current phys_to_virt patching mechanism works only for 32 bit
      physical addresses and this patch extends the idea for 64bit physical
      addresses.
      
      The 64bit v2p patching mechanism patches the higher 8 bits of physical
      address with a constant using 'mov' instruction and lower 32bits are patched
      using 'add'. While this is correct, in those platforms where the lowmem addressable
      physical memory spawns across 4GB boundary, a carry bit can be produced as a
      result of addition of lower 32bits. This has to be taken in to account and added
      in to the upper. The patched __pv_offset and va are added in lower 32bits, where
      __pv_offset can be in two's complement form when PA_START < VA_START and that can
      result in a false carry bit.
      
      e.g
          1) PA = 0x80000000; VA = 0xC0000000
             __pv_offset = PA - VA = 0xC0000000 (2's complement)
      
          2) PA = 0x2 80000000; VA = 0xC000000
             __pv_offset = PA - VA = 0x1 C0000000
      
      So adding __pv_offset + VA should never result in a true overflow for (1).
      So in order to differentiate between a true carry, a __pv_offset is extended
      to 64bit and the upper 32bits will have 0xffffffff if __pv_offset is
      2's complement. So 'mvn #0' is inserted instead of 'mov' while patching
      for the same reason. Since mov, add, sub instruction are to patched
      with different constants inside the same stub, the rotation field
      of the opcode is using to differentiate between them.
      
      So the above examples for v2p translation becomes for VA=0xC0000000,
          1) PA[63:32] = 0xffffffff
             PA[31:0] = VA + 0xC0000000 --> results in a carry
             PA[63:32] = PA[63:32] + carry
      
             PA[63:0] = 0x0 80000000
      
          2) PA[63:32] = 0x1
             PA[31:0] = VA + 0xC0000000 --> results in a carry
             PA[63:32] = PA[63:32] + carry
      
             PA[63:0] = 0x2 80000000
      
      The above ideas were suggested by Nicolas Pitre <nico@linaro.org> as
      part of the review of first and second versions of the subject patch.
      
      There is no corresponding change on the phys_to_virt() side, because
      computations on the upper 32-bits would be discarded anyway.
      
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NSricharan R <r.sricharan@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      f52bb722
  5. 03 10月, 2013 1 次提交
    • S
      ARM: 7846/1: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices · bc41b872
      Santosh Shilimkar 提交于
      The generic code is well equipped to differentiate between
      SMP and UP configurations.However, there are some devices which
      use Cortex-A9 MP core IP with 1 CPU as configuration. To let
      these SOCs to co-exist in a CONFIG_SMP=y build by leveraging
      the SMP_ON_UP support, we need to additionally check the
      number the cores in Cortex-A9 MPCore configuration. Without
      such a check in place, the startup code tries to execute
      ALT_SMP() set of instructions which lead to CPU faults.
      
      The issue was spotted on TI's Aegis device and this patch
      makes now the device work with omap2plus_defconfig which
      enables SMP by default. The change is kept limited to only
      Cortex-A9 MPCore detection code.
      
      Note that if any future SoC *does* use 0x0 as the PERIPH_BASE, then
      the SCU address check code needs to be #ifdef'd for for the Aegis
      platform.
      Acked-by: NSricharan R <r.sricharan@ti.com>
      Signed-off-by: NVaibhav Bedia <vaibhav.bedia@ti.com>
      Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bc41b872
  6. 01 8月, 2013 1 次提交
  7. 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
  8. 30 5月, 2013 1 次提交
  9. 03 4月, 2013 1 次提交
  10. 04 3月, 2013 1 次提交
  11. 17 1月, 2013 1 次提交
  12. 11 1月, 2013 1 次提交
  13. 19 9月, 2012 1 次提交
    • D
      ARM: virt: allow the kernel to be entered in HYP mode · 80c59daf
      Dave Martin 提交于
      This patch does two things:
      
        * Ensure that asynchronous aborts are masked at kernel entry.
          The bootloader should be masking these anyway, but this reduces
          the damage window just in case it doesn't.
      
        * Enter svc mode via exception return to ensure that CPU state is
          properly serialised.  This does not matter when switching from
          an ordinary privileged mode ("PL1" modes in ARMv7-AR rev C
          parlance), but it potentially does matter when switching from a
          another privileged mode such as hyp mode.
      
      This should allow the kernel to boot safely either from svc mode or
      hyp mode, even if no support for use of the ARM Virtualization
      Extensions is built into the kernel.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
      80c59daf
  14. 14 9月, 2012 1 次提交
  15. 10 7月, 2012 1 次提交
  16. 04 5月, 2012 1 次提交
  17. 29 3月, 2012 1 次提交
  18. 24 3月, 2012 2 次提交
  19. 13 1月, 2012 1 次提交
  20. 08 12月, 2011 2 次提交
  21. 06 12月, 2011 2 次提交
    • W
      ARM: SMP: use idmap_pgd for mapping MMU enable during secondary booting · 4e8ee7de
      Will Deacon 提交于
      The ARM SMP booting code allocates a temporary set of page tables
      containing an identity mapping of the kernel image and provides this
      to secondary CPUs for initial booting.
      
      In reality, we only need to include the __turn_mmu_on function in the
      identity mapping since the rest of the kernel is executing from virtual
      addresses after this point.
      
      This patch adds __turn_mmu_on to the .idmap.text section, allowing the
      SMP booting code to use the idmap_pgd directly and not have to populate
      its own set of page table.
      
      As a result of this patch, we can make the identity_mapping_add function
      static (since it is only used within mm/idmap.c) and also remove the
      identity_mapping_del function. The identity map population is moved to
      an early initcall so that it is setup in time for secondary CPU bringup.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      4e8ee7de
    • W
      ARM: head.S: only include __turn_mmu_on in the initial identity mapping · 72662e01
      Will Deacon 提交于
      __create_page_tables identity maps the region of memory from
      __enable_mmu to the end of __turn_mmu_on.
      
      In preparation for including __turn_mmu_on in the .idmap.text section,
      this patch modifies the identity mapping so that it only includes the
      __turn_mmu_on code.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      72662e01
  22. 09 11月, 2011 1 次提交
  23. 26 9月, 2011 2 次提交
  24. 23 8月, 2011 1 次提交
  25. 13 8月, 2011 1 次提交
  26. 19 7月, 2011 1 次提交
    • D
      ARM: 6999/1: head, zImage: Always Enter the kernel in ARM state · 540b5738
      Dave Martin 提交于
      Currently, the documented kernel entry requirements are not
      explicit about whether the kernel should be entered in ARM or
      Thumb, leading to an ambiguitity about how to enter Thumb-2
      kernels.  As a result, the kernel is reliant on the zImage
      decompressor to enter the kernel proper in the correct instruction
      set state.
      
      This patch changes the boot entry protocol for head.S and Image to
      be the same as for zImage: in all cases, the kernel is now entered
      in ARM.
      
      Documentation/arm/Booting is updated to reflect this new policy.
      
      A different rule will be needed for Cortex-M class CPUs as and when
      support for those lands in mainline, since these CPUs don't support
      the ARM instruction set at all: a note is added to the effect that
      the kernel must be entered in Thumb on such systems.
      Signed-off-by: NDave Martin <dave.martin@linaro.org>
      Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      540b5738
  27. 26 5月, 2011 1 次提交
  28. 11 5月, 2011 1 次提交
  29. 11 3月, 2011 1 次提交
  30. 18 2月, 2011 4 次提交
  31. 16 2月, 2011 1 次提交
  32. 10 2月, 2011 1 次提交