1. 21 Nov, 2018 31 commits
  2. 20 Nov, 2018 1 commit
  3. 19 Nov, 2018 3 commits
  4. 15 Nov, 2018 3 commits
    • Maciej W. Rozycki's avatar
      MIPS: SiByte: Enable swiotlb for SWARM, LittleSur and BigSur · e4849aff
      Maciej W. Rozycki authored
      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: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reviewed-by: default avatarChristoph 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
    • Maciej W. Rozycki's avatar
      MIPS: SiByte: Enable ZONE_DMA32 for LittleSur · 756d6d83
      Maciej W. Rozycki authored
      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: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reviewed-by: default avatarChristoph 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
    • Maciej W. Rozycki's avatar
      MIPS: SiByte: Set 32-bit bus mask for BCM1250 PCI · 3747b9d6
      Maciej W. Rozycki authored
      The Broadcom SiByte BCM1250, BCM1125H and BCM1125 SOCs have an onchip
      32-bit PCI host bridge, and the two former SOCs also have an onchip HT
      host bridge.  The HT host bridge, where present, appears in the PCI
      configuration space as if it was a device on the 32-bit PCI bus behind
      the PCI host bridge, however at the hardware level its signals are
      routed separately, so these two devices are actually peer host bridges.
      
      As documented[1] and observed in reality the 32-bit PCI host bridge does
      not support 64-bit addressing as it does not support the Dual Address
      Cycle (DAC) PCI command, and naturally, being 32-bit only, it has no
      means to carry the high 32 address bits otherwise.  However the DRAM
      controller also included in the SOC 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.  Consequently if the
      maximum amount of memory has been installed, then it will span up to
      19GiB.
      
      Contrariwise, the HT host bridge does support full 40-bit addressing
      defined by the HyperTransport (formerly LDT) specification the bridge
      adheres to, depending on the peripherals revision of the SOC[2] either
      revision 0.17[3] or revision 1.03[4].  This allows addressing any and
      all memory installed, and well beyond.
      
      Set the bus mask then to limit DMA addressing to 32 bits for all the
      devices down the 32-bit PCI host bridge, excluding however any devices
      that are down the HT host bridge.
      
      References:
      
      [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
          Broadcom Corporation, 21 Oct 2002, Section 8: "PCI Bus and
          HyperTransport Fabric", "Introduction", p. 190
      
      [2] same, Table 140: "HyperTransport Configuration Header (Type 1)", p.
          245
      
      [3] "Lightning Data Transport IO Specification", Revision 0.17, Advanced
          Micro Devices, 21 Jan 2000, Section 3.2.1.2 "Command Packet", p. 8
      
      [4] "HyperTransport I/O Link Specification", Revision 1.03,
          HyperTransport Technology Consortium, 10 Oct 2001, Section 3.2.1.2
          "Request Packet", pp. 27-28
      Signed-off-by: default avatarMaciej W. Rozycki <macro@linux-mips.org>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Patchwork: https://patchwork.linux-mips.org/patch/21106/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      3747b9d6
  5. 12 Nov, 2018 2 commits
    • Paul Burton's avatar
      lib/gcd: Remove use of CPU_NO_EFFICIENT_FFS macro · d0894409
      Paul Burton authored
      The CPU_NO_EFFICIENT_FFS pre-processor macro is no longer used, with all
      architectures toggling the equivalent Kconfig symbol
      CONFIG_CPU_NO_EFFICIENT_FFS instead. Remove our check for the unused
      macro.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21046/
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      d0894409
    • Paul Burton's avatar
      MIPS: Use Kconfig to select CPU_NO_EFFICIENT_FFS · 57eeaced
      Paul Burton authored
      Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
      configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
      in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.
      
      The latter only works if a platform has an cpu-feature-overrides.h
      header which defines cpu_has_mips* macros, which are not generally
      needed. There are many cases where we know that the target ISA for a
      kernel build is MIPS32r1 or later & thus includes the CLZ instruction,
      without requiring any overrides from the platform. Using Kconfig allows
      us to take those into account, and more naturally make a decision about
      instruction support using information about the target ISA.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21045/
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      57eeaced