<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/powerpc/kernel/setup_32.c, branch v2.6.23</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>[POWERPC] Merge CPU features pertaining to icache coherency</title>
<updated>2007-06-14T12:30:16+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2007-06-13T04:52:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4508dc21feb189159d4cc1d5b79c5a55fad5f2ed'/>
<id>4508dc21feb189159d4cc1d5b79c5a55fad5f2ed</id>
<content type='text'>
Currently the powerpc kernel has a 64-bit only feature,
COHERENT_ICACHE used for those CPUS which maintain icache/dcache
coherency in hardware (POWER5, essentially).  It also has a feature,
SPLIT_ID_CACHE, which is used on CPUs which have separate i and
d-caches, which is to say everything except 601 and Freescale E200.

In nearly all the places we check the SPLIT_ID_CACHE, what we actually
care about is whether the i and d-caches are coherent (which they will
be, trivially, if they're the same cache).

This tries to clarify the situation a little.  The COHERENT_ICACHE
feature becomes availble on 32-bit and is set for all CPUs where i and
d-cache are effectively coherent, whether this is due to special logic
(POWER5) or because they're unified.  We check this, instead of
SPLIT_ID_CACHE nearly everywhere.

The SPLIT_ID_CACHE feature itself is replaced by a UNIFIED_ID_CACHE
feature with reversed sense, set only on 601 and Freescale E200.  In
the two places (one Freescale BookE specific) where we really care
whether it's a unified cache, not whether they're coherent, we check
this feature.  The CPUs with unified cache are so few, we could
consider replacing this feature bit with explicit checks against the
PVR.

This will make unifying the 32-bit and 64-bit cache flush code a
little more straightforward.

Signed-off-by: David Gibson &lt;dwg@au1.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>
Currently the powerpc kernel has a 64-bit only feature,
COHERENT_ICACHE used for those CPUS which maintain icache/dcache
coherency in hardware (POWER5, essentially).  It also has a feature,
SPLIT_ID_CACHE, which is used on CPUs which have separate i and
d-caches, which is to say everything except 601 and Freescale E200.

In nearly all the places we check the SPLIT_ID_CACHE, what we actually
care about is whether the i and d-caches are coherent (which they will
be, trivially, if they're the same cache).

This tries to clarify the situation a little.  The COHERENT_ICACHE
feature becomes availble on 32-bit and is set for all CPUs where i and
d-cache are effectively coherent, whether this is due to special logic
(POWER5) or because they're unified.  We check this, instead of
SPLIT_ID_CACHE nearly everywhere.

The SPLIT_ID_CACHE feature itself is replaced by a UNIFIED_ID_CACHE
feature with reversed sense, set only on 601 and Freescale E200.  In
the two places (one Freescale BookE specific) where we really care
whether it's a unified cache, not whether they're coherent, we check
this feature.  The CPUs with unified cache are so few, we could
consider replacing this feature bit with explicit checks against the
PVR.

This will make unifying the 32-bit and 64-bit cache flush code a
little more straightforward.

Signed-off-by: David Gibson &lt;dwg@au1.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Fix breakage caused by 72486f1f8f0a2bc828b9d30cf4690cf2dd6807fc</title>
<updated>2007-04-12T17:55:16+00:00</updated>
<author>
<name>Giuliano Pochini</name>
<email>pochini@shiny.it</email>
</author>
<published>2007-03-27T05:40:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5e41763ae9b4b6335fab88da85600f16d7a5a7b5'/>
<id>5e41763ae9b4b6335fab88da85600f16d7a5a7b5</id>
<content type='text'>
72486f1f8f0a2bc828b9d30cf4690cf2dd6807fc inverted the sense for enabling
hotplug CPU controls without reference to any other architecture other than
i386, ia64 and PowerPC.  This left everyone else without hotplug CPU control.

Fix powerpc for this brain damage.

(akpm: patch adapted from rmk's ARM fix.  Changelog stolen from rmk)

Signed-off-by: Giuliano Pochini &lt;pochini@shiny.it&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.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>
72486f1f8f0a2bc828b9d30cf4690cf2dd6807fc inverted the sense for enabling
hotplug CPU controls without reference to any other architecture other than
i386, ia64 and PowerPC.  This left everyone else without hotplug CPU control.

Fix powerpc for this brain damage.

(akpm: patch adapted from rmk's ARM fix.  Changelog stolen from rmk)

Signed-off-by: Giuliano Pochini &lt;pochini@shiny.it&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Russell King &lt;rmk@arm.linux.org.uk&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] 32-bit early_init() should zero from __bss_start to __bss_stop only</title>
<updated>2007-03-16T05:38:19+00:00</updated>
<author>
<name>Mark A. Greer</name>
<email>mgreer@mvista.com</email>
</author>
<published>2006-10-25T23:36:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=556b09c8189b9b3f5626ca73196009e397503f85'/>
<id>556b09c8189b9b3f5626ca73196009e397503f85</id>
<content type='text'>
Currently, early_init() in setup_32.c zeroes from '_bss_start' to '_end'.
It should only zero from '__bss_start' to '__bss_stop'.  This patch does that.

Signed-off-by: Mark A. Greer &lt;mgreer@mvista.com&gt;
Acked-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>
Currently, early_init() in setup_32.c zeroes from '_bss_start' to '_end'.
It should only zero from '__bss_start' to '__bss_stop'.  This patch does that.

Signed-off-by: Mark A. Greer &lt;mgreer@mvista.com&gt;
Acked-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] Use udbg_early_init() on ppc32</title>
<updated>2007-02-14T00:55:16+00:00</updated>
<author>
<name>David Gibson</name>
<email>david@gibson.dropbear.id.au</email>
</author>
<published>2007-02-13T04:54:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=719c91ccadd3ed26570dbb29d54166914832eee9'/>
<id>719c91ccadd3ed26570dbb29d54166914832eee9</id>
<content type='text'>
udbg_early_init() is a function used on 64 bit systems, which
initializes whichever early udbg backend is configured.  This function
is not called on 32-bit, however if btext early debug is enabled it
does have an explicit, inline, #ifdef-ed assignment performing
analagous initialization.

This patch makes things more uniform by folding the btext
initialization as an option into udbg_early_init() and calling that
from the 32-bit setup path.

Signed-off-by: David Gibson &lt;dwg@au1.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>
udbg_early_init() is a function used on 64 bit systems, which
initializes whichever early udbg backend is configured.  This function
is not called on 32-bit, however if btext early debug is enabled it
does have an explicit, inline, #ifdef-ed assignment performing
analagous initialization.

This patch makes things more uniform by folding the btext
initialization as an option into udbg_early_init() and calling that
from the 32-bit setup path.

Signed-off-by: David Gibson &lt;dwg@au1.ibm.com&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>[POWERPC] Add export of vgacon_remap_base</title>
<updated>2007-02-08T05:08:47+00:00</updated>
<author>
<name>Mathieu Desnoyers</name>
<email>compudj@krystal.dyndns.org</email>
</author>
<published>2007-02-08T00:04:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d003e7a1a569501cbe9a5ca14748177498c4893a'/>
<id>d003e7a1a569501cbe9a5ca14748177498c4893a</id>
<content type='text'>
The following macro :
include/asm-powerpc/vga.h:#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
is used by drivers/video/console/vgacon.c which can be compiled as a module
(drivers/video/vga16fb.ko).

Therefore, vgacon_remap_base should be exported.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@polymtl.ca&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The following macro :
include/asm-powerpc/vga.h:#define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
is used by drivers/video/console/vgacon.c which can be compiled as a module
(drivers/video/vga16fb.ko).

Therefore, vgacon_remap_base should be exported.

Signed-off-by: Mathieu Desnoyers &lt;mathieu.desnoyers@polymtl.ca&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>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>[PATCH] Clean up usage of boot_dev</title>
<updated>2006-11-13T03:44:59+00:00</updated>
<author>
<name>s.hauer@pengutronix.de</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2006-11-02T12:56:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fd6e7d2d6a0231ebfa08e1f9a323497ea548da7d'/>
<id>fd6e7d2d6a0231ebfa08e1f9a323497ea548da7d</id>
<content type='text'>
dev_t boot_dev is declared in arch/powerpc/kernel/setup_32.c
and in arch/powerpc/kernel/setup_64.c but not used in these files.
It is only used in arch/powerpc/platforms/powermac/setup.c, so make
it static in this file.

Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Acked-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>
dev_t boot_dev is declared in arch/powerpc/kernel/setup_32.c
and in arch/powerpc/kernel/setup_64.c but not used in these files.
It is only used in arch/powerpc/platforms/powermac/setup.c, so make
it static in this file.

Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Acked-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] 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>
</feed>
