1. 22 4月, 2011 1 次提交
  2. 24 9月, 2009 1 次提交
  3. 16 3月, 2009 1 次提交
  4. 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
  5. 18 7月, 2008 2 次提交
    • D
    • 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
  6. 20 5月, 2008 1 次提交
    • D
      sparc64: Add global register dumping facility. · 93dae5b7
      David S. Miller 提交于
      When a cpu really is stuck in the kernel, it can be often
      impossible to figure out which cpu is stuck where.  The
      worst case is when the stuck cpu has interrupts disabled.
      
      Therefore, implement a global cpu state capture that uses
      SMP message interrupts which are not disabled by the
      normal IRQ enable/disable APIs of the kernel.
      
      As long as we can get a sysrq 'y' to the kernel, we can
      get a dump.  Even if the console interrupt cpu is wedged,
      we can trigger it from userspace using /proc/sysrq-trigger
      
      The output is made compact so that this facility is more
      useful on high cpu count systems, which is where this
      facility will likely find itself the most useful :)
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      93dae5b7
  7. 20 10月, 2007 1 次提交
  8. 17 10月, 2007 1 次提交
  9. 16 7月, 2007 2 次提交
    • D
      [SPARC64]: dr-cpu unconfigure support. · e0204409
      David S. Miller 提交于
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e0204409
    • D
      [SPARC64]: Initial LDOM cpu hotplug support. · 4f0234f4
      David S. Miller 提交于
      Only adding cpus is supports at the moment, removal
      will come next.
      
      When new cpus are configured, the machine description is
      updated.  When we get the configure request we pass in a
      cpu mask of to-be-added cpus to the mdesc CPU node parser
      so it only fetches information for those cpus.  That code
      also proceeds to update the SMT/multi-core scheduling bitmaps.
      
      cpu_up() does all the work and we return the status back
      over the DS channel.
      
      CPUs via dr-cpu need to be booted straight out of the
      hypervisor, and this requires:
      
      1) A new trampoline mechanism.  CPUs are booted straight
         out of the hypervisor with MMU disabled and running in
         physical addresses with no mappings installed in the TLB.
      
         The new hvtramp.S code sets up the critical cpu state,
         installs the locked TLB mappings for the kernel, and
         turns the MMU on.  It then proceeds to follow the logic
         of the existing trampoline.S SMP cpu bringup code.
      
      2) All calls into OBP have to be disallowed when domaining
         is enabled.  Since cpus boot straight into the kernel from
         the hypervisor, OBP has no state about that cpu and therefore
         cannot handle being invoked on that cpu.
      
         Luckily it's only a handful of interfaces which can be called
         after the OBP device tree is obtained.  For example, rebooting,
         halting, powering-off, and setting options node variables.
      
      CPU removal support will require some infrastructure changes
      here.  Namely we'll have to process the requests via a true
      kernel thread instead of in a workqueue.  workqueues run on
      a per-cpu thread, but when unconfiguring we might need to
      force the thread to execute on another cpu if the current cpu
      is the one being removed.  Removal of a cpu also causes the kernel
      to destroy that cpu's workqueue running thread.
      
      Another issue on removal is that we may have interrupts still
      pointing to the cpu-to-be-removed.  So new code will be needed
      to walk the active INO list and retarget those cpus as-needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f0234f4
  10. 05 6月, 2007 2 次提交
  11. 29 5月, 2007 1 次提交
  12. 10 5月, 2007 1 次提交
  13. 26 4月, 2007 1 次提交
  14. 26 4月, 2006 1 次提交
  15. 20 3月, 2006 2 次提交
    • D
      [SPARC64]: Add SMT scheduling support for Niagara. · 8935dced
      David S. Miller 提交于
      The mapping is a simple "(cpuid >> 2) == core" for now.
      Later we'll add more sophisticated code that will walk
      the sun4v machine description and figure this out from
      there.
      
      We should also add core mappings for jaguar and panther
      processors.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8935dced
    • D
      [SPARC64]: Refine code sequences to get the cpu id. · 92704a1c
      David S. Miller 提交于
      On uniprocessor, it's always zero for optimize that.
      
      On SMP, the jmpl to the stub kills the return address stack in the cpu
      branch prediction logic, so expand the code sequence inline and use a
      code patching section to fix things up.  This also always better and
      explicit register selection, which will be taken advantage of in a
      future changeset.
      
      The hard_smp_processor_id() function is big, so do not inline it.
      
      Fix up tests for Jalapeno to also test for Serrano chips too.  These
      tests want "jbus Ultra-IIIi" cases to match, so that is what we should
      test for.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92704a1c
  16. 27 2月, 2006 1 次提交
  17. 22 6月, 2005 1 次提交
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
  18. 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