[PATCH] ppc32: Resurrect Documentation/powerpc/cpu_features.txt

From: Arthur Othieno
Date: Sun Dec 19 2004 - 20:16:58 EST


Documentation/powerpc/cpu_features.txt mysteriously disappeared
sometime when 2.5 forked off.

Searching through BK logs on linux.bkbits.net didn't reveal anything,
unfortunately. The only reference I could pick up from searching the
available lkml archives is the 2.4.20-pre11 ChangeLog where this was
first merged.

Thus far, nothing indicates it was intentionally removed, and AFAICS,
is still up to date with the current code.

Against 2.6.9. Applies cleanly against 2.6.10-rc3. Thanks.

Signed-off-by: Arthur Othieno <a.othieno@xxxxxxxxxx>

00-INDEX | 3 ++
cpu_features.txt | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 59 insertions(+)

diff -uprN a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
--- a/Documentation/powerpc/00-INDEX 2003-12-18 03:59:16.000000000 +0100
+++ b/Documentation/powerpc/00-INDEX 2004-05-22 13:38:54.000000000 +0200
@@ -5,6 +5,9 @@ please mail me.

- this file
+ - info on how we support a variety of CPUs with minimal compile-time
+ options.
- info about the Linux/PPC /proc/ppc_htab entry
diff -uprN a/Documentation/powerpc/cpu_features.txt b/Documentation/powerpc/cpu_features.txt
--- a/Documentation/powerpc/cpu_features.txt 1970-01-01 01:00:00.000000000 +0100
+++ b/Documentation/powerpc/cpu_features.txt 2004-05-22 13:38:27.000000000 +0200
@@ -0,0 +1,56 @@
+Hollis Blanchard <hollis@xxxxxxxxxxxxxx>
+5 Jun 2002
+This document describes the system (including self-modifying code) used in the
+PPC Linux kernel to support a variety of PowerPC CPUs without requiring
+compile-time selection.
+Early in the boot process the ppc32 kernel detects the current CPU type and
+chooses a set of features accordingly. Some examples include Altivec support,
+split instruction and data caches, and if the CPU supports the DOZE and NAP
+sleep modes.
+Detection of the feature set is simple. A list of processors can be found in
+arch/ppc/kernel/cputable.c. The PVR register is masked and compared with each
+value in the list. If a match is found, the cpu_features of cur_cpu_spec is
+assigned to the feature bitmask for this processor and a __setup_cpu function
+is called.
+C code may test 'cur_cpu_spec[smp_processor_id()]->cpu_features' for a
+particular feature bit. This is done in quite a few places, for example
+in ppc_setup_l2cr().
+Implementing cpufeatures in assembly is a little more involved. There are
+several paths that are performance-critical and would suffer if an array
+index, structure dereference, and conditional branch were added. To avoid the
+performance penalty but still allow for runtime (rather than compile-time) CPU
+selection, unused code is replaced by 'nop' instructions. This nop'ing is
+based on CPU 0's capabilities, so a multi-processor system with non-identical
+processors will not work (but such a system would likely have other problems
+After detecting the processor type, the kernel patches out sections of code
+that shouldn't be used by writing nop's over it. Using cpufeatures requires
+just 2 macros (found in include/asm-ppc/cputable.h), as seen in head.S
+ mfspr r22,SPRN_VRSAVE /* if G4, save vrsave register value */
+ stw r22,THREAD_VRSAVE(r23)
+ #endif /* CONFIG_ALTIVEC */
+If CPU 0 supports Altivec, the code is left untouched. If it doesn't, both
+instructions are replaced with nop's.
+The END_FTR_SECTION macro has two simpler variations: END_FTR_SECTION_IFSET
+and END_FTR_SECTION_IFCLR. These simply test if a flag is set (in
+cur_cpu_spec[0]->cpu_features) or is cleared, respectively. These two macros
+should be used in the majority of cases.
+The END_FTR_SECTION macros are implemented by storing information about this
+code in the '__ftr_fixup' ELF section. When do_cpu_ftr_fixups
+(arch/ppc/kernel/misc.S) is invoked, it will iterate over the records in
+__ftr_fixup, and if the required feature is not present it will loop writing
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/