1. 30 8月, 2017 2 次提交
  2. 29 8月, 2017 2 次提交
    • P
      MIPS: Move r4k FP code from r4k_switch.S to r4k_fpu.S · a2aea699
      Paul Burton 提交于
      Move _save_fp(), _restore_fp(), _save_msa(), _restore_msa(),
      _init_msa_upper() & _init_fpu() out of r4k_switch.S & into r4k_fpu.S.
      This allows us to clean up the way in which Octeon includes the default
      r4k implementations of these FP functions despite replacing resume(),
      and makes CONFIG_R4K_FPU more straightforwardly represent all
      configurations that have an R4K-style FPU, including Octeon.
      
      Besides cleaning up this will be useful for later patches which disable
      FP support.
      
      [ralf@linux-mips.org: Fixed build issues reported by Arnd Bergmann
      <arnd@arndb.de>]
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16237/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a2aea699
    • P
      MIPS: Remove unused R6000 support · 3b2db173
      Paul Burton 提交于
      The kernel contains a small amount of incomplete code aimed at
      supporting old R6000 CPUs. This is:
      
        - Unused, as no machine selects CONFIG_SYS_HAS_CPU_R6000.
      
        - Broken, since there are glaring errors such as r6000_fpu.S moving
          the FCSR register to t1, then ignoring it & instead saving t0 into
          struct sigcontext...
      
        - A maintenance headache, since it's code that nobody can test which
          nevertheless imposes constraints on code which it shares with other
          machines.
      
      Remove this incomplete & broken R6000 CPU support in order to clean up
      and in preparation for changes which will no longer need to consider
      dragging the pretense of R6000 support along with them.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16236/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3b2db173
  3. 08 8月, 2017 1 次提交
    • P
      MIPS: Prevent building MT support for microMIPS kernels · 527f1028
      Paul Burton 提交于
      We don't currently support the MT ASE for microMIPS kernels, and there
      are no CPUs currently in existence that use both. They can however both
      be enabled in Kconfig, resulting in build failures such as:
      
        AS      arch/mips/kernel/cps-vec.o
      arch/mips/kernel/cps-vec.S: Assembler messages:
      arch/mips/kernel/cps-vec.S:242: Warning: the 32-bit microMIPS architecture does not support the `mt' extension
      arch/mips/kernel/cps-vec.S:276: Error: unrecognized opcode `mttc0 $13,$2,2'
      arch/mips/kernel/cps-vec.S:282: Error: unrecognized opcode `mttc0 $8,$1,2'
      arch/mips/kernel/cps-vec.S:285: Error: unrecognized opcode `mttc0 $0,$2,1'
      ...
      
      Fix this by preventing MT from being enabled when targeting microMIPS.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16951/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      527f1028
  4. 11 7月, 2017 1 次提交
  5. 29 6月, 2017 4 次提交
    • P
      MIPS: Allow storing pgd in C0_CONTEXT for MIPSr6 · cebf8c0f
      Paul Burton 提交于
      CONFIG_MIPS_PGD_C0_CONTEXT, which allows a pointer to the page directory
      to be stored in the cop0 Context register when enabled, was previously
      only allowed for MIPSr2. MIPSr6 is just as able to make use of it, so
      allow it there too.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16204/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      cebf8c0f
    • P
      MIPS: CPS: Select CONFIG_SYS_SUPPORTS_SCHED_SMT for MIPSr6 · c8b7712c
      Paul Burton 提交于
      Prior to MIPSr6 multithreading is only supported if CONFIG_MIPS_MT_SMP
      is enabled, so CONFIG_MIPS_MT_SMP selects CONFIG_SYS_SUPPORTS_SCHED_SMT.
      With MIPSr6 the CONFIG_MIPS_CPS SMP implementation always supports
      multithreading, so have it select CONFIG_SYS_SUPPORTS_SCHED_SMT in order
      to allow the scheduler to make better informed decisions on
      multithreaded MIPSr6 systems (for example those using I6400 or I6500
      CPUs).
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16195/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c8b7712c
    • P
      MIPS: Use queued spinlocks (qspinlock) · 0b17c967
      Paul Burton 提交于
      This patch switches MIPS to make use of generically implemented queued
      spinlocks, rather than the ticket spinlocks used previously. This allows
      us to drop a whole load of inline assembly, share more generic code, and
      is also a performance win.
      
      Results from running the AIM7 short workload on a MIPS Creator Ci40 (ie.
      2 core 2 thread interAptiv CPU clocked at 546MHz) with v4.12-rc4
      pistachio_defconfig, with ftrace disabled due to a current bug, and both
      with & without use of queued rwlocks & spinlocks:
      
        Forks | v4.12-rc4 | +qlocks  | Change
       -------|-----------|----------|--------
           10 | 52630.32  | 53316.31 | +1.01%
           20 | 51777.80  | 52623.15 | +1.02%
           30 | 51645.92  | 52517.26 | +1.02%
           40 | 51634.88  | 52419.89 | +1.02%
           50 | 51506.75  | 52307.81 | +1.02%
           60 | 51500.74  | 52322.72 | +1.02%
           70 | 51434.81  | 52288.60 | +1.02%
           80 | 51423.22  | 52434.85 | +1.02%
           90 | 51428.65  | 52410.10 | +1.02%
      
      The kernels used for these tests also had my "MIPS: Hardcode cpu_has_*
      where known at compile time due to ISA" patch applied, which allows the
      kernel_uses_llsc checks in cmpxchg() & xchg() to be optimised away at
      compile time.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16358/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0b17c967
    • P
      MIPS: Use queued read/write locks (qrwlock) · 25da4e9d
      Paul Burton 提交于
      This patch switches MIPS to make use of generically implemented queued
      read/write locks, rather than the custom implementation used previously.
      This allows us to drop a whole load of inline assembly, share more
      generic code, and is also a performance win.
      
      Results from running the AIM7 short workload on a MIPS Creator Ci40 (ie.
      2 core 2 thread interAptiv CPU clocked at 546MHz) with v4.12-rc4
      pistachio_defconfig, with ftrace disabled due to a current bug, and both
      with & without use of queued rwlocks & spinlocks:
      
        Forks | v4.12-rc4 | +qlocks  | Change
       -------|-----------|----------|--------
           10 | 52630.32  | 53316.31 | +1.01%
           20 | 51777.80  | 52623.15 | +1.02%
           30 | 51645.92  | 52517.26 | +1.02%
           40 | 51634.88  | 52419.89 | +1.02%
           50 | 51506.75  | 52307.81 | +1.02%
           60 | 51500.74  | 52322.72 | +1.02%
           70 | 51434.81  | 52288.60 | +1.02%
           80 | 51423.22  | 52434.85 | +1.02%
           90 | 51428.65  | 52410.10 | +1.02%
      
      The kernels used for these tests also had my "MIPS: Hardcode cpu_has_*
      where known at compile time due to ISA" patch applied, which allows the
      kernel_uses_llsc checks in cmpxchg() & xchg() to be optimised away at
      compile time.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16357/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      25da4e9d
  6. 28 6月, 2017 1 次提交
    • D
      MIPS: Add support for eBPF JIT. · f381bf6d
      David Daney 提交于
      Since the eBPF machine has 64-bit registers, we only support this in
      64-bit kernels.  As of the writing of this commit log test-bpf is showing:
      
        test_bpf: Summary: 316 PASSED, 0 FAILED, [308/308 JIT'ed]
      
      All current test cases are successfully compiled.
      
      Many examples in samples/bpf are usable, specifically tracex5 which
      uses tail calls works.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/16369/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      f381bf6d
  7. 27 6月, 2017 1 次提交
  8. 22 5月, 2017 1 次提交
  9. 27 4月, 2017 2 次提交
  10. 13 4月, 2017 1 次提交
  11. 12 4月, 2017 1 次提交
  12. 10 4月, 2017 3 次提交
  13. 06 4月, 2017 1 次提交
  14. 28 3月, 2017 1 次提交
    • J
      MIPS: Allow KVM to be enabled on Octeon CPUs · 0ae3abcd
      James Hogan 提交于
      Octeon III has VZ ASE support, so allow KVM to be enabled on Octeon
      CPUs as it should now be functional.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Radim Krčmář" <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      0ae3abcd
  15. 08 3月, 2017 1 次提交
  16. 09 2月, 2017 1 次提交
  17. 25 1月, 2017 1 次提交
  18. 03 1月, 2017 7 次提交
  19. 10 10月, 2016 1 次提交
  20. 08 10月, 2016 1 次提交
    • V
      atomic64: no need for CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE · 51a02124
      Vineet Gupta 提交于
      This came to light when implementing native 64-bit atomics for ARCv2.
      
      The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
      to check whether atomic64_dec_if_positive() is available.  It seems it
      was needed when not every arch defined it.  However as of current code
      the Kconfig option seems needless
      
       - for CONFIG_GENERIC_ATOMIC64 it is auto-enabled in lib/Kconfig and a
         generic definition of API is present lib/atomic64.c
       - arches with native 64-bit atomics select it in arch/*/Kconfig and
         define the API in their headers
      
      So I see no point in keeping the Kconfig option
      
      Compile tested for:
       - blackfin (CONFIG_GENERIC_ATOMIC64)
       - x86 (!CONFIG_GENERIC_ATOMIC64)
       - ia64
      
      Link: http://lkml.kernel.org/r/1473703083-8625-3-git-send-email-vgupta@synopsys.comSigned-off-by: NVineet Gupta <vgupta@synopsys.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Ming Lin <ming.l@ssi.samsung.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      51a02124
  21. 07 10月, 2016 5 次提交
    • P
      MIPS: generic: Convert SEAD-3 to a generic board · 3f5f0a44
      Paul Burton 提交于
      Convert the MIPS SEAD-3 board support to be a generic board, supported
      by generic kernels.
      
      Because the SEAD-3 boot protocol was defined long ago and we don't want
      to force a switch to the UHI protocol, SEAD-3 is added as a legacy board
      which is detected by reading the REVISION register. This may technically
      not be a valid memory read & future work will include attempting to
      handle that gracefully. In practice since SEAD-3 is the only legacy
      board supported by the generic kernel so far the read will only happen
      on SEAD-3 boards, and even once Malta is converted the same REVISION
      register exists there too. Other boards such as Boston, Ci20 & Ci40 will
      use the UHI boot protocol & thus not run any of the legacy board detect
      functions.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14354/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      3f5f0a44
    • P
      MIPS: generic: Introduce generic DT-based board support · eed0eabd
      Paul Burton 提交于
      Introduce a "generic" platform, which aims to be board-agnostic by
      making use of device trees passed by the boot protocol defined in the
      MIPS UHI (Universal Hosting Interface) specification. Provision is made
      for supporting boards which use a legacy boot protocol that can't be
      changed, but adding support for such boards or any others is left to
      followon patches.
      
      Right now the built kernels expect to be loaded to 0x80100000, ie. in
      kseg0. This is fine for the vast majority of MIPS platforms, but
      nevertheless it would be good to remove this limitation in the future by
      mapping the kernel via the TLB such that it can be loaded anywhere & map
      itself appropriately.
      
      Configuration is handled by dynamically generating configs using
      scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
      makes use of it. This allows for variations upon the configuration, eg.
      differing architecture revisions or subsets of driver support for
      differing boards, to be handled without having a large number of
      defconfig files.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      eed0eabd
    • P
      MIPS: Support per-device DMA coherence · 20d33064
      Paul Burton 提交于
      On some MIPS systems, a subset of devices may have DMA coherent with CPU
      caches. For example in systems including a MIPS I/O Coherence Unit
      (IOCU), some devices may be connected to that IOCU whilst others are
      not.
      
      Prior to this patch, we have a plat_device_is_coherent() function but no
      implementation which does anything besides return a global true or
      false, optionally chosen at runtime. For devices such as those described
      above this is insufficient.
      
      Fix this by tracking DMA coherence on a per-device basis with a
      dma_coherent field in struct dev_archdata. Setting this from
      arch_setup_dma_ops() takes care of devices which set the dma-coherent
      property via device tree, and any PCI devices beneath a bridge described
      in DT, automatically.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14349/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      20d33064
    • P
      MIPS: PCI: Support generic drivers · 87dd9a4d
      Paul Burton 提交于
      Introduce support for PCI drivers using only functionality provided
      generically by the PCI subsystem, by adding the minimum arch-provided
      functions required.
      
      The driver this has been developed for & tested with the xilinx-pcie on
      a MIPS Boston development board.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14346/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      87dd9a4d
    • P
      MIPS: PCI: Introduce CONFIG_PCI_DRIVERS_LEGACY · c5611df9
      Paul Burton 提交于
      Introduce 2 Kconfig symbols, CONFIG_PCI_DRIVERS_GENERIC &
      CONFIG_PCI_DRIVERS_LEGACY, which indicate whether the system should be
      built to for PCI drivers using the MIPS-specific struct pci_controller
      API (hereafter "legacy" drivers) or more generic drivers using only
      functionality provided by the PCI core (hereafter "generic" drivers).
      
      The Kconfig entries are created such that platforms have to select
      CONFIG_PCI_DRIVERS_GENERIC if they wish to use it - that is, the default
      is CONFIG_PCI_DRIVERS_LEGACY so that existing platforms need no
      modification.
      
      The functions declared in pci.h are rearranged with those provided only
      by pci-legacy.c being guarded by an #ifdef CONFIG_PCI_DRIVERS_LEGACY to
      ensure they are only used in configurations where they are implemented.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14345/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c5611df9
  22. 06 10月, 2016 1 次提交