<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/powerpc/kernel/cputable.c, branch v2.6.20</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[POWERPC] Fix 440SPe CPU table entry</title>
<updated>2006-12-08T08:45:38+00:00</updated>
<author>
<name>Kumar Gala</name>
<email>galak@kernel.crashing.org</email>
</author>
<published>2006-12-08T08:34:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a147c5857c0b591b05d787e59b691c3a4f245f83'/>
<id>a147c5857c0b591b05d787e59b691c3a4f245f83</id>
<content type='text'>
The 440SPe CPU table entry was missing the CPU_FTR_NODSISRALIGN and
really should have been CPU_FTRS_44X.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 440SPe CPU table entry was missing the CPU_FTR_NODSISRALIGN and
really should have been CPU_FTRS_44X.

Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Add support for FP emulation for the e300c2 core</title>
<updated>2006-12-08T08:43:30+00:00</updated>
<author>
<name>Kim Phillips</name>
<email>kim.phillips@freescale.com</email>
</author>
<published>2006-12-08T08:43:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=aa42c69c67f82e88f0726258efe7306708e1cf14'/>
<id>aa42c69c67f82e88f0726258efe7306708e1cf14</id>
<content type='text'>
The e300c2 has no FPU.  Its MSR[FP] is grounded to zero.  If an attempt
is made to execute a floating point instruction (including floating-point
load, store, or move instructions), the e300c2 takes a floating-point
unavailable interrupt.

This patch adds support for FP emulation on the e300c2 by declaring a
new CPU_FTR_FP_TAKES_FPUNAVAIL, where FP unavail interrupts are
intercepted and redirected to the ProgramCheck exception path for
correct emulation handling.

(If we run out of CPU_FTR bits we could look to reclaim this bit by adding
support to test the cpu_user_features for PPC_FEATURE_HAS_FPU instead)

It adds a nop to the exception path for 32-bit processors with a FPU.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The e300c2 has no FPU.  Its MSR[FP] is grounded to zero.  If an attempt
is made to execute a floating point instruction (including floating-point
load, store, or move instructions), the e300c2 takes a floating-point
unavailable interrupt.

This patch adds support for FP emulation on the e300c2 by declaring a
new CPU_FTR_FP_TAKES_FPUNAVAIL, where FP unavail interrupts are
intercepted and redirected to the ProgramCheck exception path for
correct emulation handling.

(If we run out of CPU_FTR bits we could look to reclaim this bit by adding
support to test the cpu_user_features for PPC_FEATURE_HAS_FPU instead)

It adds a nop to the exception path for 32-bit processors with a FPU.

Signed-off-by: Kim Phillips &lt;kim.phillips@freescale.com&gt;
Signed-off-by: Kumar Gala &lt;galak@kernel.crashing.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Add the e300c3 core to the CPU table.</title>
<updated>2006-12-04T09:42:06+00:00</updated>
<author>
<name>Scott Wood</name>
<email>scottwood@freescale.com</email>
</author>
<published>2006-12-01T18:57:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=57933f8fbedba686659b947659418734615611e9'/>
<id>57933f8fbedba686659b947659418734615611e9</id>
<content type='text'>
This core is used in Freescale's 831x chips.

Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This core is used in Freescale's 831x chips.

Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] powerpc: Make 970MP detectable by oprofile</title>
<updated>2006-12-04T09:41:02+00:00</updated>
<author>
<name>Mike Wolf</name>
<email>mjw@us.ibm.com</email>
</author>
<published>2006-11-21T20:41:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fecb352f6bb86564b24ecbf7e5bfec09346b9327'/>
<id>fecb352f6bb86564b24ecbf7e5bfec09346b9327</id>
<content type='text'>
Change the oprofile_cpu_type in cputables.c to be ppc64/970MP.  Oprofile
needs to distinquish the MP from other 970 processors so it can add some
new counters specific to the 970MP.

Signed-off-by: Mike Wolf &lt;mjw@us.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Change the oprofile_cpu_type in cputables.c to be ppc64/970MP.  Oprofile
needs to distinquish the MP from other 970 processors so it can add some
new counters specific to the 970MP.

Signed-off-by: Mike Wolf &lt;mjw@us.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Distinguish POWER6 partition modes and tell userspace</title>
<updated>2006-12-04T09:40:16+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@samba.org</email>
</author>
<published>2006-11-10T09:38:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=974a76f51355d22f4f63d83d6bb1ccecd019ec58'/>
<id>974a76f51355d22f4f63d83d6bb1ccecd019ec58</id>
<content type='text'>
This adds code to look at the properties firmware puts in the device
tree to determine what compatibility mode the partition is in on
POWER6 machines, and set the ELF aux vector AT_HWCAP and AT_PLATFORM
entries appropriately.

Specifically, we look at the cpu-version property in the cpu node(s).
If that contains a "logical" PVR value (of the form 0x0f00000x), we
call identify_cpu again with this PVR value.  A value of 0x0f000001
indicates the partition is in POWER5+ compatibility mode, and a value
of 0x0f000002 indicates "POWER6 architected" mode, with various
extensions disabled.  We also look for various other properties:
ibm,dfp, ibm,purr and ibm,spurr.

Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This adds code to look at the properties firmware puts in the device
tree to determine what compatibility mode the partition is in on
POWER6 machines, and set the ELF aux vector AT_HWCAP and AT_PLATFORM
entries appropriately.

Specifically, we look at the cpu-version property in the cpu node(s).
If that contains a "logical" PVR value (of the form 0x0f00000x), we
call identify_cpu again with this PVR value.  A value of 0x0f000001
indicates the partition is in POWER5+ compatibility mode, and a value
of 0x0f000002 indicates "POWER6 architected" mode, with various
extensions disabled.  We also look for various other properties:
ibm,dfp, ibm,purr and ibm,spurr.

Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] cell: Add oprofile support</title>
<updated>2006-12-04T09:40:14+00:00</updated>
<author>
<name>Maynard Johnson</name>
<email>maynardj@us.ibm.com</email>
</author>
<published>2006-11-20T17:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=18f2190d796198fbb5d4bc4c87511acf3ced7d47'/>
<id>18f2190d796198fbb5d4bc4c87511acf3ced7d47</id>
<content type='text'>
Add PPU event-based and cycle-based profiling support to Oprofile for Cell.

Oprofile is expected to collect data on all CPUs simultaneously.
However, there is one set of performance counters per node.  There are
two hardware threads or virtual CPUs on each node.  Hence, OProfile must
multiplex in time the performance counter collection on the two virtual
CPUs.

The multiplexing of the performance counters is done by a virtual
counter routine.  Initially, the counters are configured to collect data
on the even CPUs in the system, one CPU per node.  In order to capture
the PC for the virtual CPU when the performance counter interrupt occurs
(the specified number of events between samples has occurred), the even
processors are configured to handle the performance counter interrupts
for their node.  The virtual counter routine is called via a kernel
timer after the virtual sample time.  The routine stops the counters,
saves the current counts, loads the last counts for the other virtual
CPU on the node, sets interrupts to be handled by the other virtual CPU
and restarts the counters, the virtual timer routine is scheduled to run
again.  The virtual sample time is kept relatively small to make sure
sampling occurs on both CPUs on the node with a relatively small
granularity.  Whenever the counters overflow, the performance counter
interrupt is called to collect the PC for the CPU where data is being
collected.

The oprofile driver relies on a firmware RTAS call to setup the debug bus
to route the desired signals to the performance counter hardware to be
counted.  The RTAS call must set the routing registers appropriately in
each of the islands to pass the signals down the debug bus as well as
routing the signals from a particular island onto the bus.  There is a
second firmware RTAS call to reset the debug bus to the non pass thru
state when the counters are not in use.

Signed-off-by: Carl Love &lt;carll@us.ibm.com&gt;
Signed-off-by: Maynard Johnson &lt;mpjohn@us.ibm.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd.bergmann@de.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add PPU event-based and cycle-based profiling support to Oprofile for Cell.

Oprofile is expected to collect data on all CPUs simultaneously.
However, there is one set of performance counters per node.  There are
two hardware threads or virtual CPUs on each node.  Hence, OProfile must
multiplex in time the performance counter collection on the two virtual
CPUs.

The multiplexing of the performance counters is done by a virtual
counter routine.  Initially, the counters are configured to collect data
on the even CPUs in the system, one CPU per node.  In order to capture
the PC for the virtual CPU when the performance counter interrupt occurs
(the specified number of events between samples has occurred), the even
processors are configured to handle the performance counter interrupts
for their node.  The virtual counter routine is called via a kernel
timer after the virtual sample time.  The routine stops the counters,
saves the current counts, loads the last counts for the other virtual
CPU on the node, sets interrupts to be handled by the other virtual CPU
and restarts the counters, the virtual timer routine is scheduled to run
again.  The virtual sample time is kept relatively small to make sure
sampling occurs on both CPUs on the node with a relatively small
granularity.  Whenever the counters overflow, the performance counter
interrupt is called to collect the PC for the CPU where data is being
collected.

The oprofile driver relies on a firmware RTAS call to setup the debug bus
to route the desired signals to the performance counter hardware to be
counted.  The RTAS call must set the routing registers appropriately in
each of the islands to pass the signals down the debug bus as well as
routing the signals from a particular island onto the bus.  There is a
second firmware RTAS call to reset the debug bus to the non pass thru
state when the counters are not in use.

Signed-off-by: Carl Love &lt;carll@us.ibm.com&gt;
Signed-off-by: Maynard Johnson &lt;mpjohn@us.ibm.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd.bergmann@de.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'linux-2.6' into for-linus</title>
<updated>2006-12-04T04:59:07+00:00</updated>
<author>
<name>Paul Mackerras</name>
<email>paulus@samba.org</email>
</author>
<published>2006-12-04T04:59:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=79acbb3ff2d8095b692e1502b9eb2ccec348de26'/>
<id>79acbb3ff2d8095b692e1502b9eb2ccec348de26</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Support feature fixups in vdso's</title>
<updated>2006-10-25T01:54:07+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2006-10-20T01:47:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0909c8c2d547e45ca50e2492b08ec93a37b35237'/>
<id>0909c8c2d547e45ca50e2492b08ec93a37b35237</id>
<content type='text'>
This patch reworks the feature fixup mecanism so vdso's can be fixed up.
The main issue was that the construct:

        .long   label  (or .llong on 64 bits)

will not work in the case of a shared library like the vdso. It will
generate an empty placeholder in the fixup table along with a reloc,
which is not something we can deal with in the vdso.

The idea here (thanks Alan Modra !) is to instead use something like:

1:
        .long   label - 1b

That is, the feature fixup tables no longer contain addresses of bits of
code to patch, but offsets of such code from the fixup table entry
itself. That is properly resolved by ld when building the .so's. I've
modified the fixup mecanism generically to use that method for the rest
of the kernel as well.

Another trick is that the 32 bits vDSO included in the 64 bits kernel
need to have a table in the 64 bits format. However, gas does not
support 32 bits code with a statement of the form:

        .llong  label - 1b  (Or even just .llong label)

That is, it cannot emit the right fixup/relocation for the linker to use
to assign a 32 bits address to an .llong field. Thus, in the specific
case of the 32 bits vdso built as part of the 64 bits kernel, we are
using a modified macro that generates:

        .long   0xffffffff
        .llong  label - 1b

Note that is assumes that the value is negative which is enforced by
the .lds (those offsets are always negative as the .text is always
before the fixup table and gas doesn't support emiting the reloc the
other way around).

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch reworks the feature fixup mecanism so vdso's can be fixed up.
The main issue was that the construct:

        .long   label  (or .llong on 64 bits)

will not work in the case of a shared library like the vdso. It will
generate an empty placeholder in the fixup table along with a reloc,
which is not something we can deal with in the vdso.

The idea here (thanks Alan Modra !) is to instead use something like:

1:
        .long   label - 1b

That is, the feature fixup tables no longer contain addresses of bits of
code to patch, but offsets of such code from the fixup table entry
itself. That is properly resolved by ld when building the .so's. I've
modified the fixup mecanism generically to use that method for the rest
of the kernel as well.

Another trick is that the 32 bits vDSO included in the 64 bits kernel
need to have a table in the 64 bits format. However, gas does not
support 32 bits code with a statement of the form:

        .llong  label - 1b  (Or even just .llong label)

That is, it cannot emit the right fixup/relocation for the linker to use
to assign a 32 bits address to an .llong field. Thus, in the specific
case of the 32 bits vdso built as part of the 64 bits kernel, we are
using a modified macro that generates:

        .long   0xffffffff
        .llong  label - 1b

Note that is assumes that the value is negative which is enforced by
the .lds (those offsets are always negative as the .text is always
before the fixup table and gas doesn't support emiting the reloc the
other way around).

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Consolidate feature fixup code</title>
<updated>2006-10-25T01:42:10+00:00</updated>
<author>
<name>Benjamin Herrenschmidt</name>
<email>benh@kernel.crashing.org</email>
</author>
<published>2006-10-24T06:42:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc'/>
<id>42c4aaadb737e0e672b3fb86b2c41ff59f0fb8bc</id>
<content type='text'>
There are currently two versions of the functions for applying the
feature fixups, one for CPU features and one for firmware features. In
addition, they are both in assembly and with separate implementations
for 32 and 64 bits. identify_cpu() is also implemented in assembly and
separately for 32 and 64 bits.

This patch replaces them with a pair of C functions. The call sites are
slightly moved on ppc64 as well to be called from C instead of from
assembly, though it's a very small change, and thus shouldn't cause any
problem.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Acked-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are currently two versions of the functions for applying the
feature fixups, one for CPU features and one for firmware features. In
addition, they are both in assembly and with separate implementations
for 32 and 64 bits. identify_cpu() is also implemented in assembly and
separately for 32 and 64 bits.

This patch replaces them with a pair of C functions. The call sites are
slightly moved on ppc64 as well to be called from C instead of from
assembly, though it's a very small change, and thus shouldn't cause any
problem.

Signed-off-by: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Acked-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Add 970GX cputable entry</title>
<updated>2006-10-23T08:23:17+00:00</updated>
<author>
<name>Jake Moilanen</name>
<email>moilanen@austin.ibm.com</email>
</author>
<published>2006-10-18T15:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=362ff7b2ac0234152b4a334dd006b77f4fa2ab23'/>
<id>362ff7b2ac0234152b4a334dd006b77f4fa2ab23</id>
<content type='text'>
970GX cputable entry from Steve Winiecki.

Signed-off-by: Jake Moilanen &lt;moilanen@austin.ibm.com&gt;

 arch/powerpc/kernel/cputable.c          |   15 +++++++++++++++
 arch/powerpc/oprofile/op_model_power4.c |    2 +-
 include/asm-powerpc/reg.h               |    1 +
 3 files changed, 17 insertions(+), 1 deletion(-)
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
970GX cputable entry from Steve Winiecki.

Signed-off-by: Jake Moilanen &lt;moilanen@austin.ibm.com&gt;

 arch/powerpc/kernel/cputable.c          |   15 +++++++++++++++
 arch/powerpc/oprofile/op_model_power4.c |    2 +-
 include/asm-powerpc/reg.h               |    1 +
 3 files changed, 17 insertions(+), 1 deletion(-)
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
