<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux.git/include/asm-sparc64/cpudata.h, branch master</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/'/>
<updated>2008-07-27T21:00:59+00:00</updated>
<entry>
<title>sparc, sparc64: use arch/sparc/include</title>
<updated>2008-07-27T21:00:59+00:00</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@ravnborg.org</email>
</author>
<published>2008-07-27T21:00:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a439fe51a1f8eb087c22dd24d69cebae4a3addac'/>
<id>urn:sha1:a439fe51a1f8eb087c22dd24d69cebae4a3addac</id>
<content type='text'>
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: Sam Ravnborg &lt;sam@ravnborg.org&gt;
</content>
</entry>
<entry>
<title>sparc: join the remaining header files</title>
<updated>2008-07-18T04:55:51+00:00</updated>
<author>
<name>Sam Ravnborg</name>
<email>sam@ravnborg.org</email>
</author>
<published>2008-07-18T04:55:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5e706ad886b6a5eb59637830110b09ccebf01c5'/>
<id>urn:sha1:f5e706ad886b6a5eb59637830110b09ccebf01c5</id>
<content type='text'>
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                             &gt;   asm-sparc/$FILE
  printf "#define %s\n" $GUARD                             &gt;&gt;  asm-sparc/$FILE
  printf "#if defined(__sparc__) &amp;&amp; defined(__arch64__)\n" &gt;&gt;  asm-sparc/$FILE
  printf "#include &lt;asm-sparc/%s&gt;\n" $FN64                 &gt;&gt;  asm-sparc/$FILE
  printf "#else\n"                                         &gt;&gt;  asm-sparc/$FILE
  printf "#include &lt;asm-sparc/%s&gt;\n" $FN32                 &gt;&gt;  asm-sparc/$FILE
  printf "#endif\n"                                        &gt;&gt;  asm-sparc/$FILE
  printf "#endif\n"                                        &gt;&gt;  asm-sparc/$FILE
  git add asm-sparc/$FILE
  echo new file done
  printf "#include &lt;asm-sparc/%s&gt;\n" $FILE                 &gt;  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: Sam Ravnborg &lt;sam@ravnborg.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Fix sparse warnings in arch/sparc64/kernel/{cpu,setup}.c</title>
<updated>2008-03-26T04:51:40+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2008-03-26T04:51:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3d5ae6b69eacfac025021998d2ce159768edcfe1'/>
<id>urn:sha1:3d5ae6b69eacfac025021998d2ce159768edcfe1</id>
<content type='text'>
We create a local header file entry.h, under arch/sparc64/kernel/,
that we can use to declare routines either defined in assembler
or only invoked from assembler.  As well as other data objects
which are private to the inner sparc64 kernel arch code.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Access ivector_table[] using physical addresses.</title>
<updated>2007-10-14T04:53:15+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-10-14T04:42:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=eb2d8d60327bec172ec80efbda94d0c492088204'/>
<id>urn:sha1:eb2d8d60327bec172ec80efbda94d0c492088204</id>
<content type='text'>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Make IVEC pointers 64-bit.</title>
<updated>2007-10-14T04:53:15+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-10-12T09:59:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a650d3839e7a68321e5b76264398a63019b0928b'/>
<id>urn:sha1:a650d3839e7a68321e5b76264398a63019b0928b</id>
<content type='text'>
Currently we chain IVEC entries using 32-bit "pointers"
because we know that the ivector_table is in the main
kernel image, thus below 4GB.

This uses proper 64-bit pointers instead.

Whilst this bloats up the kernel image size, this sets
the infrastructure necessary to significantly shrink the
kernel size by using physical addresses and dynamically
allocating the ivector table.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: More sensible udelay implementation.</title>
<updated>2007-07-16T11:05:02+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-07-14T09:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8b99cfb8cc51adae7f5294c8962a026c63100959'/>
<id>urn:sha1:8b99cfb8cc51adae7f5294c8962a026c63100959</id>
<content type='text'>
Take a page from the powerpc folks and just calculate the
delay factor directly.

Since frequency scaling chips use a system-tick register,
the value is going to be the same system-wide.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Initial LDOM cpu hotplug support.</title>
<updated>2007-07-16T11:04:40+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-07-13T23:03:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4f0234f4f9da485ecb9729af1b88567700fd4767'/>
<id>urn:sha1:4f0234f4f9da485ecb9729af1b88567700fd4767</id>
<content type='text'>
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: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Proper multi-core scheduling support.</title>
<updated>2007-06-05T04:50:00+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@hutch.davemloft.net</email>
</author>
<published>2007-06-05T00:01:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f78eae2e6f5d1eb05f76a45486286445b916bd92'/>
<id>urn:sha1:f78eae2e6f5d1eb05f76a45486286445b916bd92</id>
<content type='text'>
The scheduling domain hierarchy is:

   all cpus --&gt;
      cpus that share an instruction cache --&gt;
          cpus that share an integer execution unit

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Eliminate NR_CPUS limitations.</title>
<updated>2007-05-29T09:49:49+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-05-26T08:14:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=22adb358e816ce6aa0afb231ae9d826b0bddc8b0'/>
<id>urn:sha1:22adb358e816ce6aa0afb231ae9d826b0bddc8b0</id>
<content type='text'>
Cheetah systems can have cpuids as large as 1023, although physical
systems don't have that many cpus.

Only three limitations existed in the kernel preventing arbitrary
NR_CPUS values:

1) dcache dirty cpu state stored in page-&gt;flags on
   D-cache aliasing platforms.  With some build time
   calculations and some build-time BUG checks on
   page-&gt;flags layout, this one was easily solved.

2) The cheetah XCALL delivery code could only handle
   a cpumask with up to 32 cpus set.  Some simple looping
   logic clears that up too.

3) thread_info-&gt;cpu was a u8, easily changed to a u16.

There are a few spots in the kernel that still put NR_CPUS
sized arrays on the kernel stack, but that's not a sparc64
specific problem.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SPARC64]: Use machine description and OBP properly for cpu probing.</title>
<updated>2007-05-29T09:49:41+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@sunset.davemloft.net</email>
</author>
<published>2007-05-25T22:49:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5cbc30737398b49f62ae8603129ce43ac7db1a41'/>
<id>urn:sha1:5cbc30737398b49f62ae8603129ce43ac7db1a41</id>
<content type='text'>
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
