1. 22 11月, 2018 1 次提交
    • P
      MIPS: Enable dead code elimination · c0436b50
      Paul Burton 提交于
      Select CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION for MIPS, allowing the
      user to enable dead code elimination. In order for this to work, ensure
      that we keep the data bus exception table & the machine list by
      annotating them with KEEP.
      
      This shrinks both 32r2el_defconfig & 64r6el_defconfig builds by ~6%, as
      shown by numbers from scripts/bloat-o-meter:
      
                | 32r2el_defconfig | 64r6el_defconfig
        --------|------------------|------------------
         No DCE | 8919864          | 8286307
            DCE | 8338988 (-6.51%) | 7741808 (-6.57%)
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21187/
      Cc: linux-mips@linux-mips.org
      c0436b50
  2. 21 11月, 2018 1 次提交
  3. 16 11月, 2018 2 次提交
    • M
      MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur · e4849aff
      Maciej W. Rozycki 提交于
      The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
      DRAM controller that supports memory amounts of up to 16GiB, and due to
      how the address decoder has been wired in the SOC any memory beyond 1GiB
      is actually mapped starting from 4GiB physical up, that is beyond the
      32-bit addressable limit[1].  Consequently if the maximum amount of
      memory has been installed, then it will span up to 19GiB.
      
      Many of the evaluation boards we support that are based on one of these
      SOCs have their memory soldered and the amount present fits in the
      32-bit address range.  The BCM91250A SWARM board however has actual DIMM
      slots and accepts, depending on the peripherals revision of the SOC, up
      to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
      I believe this is also the case with the BCM91250C2 LittleSur board.
      This means that up to either 3GiB or 7GiB of memory requires 64-bit
      addressing to access.
      
      I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
      accepts at least as much memory, although I have no documentation or
      actual hardware available to verify that.
      
      Both systems have PCI slots installed for use by any PCI option boards,
      including ones that only support 32-bit addressing (additionally the
      32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
      addressing to 32-bits), and there is no IOMMU available.  Therefore for
      PCI DMA to work in the presence of memory beyond enable swiotlb for the
      affected systems.
      
      All the other SOC onchip DMA devices use 40-bit addressing and therefore
      can address the whole memory, so only enable swiotlb if PCI support and
      support for DMA beyond 4GiB have been both enabled in the configuration
      of the kernel.
      
      This shows up as follows:
      
      Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
      Board type: SiByte BCM91250A (SWARM)
      Determined physical RAM map:
       memory: 000000000fe7fe00 @ 0000000000000000 (usable)
       memory: 000000001ffffe00 @ 0000000080000000 (usable)
       memory: 000000000ffffe00 @ 00000000c0000000 (usable)
       memory: 0000000087fffe00 @ 0000000100000000 (usable)
      software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)
      
      in the bootstrap log and removes failures like these:
      
      defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
      fddi0: Receive buffer allocation failed
      fddi0: Adapter open failed!
      IP-Config: Failed to open fddi0
      defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
      fddi1: Receive buffer allocation failed
      fddi1: Adapter open failed!
      IP-Config: Failed to open fddi1
      
      when memory beyond 4GiB is handed out to devices that can only do 32-bit
      addressing.
      
      This updates commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
      DMA32.").
      
      References:
      
      [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
          Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
          "Memory Map", pp. 34-38
      
      [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
          Corporation, 18 May 2004, Section 3: "Physical Description",
          "Supported DRAM", p. 23
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Patchwork: https://patchwork.linux-mips.org/patch/21108/
      References: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      e4849aff
    • M
      MIPS: SiByte: Enable ZONE_DMA32 for LittleSur · 756d6d83
      Maciej W. Rozycki 提交于
      The LittleSur board is marked for high memory support and therefore
      clearly must provide a way to have enough memory installed for some to
      be present outside the low 4GiB physical address range.  With the memory
      map of the BCM1250 SOC it has been built around it means over 1GiB of
      actual DRAM, as only the first 1GiB is mapped in the low 4GiB physical
      address range[1].
      
      Complement commit cce335ae ("[MIPS] 64-bit Sibyte kernels need
      DMA32.") then and also enable ZONE_DMA32 for LittleSur.
      
      References:
      
      [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
          Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
          "Memory Map", pp. 34-38
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Patchwork: https://patchwork.linux-mips.org/patch/21107/
      Fixes: cce335ae ("[MIPS] 64-bit Sibyte kernels need DMA32.")
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      756d6d83
  4. 13 11月, 2018 3 次提交
  5. 10 11月, 2018 4 次提交
  6. 09 11月, 2018 1 次提交
  7. 06 11月, 2018 1 次提交
  8. 31 10月, 2018 2 次提交
  9. 27 9月, 2018 1 次提交
    • Y
      MIPS: Add Kconfig variable for CPUs with unaligned load/store instructions · 932afdee
      Yasha Cherikovsky 提交于
      MIPSR6 CPUs do not support unaligned load/store instructions
      (LWL, LWR, SWL, SWR and LDL, LDR, SDL, SDR for 64bit).
      
      Currently the MIPS tree has some special cases to avoid these
      instructions, and the code is testing for !CONFIG_CPU_MIPSR6.
      
      This patch declares a new Kconfig variable:
      CONFIG_CPU_HAS_LOAD_STORE_LR.
      This variable indicates that the CPU supports these instructions.
      
      Then, the patch does the following:
      - Carefully selects this option on all CPUs except MIPSR6.
      - Switches all the special cases to test for the new variable,
        and inverts the logic:
          '#ifndef CONFIG_CPU_MIPSR6' turns into
          '#ifdef CONFIG_CPU_HAS_LOAD_STORE_LR'
          and vice-versa.
      
      Also, when this variable is NOT selected (e.g. MIPSR6),
      CONFIG_GENERIC_CSUM will default to 'y', to compile generic
      C checksum code (instead of special assembly code that uses the
      unsupported instructions).
      
      This commit should not affect any existing CPU, and is required
      for future Lexra CPU support, that misses these instructions too.
      Signed-off-by: NYasha Cherikovsky <yasha.che3@gmail.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20808/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      932afdee
  10. 23 9月, 2018 1 次提交
  11. 20 9月, 2018 4 次提交
  12. 15 9月, 2018 1 次提交
    • M
      mips: switch to NO_BOOTMEM · bcec54bf
      Mike Rapoport 提交于
      MIPS already has memblock support and all the memory is already registered
      with it.
      
      This patch replaces bootmem memory reservations with memblock ones and
      removes the bootmem initialization.
      
      Since memblock allocates memory in top-down mode, we ensure that memblock
      limit is max_low_pfn to prevent allocations from the high memory.
      
      To have the exceptions base in the lower 512M of the physical memory, its
      allocation in arch/mips/kernel/traps.c::traps_init() is using bottom-up
      mode.
      Signed-off-by: NMike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20560/
      Cc: Serge Semin <fancer.lancer@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-mm@kvack.org
      Cc: linux-kernel@vger.kernel.org
      bcec54bf
  13. 08 9月, 2018 1 次提交
  14. 31 8月, 2018 1 次提交
    • P
      MIPS: Use GENERIC_IOMAP · b962aeb0
      Paul Burton 提交于
      MIPS has a copy of lib/iomap.c with minor alterations, none of which are
      necessary given appropriate definitions of PIO_OFFSET, PIO_MASK &
      PIO_RESERVED. Provide such definitions, select GENERIC_IOMAP & remove
      arch/mips/lib/iomap.c to cut back on the needless duplication.
      
      The one change this does make is to our mmio_{in,out}s[bwl] functions,
      which began to deviate from their generic counterparts with commit
      0845bb72 ("MIPS: iomap: Use __mem_{read,write}{b,w,l} for MMIO"). I
      suspect that this commit was incorrect, and that the SEAD-3 platform
      should have instead selected CONFIG_SWAP_IO_SPACE. Since the SEAD-3
      platform code is now gone & the board is instead supported by the
      generic platform (CONFIG_MIPS_GENERIC) which selects
      CONFIG_SWAP_IO_SPACE anyway, this shouldn't be a problem any more.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20342/
      Cc: linux-mips@linux-mips.org
      b962aeb0
  15. 22 8月, 2018 1 次提交
    • P
      MIPS: Workaround GCC __builtin_unreachable reordering bug · 906d441f
      Paul Burton 提交于
      Some versions of GCC for the MIPS architecture suffer from a bug which
      can lead to instructions from beyond an unreachable statement being
      incorrectly reordered into earlier branch delay slots if the unreachable
      statement is the only content of a case in a switch statement. This can
      lead to seemingly random behaviour, such as invalid memory accesses from
      incorrectly reordered loads or stores, and link failures on microMIPS
      builds.
      
      See this potential GCC fix for details:
      
          https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00360.html
      
      Runtime problems resulting from this bug were initially observed using a
      maltasmvp_defconfig v4.4 kernel built using GCC 4.9.2 (from a Codescape
      SDK 2015.06-05 toolchain), with the result being an address exception
      taken after log messages about the L1 caches (during probe of the L2
      cache):
      
          Initmem setup node 0 [mem 0x0000000080000000-0x000000009fffffff]
          VPE topology {2,2} total 4
          Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
          Primary data cache 64kB, 4-way, PIPT, no aliases, linesize 32 bytes
          <AdEL exception here>
      
      This is early enough that the kernel exception vectors are not in use,
      so any further output depends upon the bootloader. This is reproducible
      in QEMU where no further output occurs - ie. the system hangs here.
      Given the nature of the bug it may potentially be hit with differing
      symptoms. The bug is known to affect GCC versions as recent as 7.3, and
      it is unclear whether GCC 8 fixed it or just happens not to encounter
      the bug in the testcase found at the link above due to differing
      optimizations.
      
      This bug can be worked around by placing a volatile asm statement, which
      GCC is prevented from reordering past, prior to the
      __builtin_unreachable call.
      
      That was actually done already for other reasons by commit 173a3efd
      ("bug.h: work around GCC PR82365 in BUG()"), but creates problems for
      microMIPS builds due to the lack of a .insn directive. The microMIPS ISA
      allows for interlinking with regular MIPS32 code by repurposing bit 0 of
      the program counter as an ISA mode bit. To switch modes one changes the
      value of this bit in the PC. However typical branch instructions encode
      their offsets as multiples of 2-byte instruction halfwords, which means
      they cannot change ISA mode - this must be done using either an indirect
      branch (a jump-register in MIPS terminology) or a dedicated jalx
      instruction. In order to ensure that regular branches don't attempt to
      target code in a different ISA which they can't actually switch to, the
      linker will check that branch targets are code in the same ISA as the
      branch.
      
      Unfortunately our empty asm volatile statements don't qualify as code,
      and the link for microMIPS builds fails with errors such as:
      
          arch/mips/mm/dma-default.s:3265: Error: branch to a symbol in another ISA mode
          arch/mips/mm/dma-default.s:5027: Error: branch to a symbol in another ISA mode
      
      Resolve this by adding a .insn directive within the asm statement which
      declares that what comes next is code. This may or may not be true,
      since we don't really know what comes next, but as this code is in an
      unreachable path anyway that doesn't matter since we won't execute it.
      
      We do this in asm/compiler.h & select CONFIG_HAVE_ARCH_COMPILER_H in
      order to have this included by linux/compiler_types.h after
      linux/compiler-gcc.h. This will result in asm/compiler.h being included
      in all C compilations via the -include linux/compiler_types.h argument
      in c_flags, which should be harmless.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Fixes: 173a3efd ("bug.h: work around GCC PR82365 in BUG()")
      Patchwork: https://patchwork.linux-mips.org/patch/20270/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-mips@linux-mips.org
      906d441f
  16. 02 8月, 2018 3 次提交
  17. 31 7月, 2018 3 次提交
    • MIPS: Loongson: Set Loongson32 to MIPS32R1 · 968dc5a0
      谢致邦 (XIE Zhibang) 提交于
      LS232 (Loonson 2-issue 32-bit, also called GS232 (Godson 2-issue 32-bit))
      is the CPU core (microarchitecture) of Loongson 1A/1B/1C.
      
      According to "LS232 用户手册 (LS232 User Manual)", LS232 implements the
      MIPS32 Release 1 instruction set, and part of the MIPS32 Release 2
      instruction set.
      
      In the manual, LS232 implements all of the MIPS32R2 instruction set
      except the FPU instructions, and LS232 also implements 5 FPU
      instructions of the MIPS32R2 instruction set: CEIL.L.fmt, CVT.L.fmt,
      FLOOR.L.fmt, TRUNC.L.fmt, and ROUND.L.fmt.
      
      But a bug of the DI instruction has been found during tests, the DI
      instruction can not disable interrupts in arch_local_irq_disable() with
      CONFIG_PREEMPT_NONE=y and CFLAGS='-mno-branch-likely' in some cases.
      
      [paul.burton@mips.com:
        - Remove the _MIPS_ISA redefinition to match the change made for the
          generic MIPSr1 CPUs by commit 344ebf09 ("MIPS: Always use
          -march=<arch>, not -<arch> shortcuts").]
      Signed-off-by: N谢致邦 (XIE Zhibang) <Yeking@Red54.com>
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/16155/
      Cc: linux-mips@linux-mips.org
      Cc: ralf@linux-mips.org
      968dc5a0
    • P
      MIPS: generic: Select MIPS_AUTO_PFN_OFFSET · 0211d49e
      Paul Burton 提交于
      Enable CONFIG_MIPS_AUTO_PFN_OFFSET for the generic platform, allowing
      it to avoid wasted book-keeping for pages with addresses lower than the
      physical base address of memory.
      
      This has a minimal impact on kernel text size, with 64r6el_defconfig
      gaining 0.1% in size as reported by bloat-o-meter:
      
        add/remove: 4/1 grow/shrink: 345/13 up/down: 9017/-392 (8625)
        Function                                     old     new   delta
        pcpu_setup_first_chunk                      1444    1780    +336
        pcpu_alloc_first_chunk                       864    1136    +272
        start_kernel                                1064    1288    +224
        initcall_blacklist                           224     372    +148
        try_fill_recv                               2088    2184     +96
        ...
        Total: Before=8457273, After=8465898, chg +0.10%
      
      The gain for systems with large offsets to physical memory & the ability
      to continue using generic kernels on such systems seems well worth this
      small cost.
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Suggested-by: NVladimir Kondratiev <vladimir.kondratiev@intel.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20049/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      0211d49e
    • P
      MIPS: Allow auto-dection of ARCH_PFN_OFFSET & PHYS_OFFSET · 6c359eb1
      Paul Burton 提交于
      On systems where physical memory begins at a non-zero address, defining
      PHYS_OFFSET (which influences ARCH_PFN_OFFSET) can save us time & memory
      by avoiding book-keeping for pages from address zero to the start of
      memory.
      
      Some MIPS platforms already make use of this, but with the definition of
      PHYS_OFFSET being compile-time constant it hasn't been possible to
      enable this optimization for a kernel which may run on systems with
      varying physical memory base addresses.
      
      Introduce a new Kconfig option CONFIG_MIPS_AUTO_PFN_OFFSET which, when
      enabled, makes ARCH_PFN_OFFSET a variable & detects it from the boot
      memory map (which for example may have been populated from DT). The
      relationship with PHYS_OFFSET is reversed, with PHYS_OFFSET now being
      based on ARCH_PFN_OFFSET. This is because ARCH_PFN_OFFSET is used far
      more often, so avoiding the need for runtime calculation gives us a
      smaller impact on kernel text size (0.1% rather than 0.15% for
      64r6el_defconfig).
      Signed-off-by: NPaul Burton <paul.burton@mips.com>
      Suggested-by: NVladimir Kondratiev <vladimir.kondratiev@intel.com>
      Patchwork: https://patchwork.linux-mips.org/patch/20048/
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      6c359eb1
  18. 25 7月, 2018 3 次提交
  19. 25 6月, 2018 6 次提交