1. 16 Jun, 2009 2 commits
  2. 27 Jul, 2008 1 commit
    • Sam Ravnborg's avatar
      sparc, sparc64: use arch/sparc/include · a439fe51
      Sam Ravnborg authored
      
      
      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: default avatarSam Ravnborg <sam@ravnborg.org>
      a439fe51
  3. 17 Jul, 2008 1 commit
    • Sam Ravnborg's avatar
      sparc: copy sparc64 specific files to asm-sparc · a00736e9
      Sam Ravnborg authored
      
      
      Used the following script to copy the files:
      cd include
      set -e
      SPARC64=`ls asm-sparc64`
      for FILE in ${SPARC64}; do
      	if [ -f asm-sparc/$FILE ]; then
      		echo $FILE exist in asm-sparc
      	else
      		git mv asm-sparc64/$FILE asm-sparc/$FILE
      		printf "#include <asm-sparc/$FILE>\n" > asm-sparc64/$FILE
      		git add asm-sparc64/$FILE
      	fi
      done
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      a00736e9
  4. 18 Jul, 2007 1 commit
  5. 16 Jul, 2007 3 commits
    • David S. Miller's avatar
      [SPARC64]: Initial LDOM cpu hotplug support. · 4f0234f4
      David S. Miller authored
      
      
      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: default avatarDavid S. Miller <davem@davemloft.net>
      4f0234f4
    • David S. Miller's avatar
      [SPARC64]: Fix MD property lifetime bugs. · 83292e0a
      David S. Miller authored
      
      
      Property values cannot be referenced outside of
      mdesc_grab()/mdesc_release() pairs.  The only major
      offender was the VIO bus layer, easily fixed.
      
      Add some commentary to mdesc.h describing these rules.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      83292e0a
    • David S. Miller's avatar
      [SPARC64]: Abstract out mdesc accesses for better MD update handling. · 43fdf274
      David S. Miller authored
      
      
      Since we have to be able to handle MD updates, having an in-tree
      set of data structures representing the MD objects actually makes
      things more painful.
      
      The MD itself is easy to parse, and we can implement the existing
      interfaces using direct parsing of the MD binary image.
      
      The MD is now reference counted, so accesses have to now take the
      form:
      
      	handle = mdesc_grab();
      
      	... operations on MD ...
      
      	mdesc_release(handle);
      
      The only remaining issue are cases where code holds on to references
      to MD property values.  mdesc_get_property() returns a direct pointer
      to the property value, most cases just pull in the information they
      need and discard the pointer, but there are few that use the pointer
      directly over a long lifetime.  Those will be fixed up in a subsequent
      changeset.
      
      A preliminary handler for MD update events from domain services is
      there, it is rudimentry but it works and handles all of the reference
      counting.  It does not check the generation number of the MDs,
      and it does not generate a "add/delete" list for notification to
      interesting parties about MD changes but that will be forthcoming.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      43fdf274
  6. 26 Jun, 2007 1 commit
  7. 29 May, 2007 1 commit