1. 21 Nov, 2018 5 commits
    • Paul Burton's avatar
      MIPS: malta: Use img-ascii-lcd driver for LCD display · 0b003749
      Paul Burton authored
      Remove the Malta display platform code in favour of probing the
      img-ascii-lcd driver via device tree. This reduces the amount of
      platform code & the img-ascii-lcd driver offers us advantages in terms
      of code sharing with other boards & functionality such as changing the
      displayed message via sysfs. Defconfigs are untouched because the driver
      already defaults y on when CONFIG_MIPS_MALTA=y.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21182/
      Cc: linux-mips@linux-mips.org
      0b003749
    • Paul Burton's avatar
      MIPS: ptrace: introduce NT_MIPS_MSA regset · 3cd64083
      Paul Burton authored
      The current methods for obtaining FP context via ptrace only provide
      either 32 or 64 bits per data register. With MSA, where vector registers
      are aliased with scalar FP data registers, those registers are 128 bits
      wide. Thus a new mechanism is required for userland to access those
      registers via ptrace. This patch introduces an NT_MIPS_MSA regset which
      provides, in this order:
      
        - The full 128 bits value of each vector register, in native
          endianness saved as though elements are doubles. That is, the format
          of each vector register is as would be obtained by saving it to
          memory using an st.d instruction.
      
        - The 32 bit scalar FP implementation register (FIR).
      
        - The 32 bit scalar FP control & status register (FCSR).
      
        - The 32 bit MSA implementation register (MSAIR).
      
        - The 32 bit MSA control & status register (MSACSR).
      
      The provision of the FIR & FCSR registers in addition to the MSA
      equivalents allows scalar FP context to be retrieved as a subset of
      the context available via this regset. Along with the MSA equivalents
      they also nicely form the final 128 bit "register" of the regset.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21180/
      Cc: linux-mips@linux-mips.org
      3cd64083
    • Huacai Chen's avatar
      MIPS: Align kernel load address to 64KB · bec0de4c
      Huacai Chen authored
      KEXEC needs the new kernel's load address to be aligned on a page
      boundary (see sanity_check_segment_list()), but on MIPS the default
      vmlinuz load address is only explicitly aligned to 16 bytes.
      
      Since the largest PAGE_SIZE supported by MIPS kernels is 64KB, increase
      the alignment calculated by calc_vmlinuz_load_addr to 64KB.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21131/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: Steven J . Hill <Steven.Hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: <stable@vger.kernel.org> # 2.6.36+
      bec0de4c
    • Huacai Chen's avatar
      MIPS: Ensure pmd_present() returns false after pmd_mknotpresent() · 92aa0718
      Huacai Chen authored
      This patch is borrowed from ARM64 to ensure pmd_present() returns false
      after pmd_mknotpresent(). This is needed for THP.
      
      References: 5bb1cc0f ("arm64: Ensure pmd_present() returns false after pmd_mknotpresent()")
      Reviewed-by: default avatarJames Hogan <jhogan@kernel.org>
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21135/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: Steven J . Hill <Steven.Hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: <stable@vger.kernel.org> # 3.8+
      92aa0718
    • Huacai Chen's avatar
      MIPS: c-r4k: Add r4k_blast_scache_node for Loongson-3 · bb53fdf3
      Huacai Chen authored
      For multi-node Loongson-3 (NUMA configuration), r4k_blast_scache() can
      only flush Node-0's scache. So we add r4k_blast_scache_node() by using
      (CAC_BASE | (node_id << NODE_ADDRSPACE_SHIFT)) instead of CKSEG0 as the
      start address.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      [paul.burton@mips.com: Include asm/mmzone.h from asm/r4kcache.h for
      		       nid_to_addrbase(). Add asm/mach-generic/mmzone.h
      		       to allow inclusion for all platforms.]
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21129/
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: James Hogan <james.hogan@mips.com>
      Cc: Steven J . Hill <Steven.Hill@cavium.com>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: <stable@vger.kernel.org> # 3.15+
      bb53fdf3
  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 4 commits
  6. 10 Nov, 2018 3 commits
  7. 09 Nov, 2018 19 commits
    • Paul Burton's avatar
      MIPS: Avoid using .set mips0 to restore ISA · 378ed6f0
      Paul Burton authored
      We currently have 2 commonly used methods for switching ISA within
      assembly code, then restoring the original ISA.
      
        1) Using a pair of .set push & .set pop directives. For example:
      
           .set	push
           .set	mips32r2
           <some_insn>
           .set	pop
      
        2) Using .set mips0 to restore the ISA originally specified on the
           command line. For example:
      
           .set	mips32r2
           <some_insn>
           .set	mips0
      
      Unfortunately method 2 does not work with nanoMIPS toolchains, where the
      assembler rejects the .set mips0 directive like so:
      
           Error: cannot change ISA from nanoMIPS to mips0
      
      In preparation for supporting nanoMIPS builds, switch all instances of
      method 2 in generic non-platform-specific code to use push & pop as in
      method 1 instead. The .set push & .set pop is arguably cleaner anyway,
      and if nothing else it's good to consistently use one method.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21037/
      Cc: linux-mips@linux-mips.org
      378ed6f0
    • Paul Burton's avatar
      MIPS: Allow FP support to be disabled · 183b40f9
      Paul Burton authored
      Allow the user to configure the kernel to omit support for floating
      point, by setting CONFIG_MIPS_FP_SUPPORT=n. In an attempt to avoid
      problems for users who don't understand the impact of this, only expose
      the option when CONFIG_EXPERT=y.
      
      When CONFIG_MIPS_FP_SUPPORT=n all support for FPU hardware, FPU
      emulation & FP context will be removed from the kernel. If a userland
      program attempts to execute a floating point instruction it will receive
      a SIGILL.
      
      Setting CONFIG_MIPS_FP_SUPPORT=n shaves around 112KB from a
      64r6el_defconfig build using GCC 8.1.0.
      
      This also helps prepare us for supporting the nanoMIPS ISA, for which
      floating point support has not been finalized.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21014/
      Cc: linux-mips@linux-mips.org
      183b40f9
    • Paul Burton's avatar
      MIPS: Remove struct task_struct fpu state when CONFIG_MIPS_FP_SUPPORT=n · 2725f377
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point & so don't
      need to preserve floating point context for tasks. Remove that context
      from struct task_struct.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21013/
      Cc: linux-mips@linux-mips.org
      2725f377
    • Paul Burton's avatar
      MIPS: Don't compile math-emu when CONFIG_MIPS_FP_SUPPORT=n · 42b10815
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so
      there's no point compiling in our FPU emulator. Avoid doing so,
      providing stub versions of dsemul cleanup functions that are called from
      signal & task handling code.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21012/
      Cc: linux-mips@linux-mips.org
      42b10815
    • Paul Burton's avatar
      MIPS: Avoid FCSR sanitization when CONFIG_MIPS_FP_SUPPORT=n · 36a49803
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we
      don't need to worry about floating point exceptions pending in the
      Floating point Control & Status Register (FCSR) during switch_to(). Stub
      out the __sanitize_fcr31() macro in this case.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21010/
      Cc: linux-mips@linux-mips.org
      36a49803
    • Paul Burton's avatar
      MIPS: Avoid FP ELF checks when CONFIG_MIPS_FP_SUPPORT=n · ea6a3737
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we can
      avoid needless checks of ELF headers specifying the FP ABI or NaN
      encoding to use. Deselect CONFIG_ARCH_BINFMT_ELF_STATE in this case to
      avoid the need for our arch_elf_pt_proc() & arch_check_elf() functions,
      and stub out the mips_set_personality_nan() & mips_set_personality_fp()
      functions such that SET_PERSONALITY() doesn't need to worry about any of
      this.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21011/
      Cc: linux-mips@linux-mips.org
      ea6a3737
    • Paul Burton's avatar
      MIPS: signal: Remove FP context support when CONFIG_MIPS_FP_SUPPORT=n · 4eec81d7
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so
      there's no need to save & restore floating point context around signals.
      This prepares us for the removal of FP context from struct task_struct
      later.
      
      Since MSA context is a superset of FP context support for it similarly
      needs to be removed when MSA/FP support is disabled.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21009/
      Cc: linux-mips@linux-mips.org
      4eec81d7
    • Paul Burton's avatar
      MIPS: ptrace: Remove FP support when CONFIG_MIPS_FP_SUPPORT=n · 6c79759e
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove
      the related ptrace support. Besides removing code which should not be
      needed, this prepares us for the removal of FPU state in struct
      task_struct which this code requires.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21008/
      Cc: linux-mips@linux-mips.org
      6c79759e
    • Paul Burton's avatar
      MIPS: unaligned: Remove FP & MSA code when unsupported · 85164fd8
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove
      support for floating point instructions from emulate_load_store_insn() &
      emulate_load_store_microMIPS(). This code should not be needed & relies
      upon access to FPU state in struct task_struct which will later be
      removed.
      
      Similarly & for the same reasons, when CONFIG_CPU_HAS_MSA=n remove
      support for MSA instructions. Since MSA support depends upon FP support
      this is implied when CONFIG_MIPS_FP_SUPPORT=n.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21020/
      Cc: linux-mips@linux-mips.org
      85164fd8
    • Paul Burton's avatar
      MIPS: branch: Remove FP branch handling when CONFIG_MIPS_FP_SUPPORT=n · 6a1cc218
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so remove
      the floating point branch support from __compute_return_epc_for_insn() &
      __mm_isBranchInstr(). This code should never be needed & more
      importantly relies upon FPU state in struct task_struct which will later
      be removed.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21017/
      Cc: linux-mips@linux-mips.org
      6a1cc218
    • Paul Burton's avatar
      MIPS: traps: Never enable FPU when CONFIG_MIPS_FP_SUPPORT=n · 5328f742
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so we'll
      never need to enable the FPU. Avoid doing so on a Co-Processor Unusable
      exception (do_cpu), and remove the Floating Point Exception handler
      (do_fpe) which should never be executed when the FPU is disabled.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21007/
      Cc: linux-mips@linux-mips.org
      5328f742
    • Paul Burton's avatar
      MIPS: cpu-probe: Avoid probing FPU when CONFIG_MIPS_FP_SUPPORT=n · b2e628a8
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point so there's
      no point in attempting to detect an FPU. Avoid doing so.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21021/
      Cc: linux-mips@linux-mips.org
      b2e628a8
    • Paul Burton's avatar
      MIPS: Stub asm/fpu.h functions · 9ec55930
      Paul Burton authored
      Provide stub versions of functions in asm/fpu.h when
      CONFIG_MIPS_FP_SUPPORT=n. Two approaches are taken to the functions
      provided:
      
        - Functions which can safely be called when FP is not enabled provide
          stubs which return an error where appropriate or are simple no-ops.
      
        - Functions which should only ever be called in cases where
          cpu_has_fpu is true or the FPU was successfully enabled are declared
          extern & annotated with __compiletime_error() to detect cases in
          which they are called incorrectly.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21006/
      Cc: linux-mips@linux-mips.org
      9ec55930
    • Paul Burton's avatar
      MIPS: Hardcode cpu_has_fpu=0 when CONFIG_MIPS_FP_SUPPORT=n · b372e83b
      Paul Burton authored
      When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so
      there's no point in detecting presence of an FPU. Hardcode
      cpu_has_fpu=0 such that we optimize out code that makes use of the FPU.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21005/
      Cc: linux-mips@linux-mips.org
      b372e83b
    • Paul Burton's avatar
      MIPS: Introduce CONFIG_MIPS_FP_SUPPORT · c92e47e5
      Paul Burton authored
      Introduce a Kconfig variable that will indicate whether to include
      support for floating point in the kernel. For now this is always
      enabled, and will be made configurable in a later patch.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21016/
      Cc: linux-mips@linux-mips.org
      c92e47e5
    • Paul Burton's avatar
      MIPS: Better abstract R2300 FPU usage in Kconfig · 97f7dcbf
      Paul Burton authored
      Introduce a CONFIG_CPU_R2300_FPU Kconfig symbol mirroring the existing
      CONFIG_CPU_R4K_FPU, and use it to determine whether to build r4k_fpu.S.
      
      This removes the duplicate R3000 & TX39XX cases in
      arch/mips/kernel/Makefile and prepares us for the possibility of
      disabling FP support later.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21004/
      Cc: linux-mips@linux-mips.org
      97f7dcbf
    • Paul Burton's avatar
      MIPS: Drop forward declarations of sigcontext in asm/fpu.h · 7d3713a4
      Paul Burton authored
      asm/fpu.h contains forward declarations of struct sigcontext & struct
      sigcontext32 which appear to have been unused since commit 137f6f3e
      ("MIPS: Cleanup signal code initialization"). Remove the dead code.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21015/
      Cc: linux-mips@linux-mips.org
      7d3713a4
    • Paul Burton's avatar
      MIPS: Ensure emulated FP sets PF_USED_MATH · 1975ed43
      Paul Burton authored
      Emulated floating point instructions don't ensure that the PF_USED_MATH
      flag is set for the task. This results in a couple of inconsistencies:
      
        - ptrace will return the default initial state of FP registers rather
          than the values actually stored in struct thread_struct, hiding
          state that has been updated by emulated floating point instructions.
      
        - If a task migrates to a CPU with an FPU after having emulated
          floating point instructions then its floating point register state
          will be reset to the default ~0 bit pattern, losing state from the
          emulated instructions.
      
      Fix this by calling init_fp_ctx() from fpu_emulator_cop1Handler() to
      consistently initialize FP state if it was previously uninitialized,
      setting the PF_USED_MATH flag in the process.
      
      All callers of fpu_emulator_cop1Handler() either call lose_fpu(1) before
      it in order to save any live FPU registers to struct thread_struct, or
      in the case of do_cpu() already know that the task does not own an FPU
      so lose_fpu(1) would be a no-op. Since we know that saving FP context
      will be unnecessary in the case where FP context was just initialized we
      move this call into fpu_emulator_cop1Handler() too, providing
      consistency & avoiding needless duplication.
      
      Calls to own_fpu(1) are common after return from
      fpu_emulator_cop1Handler() too, but this would not be a no-op in the
      do_cpu() case so these are left as-is. A potential future improvement
      could be to have fpu_emulator_cop1Handler() restore FPU state
      automatically only if it saved it, though this may not be optimal if
      some callers are better off without their current calls to own_fpu(1).
      One potential example of this could be mipsr2_decoder() which as-is
      could end up saving & restoring FP context repeatedly & unnecessarily if
      emulating multiple FP instructions.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21003/
      Cc: linux-mips@linux-mips.org
      1975ed43
    • Paul Burton's avatar
      MIPS: Simplify FP context initialization · cc97ab23
      Paul Burton authored
      MIPS has up until now had 3 different ways for a task's floating point
      context to be initialized:
      
        - If the task's first use of FP involves it gaining ownership of an
          FPU then _init_fpu() is used to initialize the FPU's registers such
          that they all contain ~0, and the FPU registers will be stored to
          struct thread_info later (eg. when context switching).
      
        - If the task first uses FP on a CPU without an associated FPU then
          fpu_emulator_init_fpu() initializes the task's floating point
          register state in struct thread_info such that all floating point
          register contain the bit pattern 0x7ff800007ff80000, different to
          the _init_fpu() behaviour.
      
        - If a task's floating point context is first accessed via ptrace then
          init_fp_ctx() initializes the floating point register state in
          struct thread_info to ~0, giving equivalent state to _init_fpu().
      
      The _init_fpu() path has 2 separate implementations - one for r2k/r3k
      style systems & one for r4k style systems. The _init_fpu() path also
      requires that we be careful to clear & restore the value of the
      Config5.FRE bit on modern systems in order to avoid inadvertently
      triggering floating point exceptions.
      
      None of this code is in a performance critical hot path - it runs only
      the first time a task uses floating point. As such it doesn't seem to
      warrant the complications of maintaining the _init_fpu() path.
      
      Remove _init_fpu() & fpu_emulator_init_fpu(), instead using
      init_fp_ctx() consistently to initialize floating point register state
      in struct thread_info. Upon a task's first use of floating point this
      will typically mean that we initialize state in memory & then load it
      into FPU registers using _restore_fp() just as we would on a context
      switch. For other paths such as __compute_return_epc_for_insn() or
      mipsr2_decoder() this results in a significant simplification of the
      work to be done.
      Signed-off-by: default avatarPaul Burton <paul.burton@mips.com>
      Patchwork: https://patchwork.linux-mips.org/patch/21002/
      Cc: linux-mips@linux-mips.org
      cc97ab23
  8. 08 Nov, 2018 2 commits