1. 28 7月, 2011 2 次提交
    • D
      sparc: Detect and handle UltraSPARC-T3 cpu types. · 4ba991d3
      David S. Miller 提交于
      The cpu compatible string we look for is "SPARC-T3".
      
      As far as memset/memcpy optimizations go, we treat this chip the same
      as Niagara-T2/T2+.  Use cache initializing stores for memset, and use
      perfetch, FPU block loads, cache initializing stores, and block stores
      for copies.
      
      We use the Niagara-T2 perf support, since T3 is a close relative in
      this regard.  Later we'll add support for the new events T3 can
      report, plus enable T3's new "sample" mode.
      
      For now I haven't added any new ELF hwcap flags.  We probably need
      to add a couple, for example:
      
      T2 and T3 both support the population count instruction in hardware.
      
      T3 supports VIS3 instructions, including support (finally) for
      partitioned shift.  One can also now move directly between float
      and integer registers.
      
      T3 supports instructions meant to help with Galois Field and other HPC
      calculations, such as XOR multiply.  Also there are "OP and negate"
      instructions, for example "fnmul" which is multiply-and-negate.
      
      T3 recognizes the transactional memory opcodes, however since
      transactional memory isn't supported: 1) 'commit' behaves as a NOP and
      2) 'chkpt' always branches 3) 'rdcps' returns all zeros and 4) 'wrcps'
      behaves as a NOP.
      
      So we'll need about 3 new elf capability flags in the end to represent
      all of these things.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ba991d3
    • D
      sparc: Don't leave sparc_pmu_type NULL on sun4v. · facfddef
      David S. Miller 提交于
      Otherwise we'll crash in the sparc perf init code.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      facfddef
  2. 22 4月, 2011 2 次提交
    • S
      sparc32: probe for cpu info only during startup · 9c2853af
      Sam Ravnborg 提交于
      We did a cpu_probe() call each time a CPU got online - which
      only effect was to save latest CPU/FPU info for use by show_cpuinfo().
      Use same setup as for sparc64 where we probe for this info during startup,
      and only once.
      
      This allowed us to annotate a few functions __init which again
      fixed the following section mismatch warnings:
      
      WARNING: vmlinux.o(.text+0x65f0): Section mismatch in reference from the function set_cpu_and_fpu() to the (unknown reference) .init.rodata:(unknown)
      WARNING: vmlinux.o(.text+0x65f8): Section mismatch in reference from the function set_cpu_and_fpu() to the (unknown reference) .init.rodata:(unknown)
      WARNING: vmlinux.o(.text+0x664c): Section mismatch in reference from the function set_cpu_and_fpu() to the variable .init.rodata:manufacturer_info
      WARNING: vmlinux.o(.text+0x6650): Section mismatch in reference from the function set_cpu_and_fpu() to the variable .init.rodata:manufacturer_info
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9c2853af
    • S
      sparc: consolidate show_cpuinfo in cpu.c · cb1b8209
      Sam Ravnborg 提交于
      We have all the cpu related info in cpu.c - so move
      the remaining functions to support /proc/cpuinfo to this file.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb1b8209
  3. 17 3月, 2011 1 次提交
  4. 10 1月, 2011 1 次提交
  5. 03 12月, 2009 1 次提交
  6. 18 8月, 2009 1 次提交
  7. 29 1月, 2009 1 次提交
  8. 18 1月, 2009 1 次提交
  9. 09 1月, 2009 1 次提交
    • S
      sparc: move EXPORT_SYMBOL to the symbols definition · 6943f3da
      Sam Ravnborg 提交于
      Move all applicable EXPORT_SYMBOL()s to the file where the respective
      symbol is defined.
      
      Removed all the includes that are no longer needed in sparc_ksyms_32.c
      
      Comment all remaining EXPORT_SYMBOL()s in sparc_ksyms_32.c
      
      Two symbols are shared with sparc64 thus the exports were removed from
      the sparc_ksyms_64.c too, along with the include their ommission made
      redundant.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      
      Additions by Julian Calaby:
      * Moved EXPORT_SYMBOL()s for prom functions to their rightful places.
      * Made some minor cleanups to the includes and comments of sparc_ksyms_32.c
      * Made another subtraction from sparc_ksyms_64.c
      * Updated and tidied commit message.
      * Rebased patch over sparc-2.6.git HEAD.
      * Ensured that all modified files have the correct includes.
      Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6943f3da
  10. 07 12月, 2008 3 次提交
  11. 06 12月, 2008 2 次提交
  12. 05 12月, 2008 1 次提交
    • S
      sparc: prepare kernel/ for unification · d670bd4f
      Sam Ravnborg 提交于
      o sparc32 files with identical names to sparc64 renamed to <name>_32.S
      o introduced a few Kconfig helpers to simplify Makefile logic
      o refactored Makefile to prepare for unification
        - use obj-$(CONFIG_SPARC32) for sparc32 specific files
        - use <name>_$(BITS) for files where sparc64 has a _64 variant
        - sparc64 directly include a few files where sparc32 builds them,
          refer to these files directly (no BITS)
        - sneaked in -Werror as used by sparc64
      o modified sparc/Makefile to use the new names for head/init_task
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d670bd4f
  13. 01 12月, 2008 1 次提交
  14. 29 2月, 2008 1 次提交
  15. 01 7月, 2006 1 次提交
  16. 10 11月, 2005 1 次提交
  17. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4