1. 20 8月, 2010 1 次提交
  2. 04 3月, 2010 1 次提交
  3. 06 11月, 2009 1 次提交
  4. 10 9月, 2009 1 次提交
  5. 05 12月, 2008 3 次提交
  6. 12 9月, 2008 1 次提交
  7. 01 9月, 2008 1 次提交
    • A
      sparc: remove CONFIG_SUN4 · 5110bd21
      Adrian Bunk 提交于
      While doing some easy cleanups on the sparc code I noticed that the
      CONFIG_SUN4 code seems to be worse than the rest - there were some
      "I don't know how it should work, but the current code definitely cannot
      work." places.
      
      And while I have seen people running Linux on machines like a
      SPARCstation 5 a few years ago I don't recall having seen sun4
      machines, even less ones running Linux.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5110bd21
  8. 28 7月, 2008 1 次提交
    • S
      sparc, sparc64: use arch/sparc/include · a439fe51
      Sam Ravnborg 提交于
      The majority of this patch was created by the following script:
      
      ***
      ASM=arch/sparc/include/asm
      mkdir -p $ASM
      git mv include/asm-sparc64/ftrace.h $ASM
      git rm include/asm-sparc64/*
      git mv include/asm-sparc/* $ASM
      sed -ie 's/asm-sparc64/asm/g' $ASM/*
      sed -ie 's/asm-sparc/asm/g' $ASM/*
      ***
      
      The rest was an update of the top-level Makefile to use sparc
      for header files when sparc64 is being build.
      And a small fixlet to pick up the correct unistd.h from
      sparc64 code.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      a439fe51
  9. 18 7月, 2008 1 次提交
    • S
      sparc: join the remaining header files · f5e706ad
      Sam Ravnborg 提交于
      With this commit all sparc64 header files are moved to asm-sparc.
      The remaining files (71 files) were too different to be trivially
      merged so divide them up in a _32.h and a _64.h file which
      are both included from the file with no bit size.
      
      The following script were used:
      cd include
      FILES=`wc -l asm-sparc64/*h | grep -v '^     1' | cut -b 20-`
      
      for FILE in ${FILES}; do
        echo $FILE:
        BASE=`echo $FILE | cut -d '.' -f 1`
        FN32=${BASE}_32.h
        FN64=${BASE}_64.h
        GUARD=___ASM_SPARC_`echo $BASE | tr '-' '_' | tr [:lower:] [:upper:]`_H
        git mv asm-sparc/$FILE asm-sparc/$FN32
        git mv asm-sparc64/$FILE asm-sparc/$FN64
        echo git mv done
        printf "#ifndef %s\n" $GUARD                             >   asm-sparc/$FILE
        printf "#define %s\n" $GUARD                             >>  asm-sparc/$FILE
        printf "#if defined(__sparc__) && defined(__arch64__)\n" >>  asm-sparc/$FILE
        printf "#include <asm-sparc/%s>\n" $FN64                 >>  asm-sparc/$FILE
        printf "#else\n"                                         >>  asm-sparc/$FILE
        printf "#include <asm-sparc/%s>\n" $FN32                 >>  asm-sparc/$FILE
        printf "#endif\n"                                        >>  asm-sparc/$FILE
        printf "#endif\n"                                        >>  asm-sparc/$FILE
        git add asm-sparc/$FILE
        echo new file done
        printf "#include <asm-sparc/%s>\n" $FILE                 >  asm-sparc64/$FILE
        git add asm-sparc64/$FILE
        echo sparc64 file done
      done
      
      The guard contains three '_' to avoid conflict with existing guards.
      In additing the two Kbuild files are emptied to avoid breaking
      headers_* targets.
      We will reintroduce the exported header files when the necessary
      kbuild changes are merged.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5e706ad
  10. 29 4月, 2008 1 次提交
    • D
      sparc: Add kgdb support. · e2fdd7fd
      David S. Miller 提交于
      Current limitations:
      
      1) On SMP single stepping has some fundamental issues,
         shared with other sw single-step architectures such
         as mips and arm.
      
      2) On 32-bit sparc we don't support SMP kgdb yet.  That
         requires some reworking of the IPI mechanisms and
         infrastructure on that platform.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2fdd7fd
  11. 29 2月, 2008 1 次提交
  12. 20 2月, 2008 1 次提交
  13. 08 2月, 2008 1 次提交
  14. 01 11月, 2007 1 次提交
    • D
      [SPARC64]: Fix linkage of enormous kernels. · 52eb053b
      David S. Miller 提交于
      This was found by make randconfig
      
      If the kernel .text is very large, the .fixup section branches
      are too far away to be relocated correctly.
      
      Use "sethi %hi(label), reg; jmpl reg + %lo(label); %g0" sequence
      instead of the branch to fix this.
      
      There is another case in switch_to() involving a branch, which
      is fixed similarly.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52eb053b
  15. 27 10月, 2007 1 次提交
  16. 21 8月, 2007 1 次提交
  17. 21 7月, 2007 1 次提交
    • D
      [SPARC]: Fix serial console device detection. · c73fcc84
      David S. Miller 提交于
      The current scheme works on static interpretation of text names, which
      is wrong.
      
      The output-device setting, for example, must be resolved via an alias
      or similar to a full path name to the console device.
      
      Paths also contain an optional set of 'options', which starts with a
      colon at the end of the path.  The option area is used to specify
      which of two serial ports ('a' or 'b') the path refers to when a
      device node drives multiple ports.  'a' is assumed if the option
      specification is missing.
      
      This was caught by the UltraSPARC-T1 simulator.  The 'output-device'
      property was set to 'ttya' and we didn't pick upon the fact that this
      is an OBP alias set to '/virtual-devices/console'.  Instead we saw it
      as the first serial console device, instead of the hypervisor console.
      
      The infrastructure is now there to take advantage of this to resolve
      the console correctly even in multi-head situations in fbcon too.
      
      Thanks to Greg Onufer for the bug report.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c73fcc84
  18. 20 7月, 2007 1 次提交
  19. 09 5月, 2007 1 次提交
  20. 10 12月, 2006 1 次提交
  21. 15 7月, 2006 1 次提交
    • S
      [PATCH] remove set_wmb - arch removal · 52393ccc
      Steven Rostedt 提交于
      set_wmb should not be used in the kernel because it just confuses the
      code more and has no benefit.  Since it is not currently used in the
      kernel this patch removes it so that new code does not include it.
      
      All archs define set_wmb(var, value) to do { var = value; wmb(); }
      while(0) except ia64 and sparc which use a mb() instead.  But this is
      still moot since it is not used anyway.
      
      Hasn't been tested on any archs but x86 and x86_64 (and only compiled
      tested)
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      52393ccc
  22. 26 4月, 2006 1 次提交
  23. 20 3月, 2006 2 次提交
    • D
      [SPARC64]: Kill all %pstate changes in context switch code. · 314981ac
      David S. Miller 提交于
      They are totally unnecessary because:
      
      1) Interrupts are already disabled when switch_to()
         runs.
      
      2) We don't use hard-coded alternate globals any longer.
      
      This found a case in rtrap, which still assumed alternate
      global %g6 was current_thread_info(), and that is fixed
      by this changeset as well.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      314981ac
    • D
      [SPARC64]: Elminate all usage of hard-coded trap globals. · 56fb4df6
      David S. Miller 提交于
      UltraSPARC has special sets of global registers which are switched to
      for certain trap types.  There is one set for MMU related traps, one
      set of Interrupt Vector processing, and another set (called the
      Alternate globals) for all other trap types.
      
      For what seems like forever we've hard coded the values in some of
      these trap registers.  Some examples include:
      
      1) Interrupt Vector global %g6 holds current processors interrupt
         work struct where received interrupts are managed for IRQ handler
         dispatch.
      
      2) MMU global %g7 holds the base of the page tables of the currently
         active address space.
      
      3) Alternate global %g6 held the current_thread_info() value.
      
      Such hardcoding has resulted in some serious issues in many areas.
      There are some code sequences where having another register available
      would help clean up the implementation.  Taking traps such as
      cross-calls from the OBP firmware requires some trick code sequences
      wherein we have to save away and restore all of the special sets of
      global registers when we enter/exit OBP.
      
      We were also using the IMMU TSB register on SMP to hold the per-cpu
      area base address, which doesn't work any longer now that we actually
      use the TSB facility of the cpu.
      
      The implementation is pretty straight forward.  One tricky bit is
      getting the current processor ID as that is different on different cpu
      variants.  We use a stub with a fancy calling convention which we
      patch at boot time.  The calling convention is that the stub is
      branched to and the (PC - 4) to return to is in register %g1.  The cpu
      number is left in %g6.  This stub can be invoked by using the
      __GET_CPUID macro.
      
      We use an array of per-cpu trap state to store the current thread and
      physical address of the current address space's page tables.  The
      TRAP_LOAD_THREAD_REG loads %g6 with the current thread from this
      table, it uses __GET_CPUID and also clobbers %g1.
      
      TRAP_LOAD_IRQ_WORK is used by the interrupt vector processing to load
      the current processor's IRQ software state into %g6.  It also uses
      __GET_CPUID and clobbers %g1.
      
      Finally, TRAP_LOAD_PGD_PHYS loads the physical address base of the
      current address space's page tables into %g7, it clobbers %g1 and uses
      __GET_CPUID.
      
      Many refinements are possible, as well as some tuning, with this stuff
      in place.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56fb4df6
  24. 13 1月, 2006 2 次提交
  25. 09 1月, 2006 1 次提交
  26. 09 9月, 2005 1 次提交
    • D
      [SPARC64]: Inline membar()'s again. · 4d803fcd
      David S. Miller 提交于
      Since GCC has to emit a call and a delay slot to the
      out-of-line "membar" routines in arch/sparc64/lib/mb.S
      it is much better to just do the necessary predicted
      branch inline instead as:
      
      	ba,pt	%xcc, 1f
      	 membar	#whatever
      1:
      
      instead of the current:
      
      	call	membar_foo
      	 dslot
      
      because this way GCC is not required to allocate a stack
      frame if the function can be a leaf function.
      
      This also makes this bug fix easier to backport to 2.4.x
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4d803fcd
  27. 30 8月, 2005 1 次提交
  28. 25 7月, 2005 1 次提交
  29. 26 6月, 2005 1 次提交
    • N
      [PATCH] sched: cleanup context switch locking · 4866cde0
      Nick Piggin 提交于
      Instead of requiring architecture code to interact with the scheduler's
      locking implementation, provide a couple of defines that can be used by the
      architecture to request runqueue unlocked context switches, and ask for
      interrupts to be enabled over the context switch.
      
      Also replaces the "switch_lock" used by these architectures with an oncpu
      flag (note, not a potentially slow bitflag).  This eliminates one bus
      locked memory operation when context switching, and simplifies the
      task_running function.
      Signed-off-by: NNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4866cde0
  30. 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