1. 07 11月, 2014 1 次提交
  2. 09 9月, 2014 1 次提交
  3. 26 4月, 2014 1 次提交
  4. 24 4月, 2014 1 次提交
  5. 08 4月, 2014 1 次提交
  6. 07 3月, 2014 1 次提交
    • T
      ARM: mvebu: change the default PCIe apertures for Armada 370/XP · 46febc63
      Thomas Petazzoni 提交于
      The latest Marvell bootloaders for various boards change the MBus
      Window base address from 0xC0000000 to 0xF0000000, in order to make
      more RAM in the first 4 GB actually usable by the kernel (RAM that is
      covered by the MBus window is "shadowed" and therefore not usable).
      
      However, our default PCIe memory and I/O apertures where sitting at
      0xe0000000 (for memory) and 0xe8000000 (for I/O), which will now be
      outside of the MBus Window range on those platforms. To make things
      work, we have to ensure those apertures use addresses in the
      0xF0000000 -> 0xFFFFFFFF range.
      
      Of course this change of the MBus Window base address from 0xC0000000
      to 0xF0000000 also comes with a change of the internal register base
      address from 0xD0000000 to 0xF1000000.
      
      We have therefore designed the following memory map:
      
       * 0xF0000000 -> 0xF1000000: 16 MB, used for NOR flashes on Armada XP
         GP and Armada XP DB.
      
       * 0xF1000000 -> 0xF1100000: 1 MB, used for internal registers.
      
       * 0xF8000000 -> 0xFFE00000: 126 MB, used for PCIe memory.
      
       * 0xFFE00000 -> 0xFFF00000: 1 MB, used for PCIe I/O.
      
       * 0xFFF00000 -> 0xFFFFFFFF: 1 MB, used for the BootROM mapping
      
      There is one exception to this layout: the Armada XP OpenBlocks, which
      has a 128 MB NOR flash, mapped from 0xF0000000 to 0xF8000000. This
      does not conflict with the current change for the PCIe I/O and memory
      apertures, and continues to work because on Armada XP OpenBlocks, the
      bootloader is an old one, and continues to have internal registers
      mapped at 0xD0000000.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      46febc63
  7. 18 2月, 2014 1 次提交
  8. 15 1月, 2014 1 次提交
  9. 12 12月, 2013 1 次提交
  10. 26 11月, 2013 1 次提交
    • G
      ARM: mvebu: use the virtual CPU registers to access coherency registers · b6dda00c
      Gregory CLEMENT 提交于
      The Armada XP provides a mechanism called "virtual CPU registers" or
      "per-CPU register banking", to access the per-CPU registers of the
      current CPU, without having to worry about finding on which CPU we're
      running. CPU0 has its registers at 0x21800, CPU1 at 0x21900, CPU2 at
      0x21A00 and CPU3 at 0x21B00. The virtual registers accessing the
      current CPU registers are at 0x21000.
      
      However, in the Device Tree node that provides the register addresses
      for the coherency unit (which is responsible for ensuring coherency
      between processors, and I/O coherency between processors and the
      DMA-capable devices), a mistake was made: the CPU0-specific registers
      were specified instead of the virtual CPU registers. This means that
      the coherency barrier needed for I/O coherency was not behaving
      properly when executed from a CPU different from CPU0. This patch
      fixes that by using the virtual CPU registers.
      Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: <stable@vger.kernel.org> # v3.8+
      Fixes: e60304f8 "arm: mvebu: Add hardware I/O Coherency support"
      Signed-off-by: NJason Cooper <jason@lakedaemon.net>
      b6dda00c
  11. 24 11月, 2013 1 次提交
  12. 23 10月, 2013 2 次提交
  13. 30 9月, 2013 1 次提交
  14. 18 9月, 2013 1 次提交
  15. 16 8月, 2013 1 次提交
  16. 06 8月, 2013 3 次提交
  17. 04 6月, 2013 1 次提交
  18. 28 5月, 2013 2 次提交
  19. 23 5月, 2013 1 次提交
  20. 20 5月, 2013 1 次提交
  21. 15 5月, 2013 1 次提交
  22. 15 4月, 2013 5 次提交
  23. 12 4月, 2013 1 次提交
  24. 09 3月, 2013 2 次提交
  25. 01 3月, 2013 5 次提交
  26. 22 2月, 2013 1 次提交
  27. 07 1月, 2013 1 次提交