[PATCH 5/6] PowerPC 440EPx: Sequoia board support

AMCC 440EPx Sequoia board support.

Signed-off-by: Valentine Barshak <redacted>
---
 arch/powerpc/kernel/cputable.c       |   36 +++++++++++++++++++
 arch/powerpc/kernel/head_44x.S       |    2 -
 arch/powerpc/platforms/44x/Kconfig   |   17 ++++++++-
 arch/powerpc/platforms/44x/Makefile  |    1 
 arch/powerpc/platforms/44x/sequoia.c |   66 +++++++++++++++++++++++++++++++++++
 5 files changed, 120 insertions(+), 2 deletions(-)

diff -ruN linux.orig/arch/powerpc/kernel/cputable.c linux/arch/powerpc/kernel/cputable.c

--- linux.orig/arch/powerpc/kernel/cputable.c	2007-07-27 20:37:10.000000000 +0400
+++ linux/arch/powerpc/kernel/cputable.c	2007-07-27 20:44:26.000000000 +0400

@@ -1132,6 +1132,42 @@
 		.dcache_bsize		= 32,
 		.platform		= "ppc440",
 	},
+	{ /* 440EPX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D0,
+		.cpu_name		= "440EPX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D8,
+		.cpu_name		= "440GRX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008DC,
+		.cpu_name		= "440GRX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
 	{	/* 440GP Rev. B */
 		.pvr_mask		= 0xf0000fff,
 		.pvr_value		= 0x40000440,

diff -ruN linux.orig/arch/powerpc/kernel/head_44x.S linux/arch/powerpc/kernel/head_44x.S

--- linux.orig/arch/powerpc/kernel/head_44x.S	2007-07-27 20:37:10.000000000 +0400
+++ linux/arch/powerpc/kernel/head_44x.S	2007-07-27 20:44:26.000000000 +0400

@@ -217,7 +217,7 @@
 	lis	r4,interrupt_base@h	/* IVPR only uses the high 16-bits */
 	mtspr	SPRN_IVPR,r4
 
-#ifdef CONFIG_440EP
+#if defined(CONFIG_440EP) || defined(CONFIG_440EPX)
 	/* Clear DAPUIB flag in CCR0 (enable APU between CPU and FPU) */
 	mfspr	r2,SPRN_CCR0
 	lis	r3,0xffef

diff -ruN linux.orig/arch/powerpc/platforms/44x/Kconfig linux/arch/powerpc/platforms/44x/Kconfig

--- linux.orig/arch/powerpc/platforms/44x/Kconfig	2007-07-27 20:37:11.000000000 +0400
+++ linux/arch/powerpc/platforms/44x/Kconfig	2007-07-27 21:10:32.000000000 +0400

@@ -14,6 +14,14 @@
 	help
 	  This option enables support for the IBM PPC440GP evaluation board.
 
+config SEQUOIA
+	bool "Sequoia"
+	depends on 44x
+	default n
+	select 440EPX
+	help
+	  This option enables support for the AMCC PPC440EPX evaluation board.
+
 #config LUAN
 #	bool "Luan"
 #	depends on 44x

@@ -36,6 +44,13 @@
 	select PPC_FPU
 	select IBM440EP_ERR42
 
+config 440EPX
+	bool
+	select PPC_FPU
+# Disabled until the new EMAC Driver is merged.
+#	select IBM_NEW_EMAC_EMAC4
+#	select IBM_NEW_EMAC_ZMII
+
 config 440GP
 	bool
 # Disabled until the new EMAC Driver is merged.

@@ -49,7 +64,7 @@
 
 config 440A
 	bool
-	depends on 440GX
+	depends on 440GX || 440EPX
 	default y
 
 # 44x errata/workaround config symbols, selected by the CPU models above

diff -ruN linux.orig/arch/powerpc/platforms/44x/Makefile linux/arch/powerpc/platforms/44x/Makefile

--- linux.orig/arch/powerpc/platforms/44x/Makefile	2007-07-27 20:37:11.000000000 +0400
+++ linux/arch/powerpc/platforms/44x/Makefile	2007-07-27 20:44:26.000000000 +0400

@@ -1,2 +1,3 @@
 obj-$(CONFIG_44x)	:= misc_44x.o
 obj-$(CONFIG_EBONY)	+= ebony.o
+obj-$(CONFIG_SEQUOIA)	+= sequoia.o

diff -ruN linux.orig/arch/powerpc/platforms/44x/sequoia.c linux/arch/powerpc/platforms/44x/sequoia.c

--- linux.orig/arch/powerpc/platforms/44x/sequoia.c	1970-01-01 03:00:00.000000000 +0300
+++ linux/arch/powerpc/platforms/44x/sequoia.c	2007-07-27 20:44:26.000000000 +0400

@@ -0,0 +1,66 @@
+/*
+ * Sequoia board specific routines
+ *
+ * Wade Farnsworth <wfarnsworth@mvista.com>
+ * Copyright 2004-2007 MontaVista Software Inc.
+ *
+ * Rewritten and ported to the merged powerpc tree:
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation
+ *
+ * This program is free software; you can redistribute  it and/or modify it
+ * under  the terms of  the GNU General  Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+#include <linux/init.h>
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/of_platform.h>
+#include "44x.h"
+
+static struct of_device_id sequoia_of_bus[] = {
+	{ .compatible = "ibm,plb", },
+	{ .compatible = "ibm,opb", },
+	{ .compatible = "ibm,ebc", },
+	{},
+};
+
+static int __init sequoia_device_probe(void)
+{
+	if (!machine_is(sequoia))
+		return 0;
+
+	of_platform_bus_probe(NULL, sequoia_of_bus, NULL);
+
+	return 0;
+}
+device_initcall(sequoia_device_probe);
+
+static int __init sequoia_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	if (!of_flat_dt_is_compatible(root, "amcc,sequoia"))
+		return 0;
+
+	return 1;
+}
+
+static void __init sequoia_setup_arch(void)
+{
+}
+
+define_machine(sequoia) {
+	.name 				= "Sequoia",
+	.probe 				= sequoia_probe,
+	.setup_arch			= sequoia_setup_arch,
+	.progress 			= udbg_progress,
+	.init_IRQ 			= uic_init_tree,
+	.get_irq 			= uic_get_irq,
+	.restart			= ppc44x_reset_system,
+	.calibrate_decr			= generic_calibrate_decr,
+};

On Mon, Jul 30, 2007 at 07:16:28PM +0400, Valentine Barshak wrote:

Since the with/without Security/Kasumi versions have no differences in
their cputable entry other than the PVR, couldn't you just remove the
relevant PVR bit from the mask and use a single entry?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

quoted

+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 
440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Since the with/without Security/Kasumi versions have no differences in
their cputable entry other than the PVR, couldn't you just remove the
relevant PVR bit from the mask and use a single entry?

And get rid of the stupid "has an FPU" comment at the same time
please :-)


Segher

On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:

quoted

quoted

+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 
440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Since the with/without Security/Kasumi versions have no differences in
their cputable entry other than the PVR, couldn't you just remove the
relevant PVR bit from the mask and use a single entry?

And get rid of the stupid "has an FPU" comment at the same time
please :-)

Actually that comment may be worthwhile if expanded a little.  I think
the point is that 440EPx *unlike most other 4xx chips* has an FPU.  So
the point of the comment is not explaining the feature bit, which is
obvious, but as a "no, really, it does".

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On Wed, 1 Aug 2007 15:05:42 +1000
David Gibson [off-list ref] wrote:

On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:

quoted

quoted

quoted

+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 
440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Since the with/without Security/Kasumi versions have no differences in
their cputable entry other than the PVR, couldn't you just remove the
relevant PVR bit from the mask and use a single entry?

And get rid of the stupid "has an FPU" comment at the same time
please :-)

Actually that comment may be worthwhile if expanded a little.  I think
the point is that 440EPx *unlike most other 4xx chips* has an FPU.  So
the point of the comment is not explaining the feature bit, which is
obvious, but as a "no, really, it does".

Right.  440EP(x) are the only currently available 44x chips that
contain an FPU, so I also think the comment can stay.

josh

On Mon, 30 Jul 2007 19:16:28 +0400
Valentine Barshak [off-list ref] wrote:

Should the 440GRX PVR additions be done in a separate patch?  Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?

I didn't really do this.  Might want to give yourself credit instead :).

josh

On Thursday 02 August 2007, Josh Boyer wrote:

On Mon, 30 Jul 2007 19:16:28 +0400

quoted

+0400 +++ linux/arch/powerpc/kernel/cputable.c	2007-07-27
20:44:26.000000000 +0400 @@ -1132,6 +1132,42 @@
 		.dcache_bsize		= 32,
 		.platform		= "ppc440",
 	},
+	{ /* 440EPX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D0,
+		.cpu_name		= "440EPX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */ +		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */ +		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D8,
+		.cpu_name		= "440GRX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008DC,
+		.cpu_name		= "440GRX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Should the 440GRX PVR additions be done in a separate patch?  Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?

I think it makes sense to add the 440GRx with this patchset too. The 440GRx is 
a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC 
Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new 
board specific sources should be necessary to support the Rainier, just a 
different defconfig file.

Best regards,
Stefan

On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:

On Wed, 1 Aug 2007 15:05:42 +1000
David Gibson [off-list ref] wrote:

quoted

On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:

quoted

quoted

quoted

+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE |  
PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Since the with/without Security/Kasumi versions have no  
differences in
their cputable entry other than the PVR, couldn't you just  
remove the
relevant PVR bit from the mask and use a single entry?

And get rid of the stupid "has an FPU" comment at the same time
please :-)

Actually that comment may be worthwhile if expanded a little.  I  
think
the point is that 440EPx *unlike most other 4xx chips* has an  
FPU.  So
the point of the comment is not explaining the feature bit, which is
obvious, but as a "no, really, it does".

Right.  440EP(x) are the only currently available 44x chips that
contain an FPU, so I also think the comment can stay.

I agree w/Segher the comment is redundant.  Just make a note of the  
fact that we really have FPU in the commit message.

- k

Josh Boyer wrote:

On Mon, 30 Jul 2007 19:16:28 +0400
Valentine Barshak [off-list ref] wrote:

quoted

diff -ruN linux.orig/arch/powerpc/kernel/cputable.c linux/arch/powerpc/kernel/cputable.c

--- linux.orig/arch/powerpc/kernel/cputable.c	2007-07-27 20:37:10.000000000 +0400
+++ linux/arch/powerpc/kernel/cputable.c	2007-07-27 20:44:26.000000000 +0400

@@ -1132,6 +1132,42 @@
 		.dcache_bsize		= 32,
 		.platform		= "ppc440",
 	},
+	{ /* 440EPX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D0,
+		.cpu_name		= "440EPX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /* 440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D8,
+		.cpu_name		= "440GRX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008DC,
+		.cpu_name		= "440GRX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Should the 440GRX PVR additions be done in a separate patch?  Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?

440GRx Doesn't have USB (host/device) controllers and and FPU.
Actually, I have a 440GRx board with the same PVR valus as 440EPx has.
HW bug may be?
I think I'll remove 440GRx for now.

quoted

diff -ruN linux.orig/arch/powerpc/platforms/44x/sequoia.c linux/arch/powerpc/platforms/44x/sequoia.c

--- linux.orig/arch/powerpc/platforms/44x/sequoia.c	1970-01-01 03:00:00.000000000 +0300
+++ linux/arch/powerpc/platforms/44x/sequoia.c	2007-07-27 20:44:26.000000000 +0400

@@ -0,0 +1,66 @@
+/*
+ * Sequoia board specific routines
+ *
+ * Wade Farnsworth <wfarnsworth@mvista.com>
+ * Copyright 2004-2007 MontaVista Software Inc.
+ *
+ * Rewritten and ported to the merged powerpc tree:
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation

I didn't really do this.  Might want to give yourself credit instead :).

josh

I'll change it to "base on Bamboo code by Josh" :)

Stefan Roese wrote:

On Thursday 02 August 2007, Josh Boyer wrote:

quoted

On Mon, 30 Jul 2007 19:16:28 +0400

quoted

+0400 +++ linux/arch/powerpc/kernel/cputable.c	2007-07-27
20:44:26.000000000 +0400 @@ -1132,6 +1132,42 @@
 		.dcache_bsize		= 32,
 		.platform		= "ppc440",
 	},
+	{ /* 440EPX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D0,
+		.cpu_name		= "440EPX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */ +		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE | PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */ +		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - with Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D8,
+		.cpu_name		= "440GRX - with Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},
+	{ /* 440GRX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008DC,
+		.cpu_name		= "440GRX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE, /* 440GRX has no FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Should the 440GRX PVR additions be done in a separate patch?  Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?

I think it makes sense to add the 440GRx with this patchset too. The 440GRx is 
a subset of the 440EPx, missing some stuff like USB, FPU. And the AMCC 
Rainier 440GRx eval board is a subset of the Sequoia eval board. So no new 
board specific sources should be necessary to support the Rainier, just a 
different defconfig file.

Best regards,
Stefan

I have a Rainier 440GRx board and the PVR is equal to the 440EPx one 
(0x200008D0). This has to be handled somehow, since the 
PPC_FEATURE_HAS_FPU flag should *not* be set for 440GRx.
I'm really not sure how though. Any ideas are greatly appreciated :)
Is it a h/w bug?
Thanks,
Valentine.

On Friday 03 August 2007, Valentine Barshak wrote:

quoted

quoted

Should the 440GRX PVR additions be done in a separate patch?  Or is the
PVR and cpu features truly the only difference between 440EPx and
440GRx?

I think it makes sense to add the 440GRx with this patchset too. The
440GRx is a subset of the 440EPx, missing some stuff like USB, FPU. And
the AMCC Rainier 440GRx eval board is a subset of the Sequoia eval board.
So no new board specific sources should be necessary to support the
Rainier, just a different defconfig file.

Best regards,
Stefan

I have a Rainier 440GRx board and the PVR is equal to the 440EPx one
(0x200008D0). This has to be handled somehow, since the
PPC_FEATURE_HAS_FPU flag should *not* be set for 440GRx.
I'm really not sure how though. Any ideas are greatly appreciated :)
Is it a h/w bug?

Depends on interpretation. IIRC currently the same die is used for 440EPx and 
440GRx. I could be wrong here though and it is just a bug in the chip. But 
anyway we should support this somehow. Could be that I missed this in the 
current 440GRx (Rainier) arch/ppc support too. I have to admit, that no 
clever solution comes to my mind right away though.

Best regards,
Stefan

Depends on interpretation. IIRC currently the same die is used for 440EPx and 
440GRx. I could be wrong here though and it is just a bug in the chip. But 
anyway we should support this somehow. Could be that I missed this in the 
current 440GRx (Rainier) arch/ppc support too. I have to admit, that no 
clever solution comes to my mind right away though.

We can always come up with some kind of runtime detection, by turning on
MSR:FP, issuing an fp instruction and catching the illegal instruction
fault if any :-)

Ben.

On Fri, 3 Aug 2007 03:39:23 -0500
Kumar Gala [off-list ref] wrote:

On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:

quoted

On Wed, 1 Aug 2007 15:05:42 +1000
David Gibson [off-list ref] wrote:

quoted

On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:

quoted

quoted

quoted

+	{ /* 440EPX  - without Security/Kasumi  */
+		.pvr_mask		= 0xf0000fff,
+		.pvr_value		= 0x200008D4,
+		.cpu_name		= "440EPX - no Security/Kasumi",
+		.cpu_features		= CPU_FTRS_44X,
+		.cpu_user_features	= COMMON_USER_BOOKE |  
PPC_FEATURE_HAS_FPU, /*
440EPX has an FPU */
+		.icache_bsize		= 32,
+		.dcache_bsize		= 32,
+	},

Since the with/without Security/Kasumi versions have no  
differences in
their cputable entry other than the PVR, couldn't you just  
remove the
relevant PVR bit from the mask and use a single entry?

And get rid of the stupid "has an FPU" comment at the same time
please :-)

Actually that comment may be worthwhile if expanded a little.  I  
think
the point is that 440EPx *unlike most other 4xx chips* has an  
FPU.  So
the point of the comment is not explaining the feature bit, which is
obvious, but as a "no, really, it does".

Right.  440EP(x) are the only currently available 44x chips that
contain an FPU, so I also think the comment can stay.

I agree w/Segher the comment is redundant.  Just make a note of the  
fact that we really have FPU in the commit message.

Fine.  I don't really care either way because in the grand scheme of
things, it has no significant impact either way.  It's just a comment.

josh

Benjamin Herrenschmidt wrote:

quoted

Depends on interpretation. IIRC currently the same die is used for 440EPx and 
440GRx. I could be wrong here though and it is just a bug in the chip. But 
anyway we should support this somehow. Could be that I missed this in the 
current 440GRx (Rainier) arch/ppc support too. I have to admit, that no 
clever solution comes to my mind right away though.

We can always come up with some kind of runtime detection, by turning on
MSR:FP, issuing an fp instruction and catching the illegal instruction
fault if any :-)

Ben.

Is it OK to workaround the GRX/EPX having the same PVR issue using 
device tree?
Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in 
the device tree, fix the cputable entry and omit FPU initialization code.
Thanks,
Valentine.

On Fri, 2007-10-05 at 22:36 +0400, Valentine Barshak wrote:

Benjamin Herrenschmidt wrote:

quoted

quoted

Depends on interpretation. IIRC currently the same die is used for 440EPx and 
440GRx. I could be wrong here though and it is just a bug in the chip. But 
anyway we should support this somehow. Could be that I missed this in the 
current 440GRx (Rainier) arch/ppc support too. I have to admit, that no 
clever solution comes to my mind right away though.

We can always come up with some kind of runtime detection, by turning on
MSR:FP, issuing an fp instruction and catching the illegal instruction
fault if any :-)

Ben.

Is it OK to workaround the GRX/EPX having the same PVR issue using 
device tree?
Say, check the PVR value and if we have 440EPx PVR, but 440GRX node in 
the device tree, fix the cputable entry and omit FPU initialization code.

Fixing the CPU features based on the tree is definitely legit. We do
that on pseries. In fact, with paulus latest patch, the cputable is
__initdata and the cur CPU features is a -copy- which makes it even more
legitimate to whack it.

Ben.