litmus-rt.git/arch/ppc64/Kconfig, branch v2.6.33-rc3

powerpc: Move most remaining ppc64 files over to arch/powerpc

2005-11-14T06:30:17+00:00

Also deletes files in arch/ppc64 that are no longer used now that
we don't compile with ARCH=ppc64 any more.

Signed-off-by: Paul Mackerras

[PATCH] ppc64: Convert NUMA to sparsemem (3)

2005-11-11T11:21:11+00:00

Convert to sparsemem and remove all the discontigmem code in the
process. This has a few advantages:

- The old numa_memory_lookup_table can go away
- All the arch specific discontigmem magic can go away

We also remove the triple pass of memory properties and instead create a
list of per node extents that we iterate through. A final cleanup would
be to change our lmb code to store extents per node, then we can reuse
that information in the numa code.

Signed-off-by: Anton Blanchard 
Signed-off-by: Paul Mackerras

[PATCH] Memory Add Fixes for ppc64

2005-11-08T04:17:38+00:00

ppc64 needs a special sysfs probe file for adding new memory.

Signed-off-by: Mike Kravetz 
Signed-off-by: Paul Mackerras

[PATCH] Memory Add Fixes for ppc64

2005-11-08T00:20:00+00:00

On Tue, Nov 08, 2005 at 08:12:56AM +1100, Benjamin Herrenschmidt wrote:
> Yes, the MAX_ORDER should be different indeed. But can Kconfig do that ?
> That is have the default value be different based on a Kconfig option ?
> I don't see that ... We may have to do things differently here...

This seems to be done in other parts of the Kconfig file.  Using those
as an example, this should keep the MAX_ORDER block size at 16MB.

Signed-off-by: Mike Kravetz 
Signed-off-by: Paul Mackerras

[PATCH] ppc64: SMU based macs cpufreq support

2005-11-08T00:17:34+00:00

CPU freq support using 970FX powertune facility for iMac G5 and SMU
based single CPU desktop.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Paul Mackerras

[PATCH] ppc64: support 64k pages

2005-11-07T00:56:47+00:00

Adds a new CONFIG_PPC_64K_PAGES which, when enabled, changes the kernel
base page size to 64K.  The resulting kernel still boots on any
hardware.  On current machines with 4K pages support only, the kernel
will maintain 16 "subpages" for each 64K page transparently.

Note that while real 64K capable HW has been tested, the current patch
will not enable it yet as such hardware is not released yet, and I'm
still verifying with the firmware architects the proper to get the
information from the newer hypervisors.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Linus Torvalds

powerpc: Merge smp-tbsync.c (the generic timebase sync routine)

2005-11-04T02:28:58+00:00

Signed-off-by: Paul Mackerras

[PATCH] ppc64 memory model depends on NUMA

2005-10-29T05:27:39+00:00

Currently when we first select memory model (FLAT, DISCONTIG, SPARSE) then
select whether the machine is NUMA.  However NUMA systems may not be FLAT.
This constraint it not honoured and we may configure a NUMA/FLAT system.

Reorder the configuration such that we choose NUMA first which allows us to
only list the memory models which are valid.  We now default NUMA for known
NUMA systems.  Note that this new order also matches that used in x86.

Signed-off-by: Andy Whitcroft 
Signed-off-by: Joel Schopp 
Signed-off-by: Andrew Morton 
Signed-off-by: Paul Mackerras

[PATCH] powerpc: Fix handling of fpscr on 64-bit

2005-10-27T10:48:50+00:00

The recent merge of fpu.S broken the handling of fpscr for
ARCH=powerpc and CONFIG_PPC64=y.  FP registers could be corrupted,
leading to strange random application crashes.

The confusion arises, because the thread_struct has (and requires) a
64-bit area to save the fpscr, because we use load/store double
instructions to get it in to/out of the FPU.  However, only the low
32-bits are actually used, so we want to treat it as a 32-bit quantity
when manipulating its bits to avoid extra load/stores on 32-bit.  This
patch replaces the current definition with a structure of two 32-bit
quantities (pad and val), to clarify things as much as is possible.
The 'val' field is used when manipulating bits, the structure itself
is used when obtaining the address for loading/unloading the value
from the FPU.

While we're at it, consolidate the 4 (!) almost identical versions of
cvt_fd() and cvt_df() (arch/ppc/kernel/misc.S,
arch/ppc64/kernel/misc.S, arch/powerpc/kernel/misc_32.S,
arch/powerpc/kernel/misc_64.S) into a single version in fpu.S.  The
new version takes a pointer to thread_struct and applies the correct
offset itself, rather than a pointer to the fpscr field itself, again
to avoid confusion as to which is the correct field to use.

Finally, this patch makes ARCH=ppc64 also use the consolidated fpu.S
code, which it previously did not.

Built for G5 (ARCH=ppc64 and ARCH=powerpc), 32-bit powermac (ARCH=ppc
and ARCH=powerpc) and Walnut (ARCH=ppc, CONFIG_MATH_EMULATION=y).
Booted on G5 (ARCH=powerpc) and things which previously fell over no
longer do.

Signed-off-by: David Gibson 
Signed-off-by: Paul Mackerras

powerpc: Merge rtas.c into arch/powerpc/kernel

2005-10-26T07:05:24+00:00

This splits arch/ppc64/kernel/rtas.c into arch/powerpc/kernel/rtas.c,
which contains generic RTAS functions useful on any CHRP platform,
and arch/powerpc/platforms/pseries/rtas-fw.[ch], which contain
some pSeries-specific firmware flashing bits.  The parts of rtas.c
that are to do with pSeries-specific error logging are protected
by a new CONFIG_RTAS_ERROR_LOGGING symbol.  The inclusion of rtas.o
is controlled by the CONFIG_PPC_RTAS symbol, and the relevant
platforms select that.

Signed-off-by: Paul Mackerras