[patch 3/3] cell: prevent alignment interrupt on local store

[patch 3/3] cell: prevent alignment interrupt on local store

[Akinobu Mita]

An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
stswi, or stswx, and the operand is in local store.

GCC generated such instructions to handle memcpy() instead of kernel
defined memcpy() without -mno-string option.

Signed-off-by: Akinobu Mita <mita@fixstars.com>

Index: 2.6-git-ps3/arch/powerpc/platforms/cell/spufs/Makefile
===================================================================
--- 2.6-git-ps3.orig/arch/powerpc/platforms/cell/spufs/Makefile
+++ 2.6-git-ps3/arch/powerpc/platforms/cell/spufs/Makefile
@@ -4,6 +4,11 @@ obj-$(CONFIG_SPU_FS) += spufs.o
 spufs-y += inode.o file.o context.o syscalls.o coredump.o
 spufs-y += sched.o backing_ops.o hw_ops.o run.o gang.o
 
+# An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
+# stswi, or stswx, and the operand is in local store.
+CFLAGS_run.o := -mno-string
+CFLAGS_file.o := -mno-string
+
 # Rules to build switch.o with the help of SPU tool chain
 SPU_CROSS	:= spu-
 SPU_CC		:= $(SPU_CROSS)gcc

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

> An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, 
> lswx,
> stswi, or stswx, and the operand is in local store.
>
> GCC generated such instructions to handle memcpy() instead of kernel
> defined memcpy() without -mno-string option.

> +# An Alignment interrupt occurs when the instruction is lmw, stmw, 
> lswi, lswx,
> +# stswi, or stswx, and the operand is in local store.
> +CFLAGS_run.o := -mno-string
> +CFLAGS_file.o := -mno-string

NAK.  Please use memcpy_fromio() and friends instead,
that's what they're there for.  I believe Arnd was working
on this?

Your patch is only a partial solution, you'd need -mno-multiple
-mno-algebraic -mno-dcbz too (and two of those don't even
exist).


Segher

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Akinobu Mita]

On Tue, Apr 10, 2007 at 02:52:33PM +0200, Segher Boessenkool wrote:
> >An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, 
> >lswx,
> >stswi, or stswx, and the operand is in local store.
> >
> >GCC generated such instructions to handle memcpy() instead of kernel
> >defined memcpy() without -mno-string option.
> 
> >+# An Alignment interrupt occurs when the instruction is lmw, stmw, 
> >lswi, lswx,
> >+# stswi, or stswx, and the operand is in local store.
> >+CFLAGS_run.o := -mno-string
> >+CFLAGS_file.o := -mno-string
> 
> NAK.  Please use memcpy_fromio() and friends instead,
> that's what they're there for.  I believe Arnd was working
> on this?
> 
> Your patch is only a partial solution, you'd need -mno-multiple
> -mno-algebraic -mno-dcbz too (and two of those don't even
> exist).

This is the patch which fix the problem with using memcpy_fromio/toio()
on LS. It seems better than adding many -mno-* options to specific
files.

From: Akinobu Mita <mita@fixstars.com>
Subject: spufs: use memcpy_fromio() to copy from local store

GCC may generates inline copy loop to handle memcpy() function
instead of kernel defined memcpy(). But this inlined version of memcpy()
causes an alignment interrupt when copying from local store.

This patch uses memcpy_fromio() and memcpy_toio to copy local store
to prevent memcpy() being inlined.

Signed-off-by: Akinobu Mita <mita@fixstars.com>

---
 arch/powerpc/platforms/cell/spufs/run.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: 2.6-git-ps3/arch/powerpc/platforms/cell/spufs/run.c
===================================================================
--- 2.6-git-ps3.orig/arch/powerpc/platforms/cell/spufs/run.c
+++ 2.6-git-ps3/arch/powerpc/platforms/cell/spufs/run.c
@@ -260,10 +260,10 @@ int spu_process_callback(struct spu_cont
 	/* get syscall block from local store */
 	npc = ctx->ops->npc_read(ctx);
 	ls = ctx->ops->get_ls(ctx);
-	ls_pointer = *(u32*)(ls + npc);
+	ls_pointer = *(u32 *)(ls + npc);
 	if (ls_pointer > (LS_SIZE - sizeof(s)))
 		return -EFAULT;
-	memcpy(&s, ls + ls_pointer, sizeof (s));
+	memcpy_fromio(&s, ls + ls_pointer, sizeof(s));
 
 	/* do actual syscall without pinning the spu */
 	ret = 0;
@@ -283,7 +283,7 @@ int spu_process_callback(struct spu_cont
 	}
 
 	/* write result, jump over indirect pointer */
-	memcpy(ls + ls_pointer, &spu_ret, sizeof (spu_ret));
+	memcpy_toio(ls + ls_pointer, &spu_ret, sizeof(spu_ret));
 	ctx->ops->npc_write(ctx, npc);
 	ctx->ops->runcntl_write(ctx, SPU_RUNCNTL_RUNNABLE);
 	return ret;

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Benjamin Herrenschmidt]

On Tue, 2007-04-10 at 20:15 +0900, Akinobu Mita wrote:
> An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
> stswi, or stswx, and the operand is in local store.
> 
> GCC generated such instructions to handle memcpy() instead of kernel
> defined memcpy() without -mno-string option.
> 
> Signed-off-by: Akinobu Mita <mita@fixstars.com>

I would personally prefer building the entire kernel with -mno-string
when cell support is enabled...

Ben.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Akinobu Mita]

On Wed, Apr 11, 2007 at 07:22:48AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2007-04-10 at 20:15 +0900, Akinobu Mita wrote:
> > An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
> > stswi, or stswx, and the operand is in local store.
> > 
> > GCC generated such instructions to handle memcpy() instead of kernel
> > defined memcpy() without -mno-string option.
> > 
> > Signed-off-by: Akinobu Mita <mita@fixstars.com>
> 
> I would personally prefer building the entire kernel with -mno-string
> when cell support is enabled...

I'm about to resend the patch which prevent alignment interrupts on LS
by using memcpy_fromio() rather than putting a collection of -mno-* options
in Makefile. (only -mno-string is not enough to prevent that as Segher said)

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Benjamin Herrenschmidt]

On Wed, 2007-04-11 at 11:56 +0900, Akinobu Mita wrote:
> On Wed, Apr 11, 2007 at 07:22:48AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2007-04-10 at 20:15 +0900, Akinobu Mita wrote:
> > > An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
> > > stswi, or stswx, and the operand is in local store.
> > > 
> > > GCC generated such instructions to handle memcpy() instead of kernel
> > > defined memcpy() without -mno-string option.
> > > 
> > > Signed-off-by: Akinobu Mita <mita@fixstars.com>
> > 
> > I would personally prefer building the entire kernel with -mno-string
> > when cell support is enabled...
> 
> I'm about to resend the patch which prevent alignment interrupts on LS
> by using memcpy_fromio() rather than putting a collection of -mno-* options
> in Makefile. (only -mno-string is not enough to prevent that as Segher said)

Sure, however we also know for sure that string instructions will suck a
LOT on a cell ... so for a multi platforms kernel that has cell support
built-in, it makes some sense to not use them.

Ben.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

>>> I would personally prefer building the entire kernel with -mno-string
>>> when cell support is enabled...
>>
>> I'm about to resend the patch which prevent alignment interrupts on LS
>> by using memcpy_fromio() rather than putting a collection of -mno-* 
>> options
>> in Makefile. (only -mno-string is not enough to prevent that as 
>> Segher said)
>
> Sure, however we also know for sure that string instructions will suck 
> a
> LOT on a cell ... so for a multi platforms kernel that has cell support
> built-in, it makes some sense to not use them.

[That's a separate issue and should be handled as a
separate patch series.]

Not only string insns are slow on the current Cell core,
many more insns are, including all dot insns; and those
are way more expensive in comparison.  Turning off
generation of string insns only won't help Cell much.

Building a multiplatform kernel with all the insns that
are expensive on Cell turned off will hurt a lot on most
other CPUs.

This isn't just a kernel issue either; the same holds
for all of userspace.  It seems to me the only way to
get good performance on both Cell and all other platforms
is to have a separate binary distribution for Cell.


Segher

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Olaf Hering]

On Wed, Apr 11, Segher Boessenkool wrote:

> This isn't just a kernel issue either; the same holds
> for all of userspace.  It seems to me the only way to
> get good performance on both Cell and all other platforms
> is to have a separate binary distribution for Cell.

How much will this impact performance on a 970, 74xx or POWER6 if
everything gets compiled with '--mcpu=$cell', compared to what is used
today? One gets at least altivec that way.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Benjamin Herrenschmidt]

On Thu, 2007-04-12 at 06:23 +0200, Olaf Hering wrote:
> On Wed, Apr 11, Segher Boessenkool wrote:
> 
> > This isn't just a kernel issue either; the same holds
> > for all of userspace.  It seems to me the only way to
> > get good performance on both Cell and all other platforms
> > is to have a separate binary distribution for Cell.
> 
> How much will this impact performance on a 970, 74xx or POWER6 if
> everything gets compiled with '--mcpu=$cell', compared to what is used
> today? One gets at least altivec that way.

Gets altivec and stops working on POWER5 ? no deal :-)

Ben.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Olaf Hering]

On Thu, Apr 12, Benjamin Herrenschmidt wrote:

> Gets altivec and stops working on POWER5 ? no deal :-)

If there is a significant performance gain (not only 9%) and if
-mcpu=$cell does not generate instructions that wont work on other
altivec capable cpus and if rpm gets a target ppcaltivec.rpm (or
similar), as separate binary tree can be done.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Benjamin Herrenschmidt]

On Thu, 2007-04-12 at 08:33 +0200, Olaf Hering wrote:
> On Thu, Apr 12, Benjamin Herrenschmidt wrote:
> 
> > Gets altivec and stops working on POWER5 ? no deal :-)
> 
> If there is a significant performance gain (not only 9%) and if
> -mcpu=$cell does not generate instructions that wont work on other
> altivec capable cpus and if rpm gets a target ppcaltivec.rpm (or
> similar), as separate binary tree can be done.

-mcpu=cell can possibly generate things that won't run on 970 and 74xx.
There are some new altivec instructions among others...

Ben.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Gabriel Paubert]

On Thu, Apr 12, 2007 at 04:38:10PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2007-04-12 at 08:33 +0200, Olaf Hering wrote:
> > On Thu, Apr 12, Benjamin Herrenschmidt wrote:
> > 
> > > Gets altivec and stops working on POWER5 ? no deal :-)
> > 
> > If there is a significant performance gain (not only 9%) and if
> > -mcpu=$cell does not generate instructions that wont work on other
> > altivec capable cpus and if rpm gets a target ppcaltivec.rpm (or
> > similar), as separate binary tree can be done.
> 
> -mcpu=cell can possibly generate things that won't run on 970 and 74xx.
> There are some new altivec instructions among others...

Any pointer to a document describing the differences?

	Regards,
	Gabriel

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Benjamin Herrenschmidt]

On Thu, 2007-04-12 at 10:31 +0200, Gabriel Paubert wrote:
> On Thu, Apr 12, 2007 at 04:38:10PM +1000, Benjamin Herrenschmidt wrote:
> > On Thu, 2007-04-12 at 08:33 +0200, Olaf Hering wrote:
> > > On Thu, Apr 12, Benjamin Herrenschmidt wrote:
> > > 
> > > > Gets altivec and stops working on POWER5 ? no deal :-)
> > > 
> > > If there is a significant performance gain (not only 9%) and if
> > > -mcpu=$cell does not generate instructions that wont work on other
> > > altivec capable cpus and if rpm gets a target ppcaltivec.rpm (or
> > > similar), as separate binary tree can be done.
> > 
> > -mcpu=cell can possibly generate things that won't run on 970 and 74xx.
> > There are some new altivec instructions among others...
> 
> Any pointer to a document describing the differences?

I'm not sure where this is documented. There are a few new ops for
doing load/save of partial vectors (to help handle edge cases),
there are some more precise implementation of some fp osp (though
that should be backward compatible), and maybe a few other things.

I think most public cell docs can be found at

http://www-306.ibm.com/chips/techlib/techlib.nsf/products/Cell_Broadband_Engine

Though I have no idea where those specifics are described.

Cheers,
Ben.

Re: [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

>> This isn't just a kernel issue either; the same holds
>> for all of userspace.  It seems to me the only way to
>> get good performance on both Cell and all other platforms
>> is to have a separate binary distribution for Cell.
>
> How much will this impact performance on a 970, 74xx or POWER6 if
> everything gets compiled with '--mcpu=$cell', compared to what is used
> today? One gets at least altivec that way.

Can't comment on POWER6; but on 74xx or 970 it will
hurt.  A lot.  Say 20-%30% or so?  [Yes I have no
benchmark data to back this up].


Segher

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Michael Ellerman]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

On Thu, 2007-04-12 at 08:50 +0200, Segher Boessenkool wrote:
> ...

> [Yes I have no benchmark data to back this up].

Which is the problem with this whole thread ...

:)

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

>> [Yes I have no benchmark data to back this up].
>
> Which is the problem with this whole thread ...

Indeed.  It's not just me though :-)


Segher

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Arnd Bergmann]

On Thursday 12 April 2007, Olaf Hering wrote:
> How much will this impact performance on a 970, 74xx or POWER6 if
> everything gets compiled with '--mcpu=$cell', compared to what is used
> today? One gets at least altivec that way.

Building with -mcpu=cell won't work on 970 or g4, because that enables
a few extra instructions that were not present in the older cpus.

If you know you want to build with altivec (i.e. not run on power4 or
older), then '-m32 -mcpu=7450 -mtune=cell' or '-m64 -mcpu=970 -mtune=cell'
would be a reasonable thing to try.

	Arnd <><

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Arnd Bergmann]

On Thursday 12 April 2007, Arnd Bergmann wrote:
> On Thursday 12 April 2007, Olaf Hering wrote:
> > How much will this impact performance on a 970, 74xx or POWER6 if
> > everything gets compiled with '--mcpu=$cell', compared to what is used
> > today? One gets at least altivec that way.
> 
> Building with -mcpu=cell won't work on 970 or g4, because that enables
> a few extra instructions that were not present in the older cpus.
> 
> If you know you want to build with altivec (i.e. not run on power4 or
> older), then '-m32 -mcpu=7450 -mtune=cell' or '-m64 -mcpu=970 -mtune=cell'
> would be a reasonable thing to try.

Ok, ignore my comment, as benh pointed out even power5 doesn't have altivec.
I don't know how many versions of libc you are currently building, but it
probably makes sense to have at least one that uses altivec, and one for
in-order (e.g. cell) and out-of-order (e.g. power5) pipelines each.

	Arnd <><

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

> I don't know how many versions of libc you are currently building, but 
> it
> probably makes sense to have at least one that uses altivec, and one 
> for
> in-order (e.g. cell) and out-of-order (e.g. power5) pipelines each.

Something compiled for one in-order CPU will not run
very well on any other in-order CPU; each has specific
hazards (like any CPU core, but on in-order it tends
to _hurt_ if you hit any).

(Almost) all "generic" optimisations for in-order cores
(schedule dependent insns far apart, ...) help even
*more* on OoOE cores since those tend to be wider.

The big issue on the Cell PPU is that it simply cannot
execute half of the insns in the PowerPC architecture
at a reasonable speed.


Segher

Re: [Cbe-oss-dev] [patch 3/3] cell: prevent alignment interrupt on local store

[Segher Boessenkool]

> Building with -mcpu=cell won't work on 970 or g4, because that enables
> a few extra instructions that were not present in the older cpus.
>
> If you know you want to build with altivec (i.e. not run on power4 or
> older), then '-m32 -mcpu=7450 -mtune=cell' or '-m64 -mcpu=970 
> -mtune=cell'
> would be a reasonable thing to try.

-mcpu=powerpc64 -mtune=cell


Segher

[RFC, PATCH] selection of CPU optimization

[Arnd Bergmann]

On Tuesday 10 April 2007, Benjamin Herrenschmidt wrote:
> On Tue, 2007-04-10 at 20:15 +0900, Akinobu Mita wrote:
> > An Alignment interrupt occurs when the instruction is lmw, stmw, lswi, lswx,
> > stswi, or stswx, and the operand is in local store.
> > 
> > GCC generated such instructions to handle memcpy() instead of kernel
> > defined memcpy() without -mno-string option.
> > 
> > Signed-off-by: Akinobu Mita <mita@fixstars.com>
> 
> I would personally prefer building the entire kernel with -mno-string
> when cell support is enabled...

The -mno-string flag should be set when _optimizing_ for cell, which it
probably is, but not when enabling a platform that runs on cell.

I recently experimented with cleaning up the CPU type selection in powerpc
in general, by splitting the selection into four groups:

1. CPU architecture (64 bit powerpc, 32 bit common, FSL book E, 4xx, ...)
  this is roughly what we have already and limits the other options
2. Minimum CPU level (power3, power4, 970, cell, ....)
  this selects the instruction set with -mcpu=xxx, but assumes that some
  CPUs use are a superset of others.
3. Optimization for a CPU (same list as above)
  compatible in both ways, but can optimize only for CPUs that were not
  excluded in step 2.
4. platform selection (mac, pseries, prep, 83xx, 86xx, ...)
  unchanged from now, but depends on 1. and 2. Depending on 1, you may
  choose multiple platforms simultaneously, or just one.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Index: linux-cg/arch/powerpc/Kconfig.cputype
===================================================================
--- /dev/null
+++ linux-cg/arch/powerpc/Kconfig.cputype
@@ -0,0 +1,610 @@
+menu "Processor support"
+choice
+	prompt "Processor Type"
+	default 6xx
+	help
+	  There are four families of PowerPC chips supported.  The more common
+	  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
+	  versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
+	  embedded versions (403 and 405) and the high end 64 bit Power
+	  processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
+
+config PPC64
+	bool "Any 64 bit processor"
+	help
+	  This option is the catch-all for all 64 bit processors, including
+	  the IBM Power3/4/5/6, PowerPC 970 (G5), Cell Broadband Engine,
+	  and the PA Semi PA6T.
+
+config PPC_6xx
+	bool "52xx/6xx/7xx/74xx/82xx/83xx/86xx"
+	select PPC_FPU
+	select 6xx
+	help
+	  This option is the catch-all for 6xx types, including some of the
+	  embedded versions.  Unless there is see an option for the specific
+	  chip family you are using, you want this option.
+
+	  If unsure, select this option.
+
+config PPC_85xx
+	bool "Freescale 85xx"
+	select E500
+	select FSL_SOC
+	select 85xx
+
+config PPC_8xx
+	bool "Freescale 8xx"
+	select FSL_SOC
+	select 8xx
+
+config 40x
+	bool "AMCC 40x"
+	select PPC_DCR_NATIVE
+
+config 44x
+	bool "AMCC 44x"
+	select PPC_DCR_NATIVE
+
+config E200
+	bool "Freescale e200"
+
+endchoice
+
+#choice
+#	prompt "Type of 6xx package"
+#	default CLASSIC32
+#	depends on PPC_6xx
+#
+config CLASSIC32
+	bool "Classic 52xx/6xx/7xx/74xx"
+	select 6xx
+	select PPC_FPU
+
+config PPC_82xx
+	bool "Embedded Freescale 82xx"
+	select 6xx
+	select PPC_FPU
+
+config PPC_83xx
+	bool "Embedded Freescale 83xx"
+	select 6xx
+	select FSL_SOC
+	select 83xx
+	select PPC_FPU
+
+config PPC_86xx
+	bool "Embedded Freescale 86xx"
+	select 6xx
+	select FSL_SOC
+	select PPC_FPU
+	select ALTIVEC
+	help
+	  The Freescale E600 SoCs have 74xx cores.
+# endchoice
+
+choice
+	prompt "Processor level"
+	default PPC_CPU_POWER3 if PPC64
+
+config PPC_CPU_UNSPECIFIED
+	bool "Use compiler default"
+
+config PPC_CPU_ANY64
+	bool "Generic 64 bit PowerPC"
+	depends on PPC64
+	select PPC_ENABLE_ANY64
+
+config PPC_CPU_RS64
+	bool "RS64 (Northstar/Pulsar/Icestar/Sstar)"
+	depends on PPC64
+	select PPC_ENABLE_RS64
+
+config PPC_CPU_POWER3
+	bool "Power3"
+	depends on PPC64
+	select PPC_ENABLE_POWER3
+
+config PPC_CPU_POWER4
+	bool "Power4"
+	depends on PPC64
+	select PPC_ENABLE_POWER4
+
+config PPC_CPU_POWER5
+	bool "Power5"
+	depends on PPC64
+	select PPC_ENABLE_POWER5
+	select ALTIVEC
+
+config PPC_CPU_POWER5PLUS
+	bool "Power5+"
+	depends on PPC64
+	select PPC_ENABLE_POWER5PLUS
+	select ALTIVEC
+
+config PPC_CPU_POWER6
+	bool "Power6"
+	depends on PPC64
+	select PPC_ENABLE_PA6T
+	select PPC_ENABLE_POWER6
+	select ALTIVEC
+
+config PPC_CPU_970
+	bool "PowerPC 970 (G5)"
+	depends on PPC64
+	select PPC_ENABLE_970
+	select ALTIVEC
+
+config PPC_CPU_CELLBE
+	bool "Cell Broadband Engine"
+	depends on PPC64
+	select PPC_ENABLE_CELLBE
+	select PPC_ENABLE_PA6T
+	select PPC_ENABLE_POWER6
+	select ALTIVEC
+
+config PPC_CPU_PA6T
+	bool "PA Semi PA6T"
+	depends on PPC64
+	select PPC_ENABLE_PA6T
+	select PPC_ENABLE_POWER6
+	select ALTIVEC
+
+config PPC_CPU_ANY32
+	bool "Generic 32 bit PowerPC"
+	depends on PPC_6xx || PPC_8xx || 4xx || E200 || E500
+	select PPC_ENABLE_ALTIVEC
+
+config PPC_CPU_601
+	bool "601 (G1)"
+	depends on CLASSIC32
+
+config PPC_CPU_603
+	bool "603/603e/82xx/83xx/e300 (G2)"
+	depends on CLASSIC32 || PPC_82xx || PPC_83xx
+
+config PPC_CPU_604
+	bool "604/604e/604r/604ev"
+	depends on CLASSIC32
+
+config PPC_CPU_750
+	bool "750/750CX/750CXe/750FX/750GX (G3)"
+	depends on CLASSIC32
+
+config PPC_CPU_7400
+	bool "7400/7410"
+	depends on CLASSIC32
+	select ALTIVEC
+
+config PPC_CPU_7450
+	bool "7450/7447/7457/7448/7450/86xx (G4)"
+	depends on CLASSIC32 || PPC_86xx
+	select ALTIVEC
+
+config PPC_CPU_801
+	bool "801"
+	depends on PPC_8xx
+
+config PPC_CPU_821
+	bool "821"
+	depends on PPC_8xx
+
+config PPC_CPU_823
+	bool "823"
+	depends on PPC_8xx
+
+config PPC_CPU_860
+	bool "860"
+	depends on PPC_8xx
+
+config PPC_CPU_403
+	bool "403"
+	depends on 40x
+
+config PPC_CPU_405
+	bool "405"
+	depends on 40x
+
+config PPC_CPU_440
+	bool "440"
+	depends on 44x
+
+config PPC_CPU_E200
+	bool "e200/5554"
+	depends on E200
+
+config PPC_CPU_E500
+	bool "e500/8540/8548"
+	depends on E500
+endchoice
+
+config PPC_ENABLE_ANY64
+	bool
+	select PPC_ENABLE_RS64
+
+config PPC_ENABLE_POWER3
+	bool
+	select PPC_ENABLE_POWER4
+
+config PPC_ENABLE_POWER4
+	bool
+	select PPC_ENABLE_POWER5
+	select PPC_ENABLE_970
+
+config PPC_ENABLE_POWER5
+	bool
+	select PPC_ENABLE_POWER5PLUS
+	select PPC_ENABLE_CELLBE
+
+config PPC_ENABLE_POWER5PLUS
+	bool
+	select PPC_ENABLE_POWER6
+
+config PPC_ENABLE_POWER6
+	bool
+	select PPC_ENABLE_ALTIVEC
+
+config PPC_ENABLE_RS64
+	bool
+	select PPC_ENABLE_POWER3
+
+config PPC_ENABLE_970
+	bool
+	select PPC_ENABLE_POWER5
+
+config PPC_ENABLE_CELLBE
+	bool
+
+config PPC_ENABLE_PA6T
+	bool
+
+choice
+	prompt "Tune for processor"
+
+config PPC_TUNE_UNSPECIFIED
+	bool "Use compiler default"
+
+config PPC_TUNE_ANY64
+	bool "Generic 64 bit PowerPC"
+	depends on PPC64
+
+config PPC_TUNE_RS64
+	bool "RS64 (Northstar/Pulsar/Icestar/Sstar)"
+	depends on PPC_ENABLE_RS64
+
+config PPC_TUNE_POWER3
+	bool "Power3"
+	depends on PPC_ENABLE_POWER3
+
+config PPC_TUNE_POWER4
+	bool "Power4"
+	depends on PPC_ENABLE_POWER4
+
+config PPC_TUNE_POWER5
+	bool "Power5"
+	depends on PPC_ENABLE_POWER5
+
+config PPC_TUNE_POWER5PLUS
+	bool "Power5+"
+	depends on PPC_ENABLE_POWER5PLUS
+
+config PPC_TUNE_POWER6
+	bool "Power6"
+	depends on PPC_ENABLE_POWER6
+
+config PPC_TUNE_970
+	bool "PowerPC 970 (G5)"
+	depends on PPC_ENABLE_970
+
+config PPC_TUNE_CELLBE
+	bool "Cell Broadband Engine"
+	depends on PPC_ENABLE_CELLBE
+
+config PPC_TUNE_PA6T
+	bool "PA Semi PA6T"
+	depends on PPC_ENABLE_PA6T
+
+config PPC_TUNE_ANY32
+	bool "Generic 32 bit PowerPC"
+	depends on PPC32
+	select PPC_ENABLE_ALTIVEC
+
+config PPC_TUNE_601
+	bool "601 (G1)"
+	depends on CLASSIC32
+
+config PPC_TUNE_603
+	bool "603/603e/82xx/83xx/e300 (G2)"
+	depends on CLASSIC32 || PPC_82xx || PPC_83xx
+
+config PPC_TUNE_604
+	bool "604/604e/604r/604ev"
+	depends on CLASSIC32
+
+config PPC_TUNE_750
+	bool "750/750CX/750CXe/750FX/750GX (G3)"
+	depends on CLASSIC32
+
+config PPC_TUNE_7400
+	bool "7400/7410"
+	depends on CLASSIC32
+
+config PPC_TUNE_7450
+	bool "7450/7447/7457/7448/7450/86xx (G4)"
+	depends on CLASSIC32 || PPC_86xx
+
+config PPC_TUNE_801
+	bool "801"
+	depends on PPC_8xx
+
+config PPC_TUNE_821
+	bool "821"
+	depends on PPC_8xx
+
+config PPC_TUNE_823
+	bool "823"
+	depends on PPC_8xx
+
+config PPC_TUNE_860
+	bool "860"
+	depends on PPC_8xx
+
+config PPC_TUNE_403
+	bool "403"
+	depends on 40x
+
+config PPC_TUNE_405
+	bool "405"
+	depends on 40x
+
+config PPC_TUNE_440
+	bool "440"
+	depends on 44x
+
+config PPC_TUNE_E200
+	bool "e200/5554"
+	depends on E200
+
+config PPC_TUNE_E500
+	bool "e500/8540/8548"
+	depends on E500
+
+endchoice
+
+config PPC_ENABLE_ALTIVEC
+	bool
+
+config PPC_CPU_FLAG
+	string
+	default "" if PPC_CPU_UNSPECIFIED
+	default "-mcpu=powerpc64" if PPC_CPU_ANY64
+	default "-mcpu=rs64" if PPC_CPU_RS64
+	default "-mcpu=power3" if PPC_CPU_POWER3
+	default "-mcpu=power4" if PPC_CPU_POWER4
+	default "-mcpu=power5" if PPC_CPU_POWER5
+	default "-mcpu=power5+" if PPC_CPU_POWER5PLUS
+	default "-mcpu=power6" if PPC_CPU_POWER6
+	default "-mcpu=970" if PPC_CPU_970
+	default "" if PPC_CPU_CELLBE
+	default "" if PPC_CPU_PA6T
+	default "-mcpu=powerpc" if PPC_CPU_ANY32
+	default "-mcpu=601" if PPC_CPU_601
+	default "-mcpu=603" if PPC_CPU_603
+	default "-mcpu=604" if PPC_CPU_604
+	default "-mcpu=750" if PPC_CPU_750
+	default "-mcpu=7400" if PPC_CPU_7400
+	default "-mcpu=7450" if PPC_CPU_7450
+	default "-mcpu=801" if PPC_CPU_801
+	default "-mcpu=821" if PPC_CPU_821
+	default "-mcpu=823" if PPC_CPU_823
+	default "-mcpu=860" if PPC_CPU_860
+	default "-mcpu=403" if PPC_CPU_403
+	default "-mcpu=405" if PPC_CPU_405
+	default "-mcpu=440" if PPC_CPU_440
+	default "" if PPC_CPU_E200
+	default "" if PPC_CPU_E500
+
+config PPC_TUNE_FLAG
+	string
+	default "" if PPC_TUNE_UNSPECIFIED
+	default "-mtune=powerpc64" if PPC_TUNE_ANY64
+	default "-mtune=rs64" if PPC_TUNE_RS64
+	default "-mtune=power3" if PPC_TUNE_POWER3
+	default "-mtune=power4" if PPC_TUNE_POWER4
+	default "-mtune=power5" if PPC_TUNE_POWER5
+	default "-mtune=power5+" if PPC_TUNE_POWER5PLUS
+	default "-mtune=power6" if PPC_TUNE_POWER6
+	default "-mtune=970" if PPC_TUNE_970
+	default "" if PPC_TUNE_CELLBE
+	default "" if PPC_TUNE_PA6T
+	default "-mtune=powerpc" if PPC_TUNE_ANY32
+	default "-mtune=601" if PPC_TUNE_601
+	default "-mtune=603" if PPC_TUNE_603
+	default "-mtune=604" if PPC_TUNE_604
+	default "-mtune=750" if PPC_TUNE_750
+	default "-mtune=7400" if PPC_TUNE_7400
+	default "-mtune=7450" if PPC_TUNE_7450
+	default "-mtune=801" if PPC_TUNE_801
+	default "-mtune=821" if PPC_TUNE_821
+	default "-mtune=823" if PPC_TUNE_823
+	default "-mtune=860" if PPC_TUNE_860
+	default "-mtune=403" if PPC_TUNE_403
+	default "-mtune=405" if PPC_TUNE_405
+	default "-mtune=440" if PPC_TUNE_440
+	default "" if PPC_TUNE_E200
+	default "" if PPC_TUNE_E500
+
+# these are temp to transition to new cpu selection
+config POWER3
+	bool
+	depends on PPC_ENABLE_POWER3 || PPC_ENABLE_RS64
+	default y
+
+config POWER4
+	depends on PPC64
+	def_bool y
+
+config POWER4_ONLY
+	bool
+	default y if !PPC_POWER3
+
+config 6xx
+	bool
+
+# this is temp to handle compat with arch=ppc
+config 8xx
+	bool
+
+# this is temp to handle compat with arch=ppc
+config 83xx
+	bool
+
+# this is temp to handle compat with arch=ppc
+config 85xx
+	bool
+
+config E500
+	bool
+
+config PPC_FPU
+	bool
+	default y if PPC64
+
+config PPC_DCR_NATIVE
+	bool
+	default n
+
+config PPC_DCR_MMIO
+	bool
+	default n
+
+config PPC_DCR
+	bool
+	depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
+	default y
+
+config PPC_OF_PLATFORM_PCI
+	bool
+	depends on PPC64 # not supported on 32 bits yet
+	default n
+
+config BOOKE
+	bool
+	depends on E200 || E500
+	default y
+
+config FSL_BOOKE
+	bool
+	depends on E200 || E500
+	default y
+
+config PTE_64BIT
+	bool
+	depends on 44x || E500
+	default y if 44x
+	default y if E500 && PHYS_64BIT
+
+config PHYS_64BIT
+	bool 'Large physical address support' if E500
+	depends on 44x || E500
+	select RESOURCES_64BIT
+	default y if 44x
+	---help---
+	  This option enables kernel support for larger than 32-bit physical
+	  addresses.  This features is not be available on all e500 cores.
+
+	  If in doubt, say N here.
+
+config ALTIVEC
+	bool "AltiVec Support"
+	depends on PPC64 || PPC_CPU_ANY32 || CLASSIC32
+	---help---
+	  This option enables kernel support for the Altivec extensions to the
+	  PowerPC processor. The kernel currently supports saving and restoring
+	  altivec registers, and turning on the 'altivec enable' bit so user
+	  processes can execute altivec instructions.
+
+	  This option is only usefully if you have a processor that supports
+	  altivec (G4, otherwise known as 74xx series), but does not have
+	  any affect on a non-altivec cpu (it does, however add code to the
+	  kernel).
+
+	  If in doubt, say Y here.
+
+config SPE
+	bool "SPE Support"
+	depends on E200 || E500
+	default y
+	---help---
+	  This option enables kernel support for the Signal Processing
+	  Extensions (SPE) to the PowerPC processor. The kernel currently
+	  supports saving and restoring SPE registers, and turning on the
+	  'spe enable' bit so user processes can execute SPE instructions.
+
+	  This option is only useful if you have a processor that supports
+	  SPE (e500, otherwise known as 85xx series), but does not have any
+	  effect on a non-spe cpu (it does, however add code to the kernel).
+
+	  If in doubt, say Y here.
+
+config PPC_STD_MMU
+	bool
+	depends on 6xx || POWER3 || POWER4 || PPC64
+	default y
+
+config PPC_STD_MMU_32
+	def_bool y
+	depends on PPC_STD_MMU && PPC32
+
+config PPC_MM_SLICES
+	bool
+	default y if HUGETLB_PAGE
+	default n
+
+config VIRT_CPU_ACCOUNTING
+	bool "Deterministic task and CPU time accounting"
+	depends on PPC64
+	default y
+	help
+	  Select this option to enable more accurate task and CPU time
+	  accounting.  This is done by reading a CPU counter on each
+	  kernel entry and exit and on transitions within the kernel
+	  between system, softirq and hardirq state, so there is a
+	  small performance impact.  This also enables accounting of
+	  stolen time on logically-partitioned systems running on
+	  IBM POWER5-based machines.
+
+	  If in doubt, say Y here.
+
+config SMP
+	depends on PPC_STD_MMU
+	bool "Symmetric multi-processing support"
+	---help---
+	  This enables support for systems with more than one CPU. If you have
+	  a system with only one CPU, say N. If you have a system with more
+	  than one CPU, say Y.  Note that the kernel does not currently
+	  support SMP machines with 603/603e/603ev or PPC750 ("G3") processors
+	  since they have inadequate hardware support for multiprocessor
+	  operation.
+
+	  If you say N here, the kernel will run on single and multiprocessor
+	  machines, but will use only one CPU of a multiprocessor machine. If
+	  you say Y here, the kernel will run on single-processor machines.
+	  On a single-processor machine, the kernel will run faster if you say
+	  N here.
+
+	  If you don't know what to do here, say N.
+
+config NR_CPUS
+	int "Maximum number of CPUs (2-128)"
+	range 2 128
+	depends on SMP
+	default "32" if PPC64
+	default "4"
+
+config NOT_COHERENT_CACHE
+	bool
+	depends on 4xx || 8xx || E200
+	default y
+
+endmenu
Index: linux-cg/arch/powerpc/Kconfig
===================================================================
--- linux-cg.orig/arch/powerpc/Kconfig
+++ linux-cg/arch/powerpc/Kconfig
@@ -4,12 +4,7 @@
 
 mainmenu "Linux/PowerPC Kernel Configuration"
 
-config PPC64
-	bool "64-bit kernel"
-	default n
-	help
-	  This option selects whether a 32-bit or a 64-bit kernel
-	  will be built.
+source "arch/powerpc/Kconfig.cputype"
 
 config PPC32
 	bool
@@ -118,258 +113,6 @@ config DEFAULT_UIMAGE
 	  Used to allow a board to specify it wants a uImage built by default
 	default n
 
-menu "Processor support"
-choice
-	prompt "Processor Type"
-	depends on PPC32
-	default 6xx
-
-config CLASSIC32
-	bool "52xx/6xx/7xx/74xx"
-	select PPC_FPU
-	select 6xx
-	help
-	  There are four families of PowerPC chips supported.  The more common
-	  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
-	  versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
-	  embedded versions (403 and 405) and the high end 64 bit Power
-	  processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
-
-	  This option is the catch-all for 6xx types, including some of the
-	  embedded versions.  Unless there is see an option for the specific
-	  chip family you are using, you want this option.
-	  
-	  You do not want this if you are building a kernel for a 64 bit
-	  IBM RS/6000 or an Apple G5, choose 6xx.
-	  
-	  If unsure, select this option
-	  
-	  Note that the kernel runs in 32-bit mode even on 64-bit chips.
-
-config PPC_82xx
-	bool "Freescale 82xx"
-	select 6xx
-	select PPC_FPU
-
-config PPC_83xx
-	bool "Freescale 83xx"
-	select 6xx
-	select FSL_SOC
-	select 83xx
-	select PPC_FPU
-
-config PPC_85xx
-	bool "Freescale 85xx"
-	select E500
-	select FSL_SOC
-	select 85xx
-
-config PPC_86xx
-	bool "Freescale 86xx"
-	select 6xx
-	select FSL_SOC
-	select PPC_FPU
-	select ALTIVEC
-	help
-	  The Freescale E600 SoCs have 74xx cores.
-
-config PPC_8xx
-	bool "Freescale 8xx"
-	select FSL_SOC
-	select 8xx
-
-config 40x
-	bool "AMCC 40x"
-	select PPC_DCR_NATIVE
-
-config 44x
-	bool "AMCC 44x"
-	select PPC_DCR_NATIVE
-
-
-config E200
-	bool "Freescale e200"
-
-endchoice
-
-config POWER4_ONLY
-	bool "Optimize for POWER4"
-	depends on PPC64
-	default n
-	---help---
-	  Cause the compiler to optimize for POWER4/POWER5/PPC970 processors.
-	  The resulting binary will not work on POWER3 or RS64 processors
-	  when compiled with binutils 2.15 or later.
-
-config POWER3
-	bool
-	depends on PPC64
-	default y if !POWER4_ONLY
-
-config POWER4
-	depends on PPC64
-	def_bool y
-
-config 6xx
-	bool
-
-# this is temp to handle compat with arch=ppc
-config 8xx
-	bool
-
-# this is temp to handle compat with arch=ppc
-config 83xx
-	bool
-
-# this is temp to handle compat with arch=ppc
-config 85xx
-	bool
-
-config E500
-	bool
-
-config PPC_FPU
-	bool
-	default y if PPC64
-
-config PPC_DCR_NATIVE
-	bool
-	default n
-
-config PPC_DCR_MMIO
-	bool
-	default n
-
-config PPC_DCR
-	bool
-	depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
-	default y
-
-config PPC_OF_PLATFORM_PCI
-	bool
-	depends on PPC64 # not supported on 32 bits yet
-	default n
-
-config BOOKE
-	bool
-	depends on E200 || E500
-	default y
-
-config FSL_BOOKE
-	bool
-	depends on E200 || E500
-	default y
-
-config PTE_64BIT
-	bool
-	depends on 44x || E500
-	default y if 44x
-	default y if E500 && PHYS_64BIT
-
-config PHYS_64BIT
-	bool 'Large physical address support' if E500
-	depends on 44x || E500
-	select RESOURCES_64BIT
-	default y if 44x
-	---help---
-	  This option enables kernel support for larger than 32-bit physical
-	  addresses.  This features is not be available on all e500 cores.
-
-	  If in doubt, say N here.
-
-config ALTIVEC
-	bool "AltiVec Support"
-	depends on CLASSIC32 || POWER4
-	---help---
-	  This option enables kernel support for the Altivec extensions to the
-	  PowerPC processor. The kernel currently supports saving and restoring
-	  altivec registers, and turning on the 'altivec enable' bit so user
-	  processes can execute altivec instructions.
-
-	  This option is only usefully if you have a processor that supports
-	  altivec (G4, otherwise known as 74xx series), but does not have
-	  any affect on a non-altivec cpu (it does, however add code to the
-	  kernel).
-
-	  If in doubt, say Y here.
-
-config SPE
-	bool "SPE Support"
-	depends on E200 || E500
-	default y
-	---help---
-	  This option enables kernel support for the Signal Processing
-	  Extensions (SPE) to the PowerPC processor. The kernel currently
-	  supports saving and restoring SPE registers, and turning on the
-	  'spe enable' bit so user processes can execute SPE instructions.
-
-	  This option is only useful if you have a processor that supports
-	  SPE (e500, otherwise known as 85xx series), but does not have any
-	  effect on a non-spe cpu (it does, however add code to the kernel).
-
-	  If in doubt, say Y here.
-
-config PPC_STD_MMU
-	bool
-	depends on 6xx || POWER3 || POWER4 || PPC64
-	default y
-
-config PPC_STD_MMU_32
-	def_bool y
-	depends on PPC_STD_MMU && PPC32
-
-config PPC_MM_SLICES
-	bool
-	default y if HUGETLB_PAGE
-	default n
-
-config VIRT_CPU_ACCOUNTING
-	bool "Deterministic task and CPU time accounting"
-	depends on PPC64
-	default y
-	help
-	  Select this option to enable more accurate task and CPU time
-	  accounting.  This is done by reading a CPU counter on each
-	  kernel entry and exit and on transitions within the kernel
-	  between system, softirq and hardirq state, so there is a
-	  small performance impact.  This also enables accounting of
-	  stolen time on logically-partitioned systems running on
-	  IBM POWER5-based machines.
-
-	  If in doubt, say Y here.
-
-config SMP
-	depends on PPC_STD_MMU
-	bool "Symmetric multi-processing support"
-	---help---
-	  This enables support for systems with more than one CPU. If you have
-	  a system with only one CPU, say N. If you have a system with more
-	  than one CPU, say Y.  Note that the kernel does not currently
-	  support SMP machines with 603/603e/603ev or PPC750 ("G3") processors
-	  since they have inadequate hardware support for multiprocessor
-	  operation.
-
-	  If you say N here, the kernel will run on single and multiprocessor
-	  machines, but will use only one CPU of a multiprocessor machine. If
-	  you say Y here, the kernel will run on single-processor machines.
-	  On a single-processor machine, the kernel will run faster if you say
-	  N here.
-
-	  If you don't know what to do here, say N.
-
-config NR_CPUS
-	int "Maximum number of CPUs (2-128)"
-	range 2 128
-	depends on SMP
-	default "32" if PPC64
-	default "4"
-
-config NOT_COHERENT_CACHE
-	bool
-	depends on 4xx || 8xx || E200
-	default y
-endmenu
-
 source "init/Kconfig"
 
 menu "Platform support"

Re: [RFC, PATCH] selection of CPU optimization

[Kumar Gala]

On Apr 12, 2007, at 8:01 AM, Arnd Bergmann wrote:

> On Tuesday 10 April 2007, Benjamin Herrenschmidt wrote:
>> On Tue, 2007-04-10 at 20:15 +0900, Akinobu Mita wrote:
>>> An Alignment interrupt occurs when the instruction is lmw, stmw,  
>>> lswi, lswx,
>>> stswi, or stswx, and the operand is in local store.
>>>
>>> GCC generated such instructions to handle memcpy() instead of kernel
>>> defined memcpy() without -mno-string option.
>>>
>>> Signed-off-by: Akinobu Mita <mita@fixstars.com>
>>
>> I would personally prefer building the entire kernel with -mno-string
>> when cell support is enabled...
>
> The -mno-string flag should be set when _optimizing_ for cell,  
> which it
> probably is, but not when enabling a platform that runs on cell.
>
> I recently experimented with cleaning up the CPU type selection in  
> powerpc
> in general, by splitting the selection into four groups:
>
> 1. CPU architecture (64 bit powerpc, 32 bit common, FSL book E,  
> 4xx, ...)
>   this is roughly what we have already and limits the other options
> 2. Minimum CPU level (power3, power4, 970, cell, ....)
>   this selects the instruction set with -mcpu=xxx, but assumes that  
> some
>   CPUs use are a superset of others.
> 3. Optimization for a CPU (same list as above)
>   compatible in both ways, but can optimize only for CPUs that were  
> not
>   excluded in step 2.
> 4. platform selection (mac, pseries, prep, 83xx, 86xx, ...)
>   unchanged from now, but depends on 1. and 2. Depending on 1, you may
>   choose multiple platforms simultaneously, or just one.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Index: linux-cg/arch/powerpc/Kconfig.cputype
> ===================================================================
> --- /dev/null
> +++ linux-cg/arch/powerpc/Kconfig.cputype
> @@ -0,0 +1,610 @@
> +menu "Processor support"
> +choice
> +	prompt "Processor Type"
> +	default 6xx
> +	help
> +	  There are four families of PowerPC chips supported.  The more  
> common
> +	  types (601, 603, 604, 740, 750, 7400), the Motorola embedded
> +	  versions (821, 823, 850, 855, 860, 52xx, 82xx, 83xx), the AMCC
> +	  embedded versions (403 and 405) and the high end 64 bit Power
> +	  processors (POWER 3, POWER4, and IBM PPC970 also known as G5).
> +
> +config PPC64
> +	bool "Any 64 bit processor"
> +	help
> +	  This option is the catch-all for all 64 bit processors, including
> +	  the IBM Power3/4/5/6, PowerPC 970 (G5), Cell Broadband Engine,
> +	  and the PA Semi PA6T.
> +
> +config PPC_6xx
> +	bool "52xx/6xx/7xx/74xx/82xx/83xx/86xx"
> +	select PPC_FPU
> +	select 6xx
> +	help
> +	  This option is the catch-all for 6xx types, including some of the
> +	  embedded versions.  Unless there is see an option for the specific
> +	  chip family you are using, you want this option.
> +
> +	  If unsure, select this option.
> +
> +config PPC_85xx
> +	bool "Freescale 85xx"
> +	select E500
> +	select FSL_SOC
> +	select 85xx
> +
> +config PPC_8xx
> +	bool "Freescale 8xx"
> +	select FSL_SOC
> +	select 8xx
> +
> +config 40x
> +	bool "AMCC 40x"
> +	select PPC_DCR_NATIVE
> +
> +config 44x
> +	bool "AMCC 44x"
> +	select PPC_DCR_NATIVE
> +
> +config E200
> +	bool "Freescale e200"
> +
> +endchoice
> +
> +#choice
> +#	prompt "Type of 6xx package"
> +#	default CLASSIC32
> +#	depends on PPC_6xx
> +#
> +config CLASSIC32
> +	bool "Classic 52xx/6xx/7xx/74xx"
> +	select 6xx
> +	select PPC_FPU
> +
> +config PPC_82xx
> +	bool "Embedded Freescale 82xx"
> +	select 6xx
> +	select PPC_FPU
> +
> +config PPC_83xx
> +	bool "Embedded Freescale 83xx"
> +	select 6xx
> +	select FSL_SOC
> +	select 83xx
> +	select PPC_FPU
> +
> +config PPC_86xx
> +	bool "Embedded Freescale 86xx"
> +	select 6xx
> +	select FSL_SOC
> +	select PPC_FPU
> +	select ALTIVEC
> +	help
> +	  The Freescale E600 SoCs have 74xx cores.
> +# endchoice
> +
> +choice
> +	prompt "Processor level"
> +	default PPC_CPU_POWER3 if PPC64
> +
> +config PPC_CPU_UNSPECIFIED
> +	bool "Use compiler default"
> +
> +config PPC_CPU_ANY64
> +	bool "Generic 64 bit PowerPC"
> +	depends on PPC64
> +	select PPC_ENABLE_ANY64
> +
> +config PPC_CPU_RS64
> +	bool "RS64 (Northstar/Pulsar/Icestar/Sstar)"
> +	depends on PPC64
> +	select PPC_ENABLE_RS64
> +
> +config PPC_CPU_POWER3
> +	bool "Power3"
> +	depends on PPC64
> +	select PPC_ENABLE_POWER3
> +
> +config PPC_CPU_POWER4
> +	bool "Power4"
> +	depends on PPC64
> +	select PPC_ENABLE_POWER4
> +
> +config PPC_CPU_POWER5
> +	bool "Power5"
> +	depends on PPC64
> +	select PPC_ENABLE_POWER5
> +	select ALTIVEC
> +
> +config PPC_CPU_POWER5PLUS
> +	bool "Power5+"
> +	depends on PPC64
> +	select PPC_ENABLE_POWER5PLUS
> +	select ALTIVEC
> +
> +config PPC_CPU_POWER6
> +	bool "Power6"
> +	depends on PPC64
> +	select PPC_ENABLE_PA6T
> +	select PPC_ENABLE_POWER6
> +	select ALTIVEC
> +
> +config PPC_CPU_970
> +	bool "PowerPC 970 (G5)"
> +	depends on PPC64
> +	select PPC_ENABLE_970
> +	select ALTIVEC
> +
> +config PPC_CPU_CELLBE
> +	bool "Cell Broadband Engine"
> +	depends on PPC64
> +	select PPC_ENABLE_CELLBE
> +	select PPC_ENABLE_PA6T
> +	select PPC_ENABLE_POWER6
> +	select ALTIVEC
> +
> +config PPC_CPU_PA6T
> +	bool "PA Semi PA6T"
> +	depends on PPC64
> +	select PPC_ENABLE_PA6T
> +	select PPC_ENABLE_POWER6
> +	select ALTIVEC
> +
> +config PPC_CPU_ANY32
> +	bool "Generic 32 bit PowerPC"
> +	depends on PPC_6xx || PPC_8xx || 4xx || E200 || E500
> +	select PPC_ENABLE_ALTIVEC

What is PPC_ENABLE_ALTIVEC used for?

> +
> +config PPC_CPU_601
> +	bool "601 (G1)"
> +	depends on CLASSIC32
> +
> +config PPC_CPU_603
> +	bool "603/603e/82xx/83xx/e300 (G2)"
> +	depends on CLASSIC32 || PPC_82xx || PPC_83xx
> +
> +config PPC_CPU_604
> +	bool "604/604e/604r/604ev"
> +	depends on CLASSIC32
> +
> +config PPC_CPU_750
> +	bool "750/750CX/750CXe/750FX/750GX (G3)"
> +	depends on CLASSIC32
> +
> +config PPC_CPU_7400
> +	bool "7400/7410"
> +	depends on CLASSIC32
> +	select ALTIVEC
> +
> +config PPC_CPU_7450
> +	bool "7450/7447/7457/7448/7450/86xx (G4)"
> +	depends on CLASSIC32 || PPC_86xx
> +	select ALTIVEC
> +
> +config PPC_CPU_801
> +	bool "801"
> +	depends on PPC_8xx
> +
> +config PPC_CPU_821
> +	bool "821"
> +	depends on PPC_8xx
> +
> +config PPC_CPU_823
> +	bool "823"
> +	depends on PPC_8xx
> +
> +config PPC_CPU_860
> +	bool "860"
> +	depends on PPC_8xx
> +
> +config PPC_CPU_403
> +	bool "403"
> +	depends on 40x
> +
> +config PPC_CPU_405
> +	bool "405"
> +	depends on 40x
> +
> +config PPC_CPU_440
> +	bool "440"
> +	depends on 44x
> +
> +config PPC_CPU_E200
> +	bool "e200/5554"
> +	depends on E200
> +
> +config PPC_CPU_E500
> +	bool "e500/8540/8548"
> +	depends on E500
> +endchoice
> +
> +config PPC_ENABLE_ANY64
> +	bool
> +	select PPC_ENABLE_RS64
> +
> +config PPC_ENABLE_POWER3
> +	bool
> +	select PPC_ENABLE_POWER4
> +
> +config PPC_ENABLE_POWER4
> +	bool
> +	select PPC_ENABLE_POWER5
> +	select PPC_ENABLE_970
> +
> +config PPC_ENABLE_POWER5
> +	bool
> +	select PPC_ENABLE_POWER5PLUS
> +	select PPC_ENABLE_CELLBE
> +
> +config PPC_ENABLE_POWER5PLUS
> +	bool
> +	select PPC_ENABLE_POWER6
> +
> +config PPC_ENABLE_POWER6
> +	bool
> +	select PPC_ENABLE_ALTIVEC
> +
> +config PPC_ENABLE_RS64
> +	bool
> +	select PPC_ENABLE_POWER3
> +
> +config PPC_ENABLE_970
> +	bool
> +	select PPC_ENABLE_POWER5
> +
> +config PPC_ENABLE_CELLBE
> +	bool
> +
> +config PPC_ENABLE_PA6T
> +	bool
> +
> +choice
> +	prompt "Tune for processor"
> +
> +config PPC_TUNE_UNSPECIFIED
> +	bool "Use compiler default"
> +
> +config PPC_TUNE_ANY64
> +	bool "Generic 64 bit PowerPC"
> +	depends on PPC64
> +
> +config PPC_TUNE_RS64
> +	bool "RS64 (Northstar/Pulsar/Icestar/Sstar)"
> +	depends on PPC_ENABLE_RS64
> +
> +config PPC_TUNE_POWER3
> +	bool "Power3"
> +	depends on PPC_ENABLE_POWER3
> +
> +config PPC_TUNE_POWER4
> +	bool "Power4"
> +	depends on PPC_ENABLE_POWER4
> +
> +config PPC_TUNE_POWER5
> +	bool "Power5"
> +	depends on PPC_ENABLE_POWER5
> +
> +config PPC_TUNE_POWER5PLUS
> +	bool "Power5+"
> +	depends on PPC_ENABLE_POWER5PLUS
> +
> +config PPC_TUNE_POWER6
> +	bool "Power6"
> +	depends on PPC_ENABLE_POWER6
> +
> +config PPC_TUNE_970
> +	bool "PowerPC 970 (G5)"
> +	depends on PPC_ENABLE_970
> +
> +config PPC_TUNE_CELLBE
> +	bool "Cell Broadband Engine"
> +	depends on PPC_ENABLE_CELLBE
> +
> +config PPC_TUNE_PA6T
> +	bool "PA Semi PA6T"
> +	depends on PPC_ENABLE_PA6T
> +
> +config PPC_TUNE_ANY32
> +	bool "Generic 32 bit PowerPC"
> +	depends on PPC32
> +	select PPC_ENABLE_ALTIVEC
> +
> +config PPC_TUNE_601
> +	bool "601 (G1)"
> +	depends on CLASSIC32
> +
> +config PPC_TUNE_603
> +	bool "603/603e/82xx/83xx/e300 (G2)"
> +	depends on CLASSIC32 || PPC_82xx || PPC_83xx
> +
> +config PPC_TUNE_604
> +	bool "604/604e/604r/604ev"
> +	depends on CLASSIC32
> +
> +config PPC_TUNE_750
> +	bool "750/750CX/750CXe/750FX/750GX (G3)"
> +	depends on CLASSIC32
> +
> +config PPC_TUNE_7400
> +	bool "7400/7410"
> +	depends on CLASSIC32
> +
> +config PPC_TUNE_7450
> +	bool "7450/7447/7457/7448/7450/86xx (G4)"
> +	depends on CLASSIC32 || PPC_86xx
> +
> +config PPC_TUNE_801
> +	bool "801"
> +	depends on PPC_8xx
> +
> +config PPC_TUNE_821
> +	bool "821"
> +	depends on PPC_8xx
> +
> +config PPC_TUNE_823
> +	bool "823"
> +	depends on PPC_8xx
> +
> +config PPC_TUNE_860
> +	bool "860"
> +	depends on PPC_8xx
> +
> +config PPC_TUNE_403
> +	bool "403"
> +	depends on 40x
> +
> +config PPC_TUNE_405
> +	bool "405"
> +	depends on 40x
> +
> +config PPC_TUNE_440
> +	bool "440"
> +	depends on 44x
> +
> +config PPC_TUNE_E200
> +	bool "e200/5554"
> +	depends on E200
> +
> +config PPC_TUNE_E500
> +	bool "e500/8540/8548"
> +	depends on E500
> +
> +endchoice
> +
> +config PPC_ENABLE_ALTIVEC
> +	bool
> +
> +config PPC_CPU_FLAG
> +	string
> +	default "" if PPC_CPU_UNSPECIFIED
> +	default "-mcpu=powerpc64" if PPC_CPU_ANY64
> +	default "-mcpu=rs64" if PPC_CPU_RS64
> +	default "-mcpu=power3" if PPC_CPU_POWER3
> +	default "-mcpu=power4" if PPC_CPU_POWER4
> +	default "-mcpu=power5" if PPC_CPU_POWER5
> +	default "-mcpu=power5+" if PPC_CPU_POWER5PLUS
> +	default "-mcpu=power6" if PPC_CPU_POWER6
> +	default "-mcpu=970" if PPC_CPU_970
> +	default "" if PPC_CPU_CELLBE
> +	default "" if PPC_CPU_PA6T
> +	default "-mcpu=powerpc" if PPC_CPU_ANY32
> +	default "-mcpu=601" if PPC_CPU_601
> +	default "-mcpu=603" if PPC_CPU_603
> +	default "-mcpu=604" if PPC_CPU_604
> +	default "-mcpu=750" if PPC_CPU_750
> +	default "-mcpu=7400" if PPC_CPU_7400
> +	default "-mcpu=7450" if PPC_CPU_7450
> +	default "-mcpu=801" if PPC_CPU_801
> +	default "-mcpu=821" if PPC_CPU_821
> +	default "-mcpu=823" if PPC_CPU_823
> +	default "-mcpu=860" if PPC_CPU_860
> +	default "-mcpu=403" if PPC_CPU_403
> +	default "-mcpu=405" if PPC_CPU_405
> +	default "-mcpu=440" if PPC_CPU_440
> +	default "" if PPC_CPU_E200
> +	default "" if PPC_CPU_E500

I think -mcpu=8540 will work for e500 (same for tune)

> +
> +config PPC_TUNE_FLAG
> +	string
> +	default "" if PPC_TUNE_UNSPECIFIED
> +	default "-mtune=powerpc64" if PPC_TUNE_ANY64
> +	default "-mtune=rs64" if PPC_TUNE_RS64
> +	default "-mtune=power3" if PPC_TUNE_POWER3
> +	default "-mtune=power4" if PPC_TUNE_POWER4
> +	default "-mtune=power5" if PPC_TUNE_POWER5
> +	default "-mtune=power5+" if PPC_TUNE_POWER5PLUS
> +	default "-mtune=power6" if PPC_TUNE_POWER6
> +	default "-mtune=970" if PPC_TUNE_970
> +	default "" if PPC_TUNE_CELLBE
> +	default "" if PPC_TUNE_PA6T
> +	default "-mtune=powerpc" if PPC_TUNE_ANY32
> +	default "-mtune=601" if PPC_TUNE_601
> +	default "-mtune=603" if PPC_TUNE_603
> +	default "-mtune=604" if PPC_TUNE_604
> +	default "-mtune=750" if PPC_TUNE_750
> +	default "-mtune=7400" if PPC_TUNE_7400
> +	default "-mtune=7450" if PPC_TUNE_7450
> +	default "-mtune=801" if PPC_TUNE_801
> +	default "-mtune=821" if PPC_TUNE_821
> +	default "-mtune=823" if PPC_TUNE_823
> +	default "-mtune=860" if PPC_TUNE_860
> +	default "-mtune=403" if PPC_TUNE_403
> +	default "-mtune=405" if PPC_TUNE_405
> +	default "-mtune=440" if PPC_TUNE_440
> +	default "" if PPC_TUNE_E200
> +	default "" if PPC_TUNE_E500
> +
> +# these are temp to transition to new cpu selection
> +config POWER3
> +	bool
> +	depends on PPC_ENABLE_POWER3 || PPC_ENABLE_RS64
> +	default y
> +
> +config POWER4
> +	depends on PPC64
> +	def_bool y
> +
> +config POWER4_ONLY
> +	bool
> +	default y if !PPC_POWER3
> +
> +config 6xx
> +	bool
> +
> +# this is temp to handle compat with arch=ppc
> +config 8xx
> +	bool
> +
> +# this is temp to handle compat with arch=ppc
> +config 83xx
> +	bool
> +
> +# this is temp to handle compat with arch=ppc
> +config 85xx
> +	bool
> +
> +config E500
> +	bool
> +
> +config PPC_FPU
> +	bool
> +	default y if PPC64
> +
> +config PPC_DCR_NATIVE
> +	bool
> +	default n
> +
> +config PPC_DCR_MMIO
> +	bool
> +	default n
> +
> +config PPC_DCR
> +	bool
> +	depends on PPC_DCR_NATIVE || PPC_DCR_MMIO
> +	default y
> +
> +config PPC_OF_PLATFORM_PCI
> +	bool
> +	depends on PPC64 # not supported on 32 bits yet
> +	default n

Should this really be in here? I don't see how OF PCI has anything to  
do with CPU/core.

> +
> +config BOOKE
> +	bool
> +	depends on E200 || E500
> +	default y
> +
> +config FSL_BOOKE
> +	bool
> +	depends on E200 || E500
> +	default y
> +
> +config PTE_64BIT
> +	bool
> +	depends on 44x || E500
> +	default y if 44x
> +	default y if E500 && PHYS_64BIT
> +
> +config PHYS_64BIT
> +	bool 'Large physical address support' if E500
> +	depends on 44x || E500
> +	select RESOURCES_64BIT
> +	default y if 44x
> +	---help---
> +	  This option enables kernel support for larger than 32-bit physical
> +	  addresses.  This features is not be available on all e500 cores.
> +
> +	  If in doubt, say N here.
> +
> +config ALTIVEC
> +	bool "AltiVec Support"
> +	depends on PPC64 || PPC_CPU_ANY32 || CLASSIC32
> +	---help---
> +	  This option enables kernel support for the Altivec extensions  
> to the
> +	  PowerPC processor. The kernel currently supports saving and  
> restoring
> +	  altivec registers, and turning on the 'altivec enable' bit so user
> +	  processes can execute altivec instructions.
> +
> +	  This option is only usefully if you have a processor that supports
> +	  altivec (G4, otherwise known as 74xx series), but does not have
> +	  any affect on a non-altivec cpu (it does, however add code to the
> +	  kernel).
> +
> +	  If in doubt, say Y here.
> +
> +config SPE
> +	bool "SPE Support"
> +	depends on E200 || E500
> +	default y
> +	---help---
> +	  This option enables kernel support for the Signal Processing
> +	  Extensions (SPE) to the PowerPC processor. The kernel currently
> +	  supports saving and restoring SPE registers, and turning on the
> +	  'spe enable' bit so user processes can execute SPE instructions.
> +
> +	  This option is only useful if you have a processor that supports
> +	  SPE (e500, otherwise known as 85xx series), but does not have any
> +	  effect on a non-spe cpu (it does, however add code to the kernel).
> +
> +	  If in doubt, say Y here.
> +
> +config PPC_STD_MMU
> +	bool
> +	depends on 6xx || POWER3 || POWER4 || PPC64
> +	default y
> +
> +config PPC_STD_MMU_32
> +	def_bool y
> +	depends on PPC_STD_MMU && PPC32
> +
> +config PPC_MM_SLICES
> +	bool
> +	default y if HUGETLB_PAGE
> +	default n
> +
> +config VIRT_CPU_ACCOUNTING
> +	bool "Deterministic task and CPU time accounting"
> +	depends on PPC64
> +	default y
> +	help
> +	  Select this option to enable more accurate task and CPU time
> +	  accounting.  This is done by reading a CPU counter on each
> +	  kernel entry and exit and on transitions within the kernel
> +	  between system, softirq and hardirq state, so there is a
> +	  small performance impact.  This also enables accounting of
> +	  stolen time on logically-partitioned systems running on
> +	  IBM POWER5-based machines.
> +
> +	  If in doubt, say Y here.
> +
> +config SMP
> +	depends on PPC_STD_MMU
> +	bool "Symmetric multi-processing support"
> +	---help---
> +	  This enables support for systems with more than one CPU. If you  
> have
> +	  a system with only one CPU, say N. If you have a system with more
> +	  than one CPU, say Y.  Note that the kernel does not currently
> +	  support SMP machines with 603/603e/603ev or PPC750 ("G3")  
> processors
> +	  since they have inadequate hardware support for multiprocessor
> +	  operation.
> +
> +	  If you say N here, the kernel will run on single and  
> multiprocessor
> +	  machines, but will use only one CPU of a multiprocessor  
> machine. If
> +	  you say Y here, the kernel will run on single-processor machines.
> +	  On a single-processor machine, the kernel will run faster if  
> you say
> +	  N here.
> +
> +	  If you don't know what to do here, say N.
> +
> +config NR_CPUS
> +	int "Maximum number of CPUs (2-128)"
> +	range 2 128
> +	depends on SMP
> +	default "32" if PPC64
> +	default "4"
> +
> +config NOT_COHERENT_CACHE
> +	bool
> +	depends on 4xx || 8xx || E200
> +	default y
> +
> +endmenu

[snip]

  - k

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Arnd Bergmann]

On Thursday 12 April 2007, Kumar Gala wrote:

> > +config PPC_CPU_ANY32
> > +	bool "Generic 32 bit PowerPC"
> > +	depends on PPC_6xx || PPC_8xx || 4xx || E200 || E500
> > +	select PPC_ENABLE_ALTIVEC
> 
> What is PPC_ENABLE_ALTIVEC used for?

The idea was that PPC_ENABLE_ALTIVEC is selected when PPC_ALTIVEC
_can_ be enabled, while PPC_ALTIVEC is selected by some CPUs
directly.

I now remember that I had not done this part right in the patch
I posted. The correct behavior should be something like

choice
	prompt "Processor level"

config PPC_CPU_740
	bool "G3 or higher"
	select PPC_ENABLE_ALTIVEC
	# altivec is possible

config PPC_CPU_86xx
	bool "86xx"
	select PPC_ALTIVEC
	# altivec is required

config PPC_CPU_4xx
	bool "4xx"
	# altivec is not possible

endchoice

config PPC_ENABLE_ALTIVEC
	bool

config PPC_ALTIVEC
	bool "Enable the use of Altivec"
	depends on PPC_ENABLE_ALTIVEC

I'll fix this up in the next version, which should also
be split into simpler patches.

> > +config PPC_CPU_FLAG
> > +	string
> > +	default "" if PPC_CPU_UNSPECIFIED
> > +	default "-mcpu=powerpc64" if PPC_CPU_ANY64
> > +	default "-mcpu=rs64" if PPC_CPU_RS64
> > +	default "-mcpu=power3" if PPC_CPU_POWER3
> > +	default "-mcpu=power4" if PPC_CPU_POWER4
> > +	default "-mcpu=power5" if PPC_CPU_POWER5
> > +	default "-mcpu=power5+" if PPC_CPU_POWER5PLUS
> > +	default "-mcpu=power6" if PPC_CPU_POWER6
> > +	default "-mcpu=970" if PPC_CPU_970
> > +	default "" if PPC_CPU_CELLBE
> > +	default "" if PPC_CPU_PA6T
> > +	default "-mcpu=powerpc" if PPC_CPU_ANY32
> > +	default "-mcpu=601" if PPC_CPU_601
> > +	default "-mcpu=603" if PPC_CPU_603
> > +	default "-mcpu=604" if PPC_CPU_604
> > +	default "-mcpu=750" if PPC_CPU_750
> > +	default "-mcpu=7400" if PPC_CPU_7400
> > +	default "-mcpu=7450" if PPC_CPU_7450
> > +	default "-mcpu=801" if PPC_CPU_801
> > +	default "-mcpu=821" if PPC_CPU_821
> > +	default "-mcpu=823" if PPC_CPU_823
> > +	default "-mcpu=860" if PPC_CPU_860
> > +	default "-mcpu=403" if PPC_CPU_403
> > +	default "-mcpu=405" if PPC_CPU_405
> > +	default "-mcpu=440" if PPC_CPU_440
> > +	default "" if PPC_CPU_E200
> > +	default "" if PPC_CPU_E500
> 
> I think -mcpu=8540 will work for e500 (same for tune)

Interestingly, -mcpu=8540 is known to gcc, according to
gcc-4.0.3 -dumpspecs, but is not listed in the documentation.
There is also -me500, while -me200 seems to be known only
to gas but not gcc.

What would be the right options to pass on e200 and on
pa6t?

> > +config PPC_OF_PLATFORM_PCI
> > +	bool
> > +	depends on PPC64 # not supported on 32 bits yet
> > +	default n
> 
> Should this really be in here? I don't see how OF PCI has anything to  
> do with CPU/core.

Right.

	Arnd <><

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Kumar Gala]

On Apr 12, 2007, at 12:26 PM, Arnd Bergmann wrote:

> On Thursday 12 April 2007, Kumar Gala wrote:
>
>>> +config PPC_CPU_ANY32
>>> +	bool "Generic 32 bit PowerPC"
>>> +	depends on PPC_6xx || PPC_8xx || 4xx || E200 || E500
>>> +	select PPC_ENABLE_ALTIVEC
>>
>> What is PPC_ENABLE_ALTIVEC used for?
>
> The idea was that PPC_ENABLE_ALTIVEC is selected when PPC_ALTIVEC
> _can_ be enabled, while PPC_ALTIVEC is selected by some CPUs
> directly.

Ok, seems like 8xx/4xx/e200/e500 its clear will NEVER have Altivec.   
I think we should put the PPC_ENABLE_ALTIVEC on PPC_6xx which should  
cover all the reasonable possible cases (603, 604, 7xx).

> I now remember that I had not done this part right in the patch
> I posted. The correct behavior should be something like
>
> choice
> 	prompt "Processor level"
>
> config PPC_CPU_740
> 	bool "G3 or higher"
> 	select PPC_ENABLE_ALTIVEC
> 	# altivec is possible
>
> config PPC_CPU_86xx
> 	bool "86xx"
> 	select PPC_ALTIVEC
> 	# altivec is required
>
> config PPC_CPU_4xx
> 	bool "4xx"
> 	# altivec is not possible
>
> endchoice
>
> config PPC_ENABLE_ALTIVEC
> 	bool
>
> config PPC_ALTIVEC
> 	bool "Enable the use of Altivec"
> 	depends on PPC_ENABLE_ALTIVEC
>
> I'll fix this up in the next version, which should also
> be split into simpler patches.
>
>>> +config PPC_CPU_FLAG
>>> +	string
>>> +	default "" if PPC_CPU_UNSPECIFIED
>>> +	default "-mcpu=powerpc64" if PPC_CPU_ANY64
>>> +	default "-mcpu=rs64" if PPC_CPU_RS64
>>> +	default "-mcpu=power3" if PPC_CPU_POWER3
>>> +	default "-mcpu=power4" if PPC_CPU_POWER4
>>> +	default "-mcpu=power5" if PPC_CPU_POWER5
>>> +	default "-mcpu=power5+" if PPC_CPU_POWER5PLUS
>>> +	default "-mcpu=power6" if PPC_CPU_POWER6
>>> +	default "-mcpu=970" if PPC_CPU_970
>>> +	default "" if PPC_CPU_CELLBE
>>> +	default "" if PPC_CPU_PA6T
>>> +	default "-mcpu=powerpc" if PPC_CPU_ANY32
>>> +	default "-mcpu=601" if PPC_CPU_601
>>> +	default "-mcpu=603" if PPC_CPU_603
>>> +	default "-mcpu=604" if PPC_CPU_604
>>> +	default "-mcpu=750" if PPC_CPU_750
>>> +	default "-mcpu=7400" if PPC_CPU_7400
>>> +	default "-mcpu=7450" if PPC_CPU_7450
>>> +	default "-mcpu=801" if PPC_CPU_801
>>> +	default "-mcpu=821" if PPC_CPU_821
>>> +	default "-mcpu=823" if PPC_CPU_823
>>> +	default "-mcpu=860" if PPC_CPU_860
>>> +	default "-mcpu=403" if PPC_CPU_403
>>> +	default "-mcpu=405" if PPC_CPU_405
>>> +	default "-mcpu=440" if PPC_CPU_440
>>> +	default "" if PPC_CPU_E200
>>> +	default "" if PPC_CPU_E500
>>
>> I think -mcpu=8540 will work for e500 (same for tune)
>
> Interestingly, -mcpu=8540 is known to gcc, according to
> gcc-4.0.3 -dumpspecs, but is not listed in the documentation.
> There is also -me500, while -me200 seems to be known only
> to gas but not gcc.
>
> What would be the right options to pass on e200 and on
> pa6t?

I think leaving it blank is the right thing for e200.

Olof should know what pa6t needs or what makes sense for it.

>>> +config PPC_OF_PLATFORM_PCI
>>> +	bool
>>> +	depends on PPC64 # not supported on 32 bits yet
>>> +	default n
>>
>> Should this really be in here? I don't see how OF PCI has anything to
>> do with CPU/core.
>
> Right.
>
> 	Arnd <><

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Arnd Bergmann]

On Thursday 12 April 2007, Kumar Gala wrote:
> > What would be the right options to pass on e200 and on
> > pa6t?
> 
> I think leaving it blank is the right thing for e200.

Leaving it blank means it will use the compiler's default
target, which can be anything. My guess is that '-mcpu=powerpc'
would be right, i.e. no 64 bit, no POWER, but most PowerPC
instructions are allowed.

	Arnd <><

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Olof Johansson]

On Thu, Apr 12, 2007 at 01:17:25PM -0500, Kumar Gala wrote:
> On Apr 12, 2007, at 12:26 PM, Arnd Bergmann wrote:
> >Interestingly, -mcpu=8540 is known to gcc, according to
> >gcc-4.0.3 -dumpspecs, but is not listed in the documentation.
> >There is also -me500, while -me200 seems to be known only
> >to gas but not gcc.
> >
> >What would be the right options to pass on e200 and on
> >pa6t?
> 
> I think leaving it blank is the right thing for e200.
> 
> Olof should know what pa6t needs or what makes sense for it.

Thanks for the heads up, I didn't notice the email go by on the list.

-m{cpu,tune}=pa6t should do it.


-Olof

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Segher Boessenkool]

>> Olof should know what pa6t needs or what makes sense for it.
>
> Thanks for the heads up, I didn't notice the email go by on the list.
>
> -m{cpu,tune}=pa6t should do it.

Except that's not in any public GCC version yet.  Well,
two weeks ago it wasn't...

Note that specifying an unknown -mcpu/tune= is an error,
not a warning or totally ignored.


Segher

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Olof Johansson]

On Thu, Apr 12, 2007 at 10:01:11PM +0200, Segher Boessenkool wrote:
> >>Olof should know what pa6t needs or what makes sense for it.
> >
> >Thanks for the heads up, I didn't notice the email go by on the list.
> >
> >-m{cpu,tune}=pa6t should do it.
> 
> Except that's not in any public GCC version yet.  Well,
> two weeks ago it wasn't...
> 
> Note that specifying an unknown -mcpu/tune= is an error,
> not a warning or totally ignored.

Correct, it's not upstream yet. It will be at some point, and in general
people who have access to hardware also have access to a toolchain that
has it.

So, leave it open, or use 970 settings for now to keep Segher happy.


-Olof

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Segher Boessenkool]

>> Except that's not in any public GCC version yet.  Well,
>> two weeks ago it wasn't...
>>
>> Note that specifying an unknown -mcpu/tune= is an error,
>> not a warning or totally ignored.
>
> Correct, it's not upstream yet. It will be at some point, and in 
> general
> people who have access to hardware also have access to a toolchain that
> has it.
>
> So, leave it open, or use 970 settings for now to keep Segher happy.

-mcpu=970 would be wrong (although it should work in this
specific case).  -mcpu=powerpc64 is better.  -mtune=970
wouldn't make any sense.

It's not about "keeping me happy", it's about doing the
Right Thing(tm).  Don't fight the toolchain, work with it.


Segher

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Segher Boessenkool]

>> I think -mcpu=8540 will work for e500 (same for tune)
>
> Interestingly, -mcpu=8540 is known to gcc, according to
> gcc-4.0.3 -dumpspecs, but is not listed in the documentation.

Sure it is: gcc/gcc/config/rs6000/rs6000.c, line #s about
1250 and further ;-)

It's supposed to be in the info manual too, if not, please
file a PR; looks good to me though.

> There is also -me500, while -me200 seems to be known only
> to gas but not gcc.

There is no -mcpu=e500.  -me500 is a GAS option.
GCC's -mcpu= options generally take specific CPU names
as parameter; I suppose it would make sense to add e200
et. al.

> What would be the right options to pass on e200 and on
> pa6t?

The best thing would be to add GCC -mcpu= options.  For
now, you're probably best of with -mcpu=powerpc and
-mcpu=powerpc64 resp., i.e. the "blended models".  This
is a good option for multiplatform kernels too; add -mtune=
to optimise for a specific core, but it will *work* on
the whole family.


Segher

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Arnd Bergmann]

On Thursday 12 April 2007, Segher Boessenkool wrote:
> > What would be the right options to pass on e200 and on
> > pa6t?
>=20
> The best thing would be to add GCC -mcpu=3D options. =A0For
> now, you're probably best of with -mcpu=3Dpowerpc and
> -mcpu=3Dpowerpc64 resp., i.e. the "blended models". =A0This
> is a good option for multiplatform kernels too; add -mtune=3D
> to optimise for a specific core, but it will *work* on
> the whole family.

We already have makefile magic to test if gcc supports a flag
and fall back to some other one if not.

After looking at rs6000.c, I found that we can probably
reduce the number of different -mcpu=3D options to 16 and only
have separate -mtune=3D options for each specific cpu.

My understanding at this point is that we can always fall back
to -mcpu=3Dpowerpc or -mcpu=3Dpowerpc64, and also

(401, 505, power, power2, rsc) -> not supported

403 -> -mcpu=3D403
(405, 440) -> -mcpu=3D405
(e500, 85xx) -> -mcpu=3D8540
601 -> -mcpu=3D601
(6xx, g3, g4, e300, e600) -> -mcpu=3D603
(ec603e, e200, 82xx) -> -mcpu=3Dec603e
(8xx) -> -mcpu=3D860

(power3, rs64) -> -mcpu=3Dpower3
power4 -> -mcpu=3Dpower4 >> -mcpu=3Dpower3
970 -> -mcpu=3D970 >> -mcpu=3Dpower4
cell -> -mcpu=3Dcell >> -mcpu=3D970
power5 -> -mcpu=3Dpower5 >> -mcpu=3Dpower4
power5+ -> -mcpu=3Dpower5+ >> -mcpu=3Dpower5
power6 -> -mcpu=3Dpower6 >> -mcpu=3Dpower5+
power6x -> -mcpu=3Dpower6x >> -mcpu=3Dpower6
pa6t -> -mcpu=3Dpa6t >> (???)

So if we select e.g. power6 and cell, it needs to fall back to power4,
which is the common subset. Selecting both 403 and 405 would result
in falling back to -mcpu=3Dpowerpc, because they don't have any larger
subset.

I'm not sure what the right fallback fo pa6t should be. I would guess
that it's a superset of power6x and 970 when considering the kernel,
but it's not entirely clear what the fallback should be.

	Arnd <><

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Olof Johansson]

On Fri, Apr 13, 2007 at 02:10:47AM +0200, Arnd Bergmann wrote:
> On Thursday 12 April 2007, Segher Boessenkool wrote:
> > > What would be the right options to pass on e200 and on
> > > pa6t?
> > 
> > The best thing would be to add GCC -mcpu= options. ?For
> > now, you're probably best of with -mcpu=powerpc and
> > -mcpu=powerpc64 resp., i.e. the "blended models". ?This
> > is a good option for multiplatform kernels too; add -mtune=
> > to optimise for a specific core, but it will *work* on
> > the whole family.
> 
> 970 -> -mcpu=970 >> -mcpu=power4
> cell -> -mcpu=cell >> -mcpu=970
> power5 -> -mcpu=power5 >> -mcpu=power4
> power5+ -> -mcpu=power5+ >> -mcpu=power5
> power6 -> -mcpu=power6 >> -mcpu=power5+
> power6x -> -mcpu=power6x >> -mcpu=power6
> pa6t -> -mcpu=pa6t >> (???)
> 
> So if we select e.g. power6 and cell, it needs to fall back to power4,
> which is the common subset. Selecting both 403 and 405 would result
> in falling back to -mcpu=powerpc, because they don't have any larger
> subset.
> 
> I'm not sure what the right fallback fo pa6t should be. I would guess
> that it's a superset of power6x and 970 when considering the kernel,
> but it's not entirely clear what the fallback should be.

On the kernel side, power6 should be closest. We likely lack some of the
optional features they implemented, but none are used in the kernel.

If we find problems down the road, we'll revise.


-Olof

Re: [Cbe-oss-dev] [RFC, PATCH] selection of CPU optimization

[Segher Boessenkool]

> My understanding at this point is that we can always fall back
> to -mcpu=powerpc or -mcpu=powerpc64,

Yes.  With perhaps and added -mno-string or similar if
some supported CPU really needs it.


>  and also

[SNIP]

> So if we select e.g. power6 and cell, it needs to fall back to power4,
> which is the common subset. Selecting both 403 and 405 would result
> in falling back to -mcpu=powerpc, because they don't have any larger
> subset.

This is way complicated.  Also, it is not unique to the
kernel; you'd be better off adding this logic to the
compiler itself.  OTOH, it's such a niche market, maybe
the distros that want it (if any do) should do this in
their RPM build scripts or similar.


Segher