1. 24 11月, 2014 1 次提交
  2. 20 11月, 2014 2 次提交
  3. 22 9月, 2014 1 次提交
  4. 02 8月, 2014 4 次提交
  5. 31 7月, 2014 1 次提交
    • H
      MIPS: Add Loongson-3B support · e7841be5
      Huacai Chen 提交于
      Loongson-3B is a 8-cores processor. In general it looks like there are
      two Loongson-3A integrated in one chip: 8 cores are separated into two
      groups (two NUMA node), each node has its own local memory.
      
      Of course there are some differences between one Loongson-3B and two
      Loongson-3A. E.g., the base addresses of IPI registers of each node are
      not the same; Loongson-3A use ChipConfig register to enable/disable
      clock, but Loongson-3B use FreqControl register instead.
      
      There are two revision of Loongson-3B, the first revision is called as
      Loongson-3B1000, whose frequency is 1GHz and has a PRid 0x6306, the
      second revision is called as Loongson-3B1500, whose frequency is 1.5GHz
      and has a PRid 0x6307. Both revisions has a bug that clock cannot be
      disabled at runtime, but this will be fixed in future.
      Signed-off-by: NHuacai Chen <chenhc@lemote.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: linux-mips@linux-mips.org
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Patchwork: https://patchwork.linux-mips.org/patch/7188/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e7841be5
  6. 31 5月, 2014 2 次提交
    • D
      MIPS: Add function get_ebase_cpunum · 45b585c8
      David Daney 提交于
      This returns the CPUNum from the low order Ebase bits.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Signed-off-by: NAndreas Herrmann <andreas.herrmann@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: kvm@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/7012/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      45b585c8
    • M
      MIPS: Implement random_get_entropy with CP0 Random · 06947aaa
      Maciej W. Rozycki 提交于
      Update to commit 9c9b415c [MIPS:
      Reimplement get_cycles().]
      
      On systems were for whatever reasons we can't use the cycle counter, fall
      back to the c0_random register as an entropy source.  It has however a
      very small range that makes it suitable for random_get_entropy only and
      not get_cycles.
      
      This optimised version compiles to 8 instructions in the fast path even in
      the worst case of all the conditions to check being variable (including a
      MFC0 move delay slot that is only required for very old processors):
      
           828:	8cf90000 	lw	t9,0(a3)
      			828: R_MIPS_LO16	jiffies
           82c:	40057800 	mfc0	a1,c0_prid
           830:	3c0200ff 	lui	v0,0xff
           834:	00a21024 	and	v0,a1,v0
           838:	1040007d 	beqz	v0,a30 <add_interrupt_randomness+0x22c>
           83c:	3c030000 	lui	v1,0x0
      			83c: R_MIPS_HI16	cpu_data
           840:	40024800 	mfc0	v0,c0_count
           844:	00000000 	nop
           848:	00409021 	move	s2,v0
           84c:	8ce20000 	lw	v0,0(a3)
      			84c: R_MIPS_LO16	jiffies
      
      On most targets the sequence will be shorter and on some it will reduce to
      a single `MFC0 <reg>,c0_count', as all MIPS architecture (i.e. non-legacy
      MIPS) processors require the CP0 Count register to be present.
      
      The only known exception that reports MIPS architecture compliance, but
      contrary to that lacks CP0 Count is the Ingenic JZ4740 thingy.  For broken
      platforms like that this code requires cpu_has_counter to be hardcoded to
      0 (i.e. no variable setting is permitted) so as not to penalise all the
      other good platforms out there.
      
      The asm barrier is required so that the compiler does not pull any
      potentially costly (cold cache!) `cpu_data' variable access into the fast
      path.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: John Crispin <blogic@openwrt.org>
      Cc: Andrew McGregor <andrewmcgr@gmail.com>
      Cc: Dave Taht <dave.taht@bufferbloat.net>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Simon Kelley <simon@thekelleys.org.uk>
      Cc: Jim Gettys <jg@freedesktop.org>
      Cc: David Daney <ddaney@caviumnetworks.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/6702/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      06947aaa
  7. 30 5月, 2014 1 次提交
  8. 24 5月, 2014 1 次提交
    • R
      MIPS: MT: Remove SMTC support · b633648c
      Ralf Baechle 提交于
      Nobody is maintaining SMTC anymore and there also seems to be no userbase.
      Which is a pity - the SMTC technology primarily developed by Kevin D.
      Kissell <kevink@paralogos.com> is an ingenious demonstration for the MT
      ASE's power and elegance.
      
      Based on Markos Chandras <Markos.Chandras@imgtec.com> patch
      https://patchwork.linux-mips.org/patch/6719/ which while very similar did
      no longer apply cleanly when I tried to merge it plus some additional
      post-SMTC cleanup - SMTC was a feature as tricky to remove as it was to
      merge once upon a time.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      b633648c
  9. 23 5月, 2014 1 次提交
  10. 01 4月, 2014 3 次提交
  11. 27 3月, 2014 7 次提交
  12. 07 3月, 2014 1 次提交
  13. 25 1月, 2014 1 次提交
  14. 23 1月, 2014 5 次提交
  15. 14 1月, 2014 1 次提交
    • P
      MIPS: Support for 64-bit FP with O32 binaries · 597ce172
      Paul Burton 提交于
      CPUs implementing MIPS32 R2 may include a 64-bit FPU, just as MIPS64 CPUs
      do. In order to preserve backwards compatibility a 64-bit FPU will act
      like a 32-bit FPU (by accessing doubles from the least significant 32
      bits of an even-odd pair of FP registers) when the Status.FR bit is
      zero, again just like a mips64 CPU. The standard O32 ABI is defined
      expecting a 32-bit FPU, however recent toolchains support use of a
      64-bit FPU from an O32 MIPS32 executable. When an ELF executable is
      built to use a 64-bit FPU a new flag (EF_MIPS_FP64) is set in the ELF
      header.
      
      With this patch the kernel will check the EF_MIPS_FP64 flag when
      executing an O32 binary, and set Status.FR accordingly. The addition
      of O32 64-bit FP support lessens the opportunity for optimisation in
      the FPU emulator, so a CONFIG_MIPS_O32_FP64_SUPPORT Kconfig option is
      introduced to allow this support to be disabled for those that don't
      require it.
      
      Inspired by an earlier patch by Leonid Yegoshin, but implemented more
      cleanly & correctly.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/6154/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      597ce172
  16. 30 10月, 2013 2 次提交
  17. 19 9月, 2013 2 次提交
  18. 18 9月, 2013 1 次提交
  19. 04 9月, 2013 1 次提交
  20. 26 8月, 2013 1 次提交
  21. 15 7月, 2013 1 次提交
    • P
      MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code · 078a55fc
      Paul Gortmaker 提交于
      commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.
      
      The __cpuinit type of throwaway sections might have made sense
      some time ago when RAM was more constrained, but now the savings
      do not offset the cost and complications.  For example, the fix in
      commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
      is a good example of the nasty type of bugs that can be created
      with improper use of the various __init prefixes.
      
      After a discussion on LKML[1] it was decided that cpuinit should go
      the way of devinit and be phased out.  Once all the users are gone,
      we can then finally remove the macros themselves from linux/init.h.
      
      Note that some harmless section mismatch warnings may result, since
      notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
      and are flagged as __cpuinit  -- so if we remove the __cpuinit from
      the arch specific callers, we will also get section mismatch warnings.
      As an intermediate step, we intend to turn the linux/init.h cpuinit
      related content into no-ops as early as possible, since that will get
      rid of these warnings.  In any case, they are temporary and harmless.
      
      Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
      from asm files.  MIPS is interesting in this respect, because there
      are also uasm users hiding behind their own renamed versions of the
      __cpuinit macros.
      
      [1] https://lkml.org/lkml/2013/5/20/589
      
      [ralf@linux-mips.org: Folded in Paul's followup fix.]
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/5494/
      Patchwork: https://patchwork.linux-mips.org/patch/5495/
      Patchwork: https://patchwork.linux-mips.org/patch/5509/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      078a55fc