[PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[fkan]

From: Victor Gallardo <vgallard@amcc.com>

ppc4xx: Add AMCC Arches 460GT eval board support 

Signed-off-by: Victor Gallardo <vgallard@amcc.com>
---
 arch/powerpc/platforms/44x/Kconfig  |   18 ++++++++
 arch/powerpc/platforms/44x/Makefile |    1 +
 arch/powerpc/platforms/44x/arches.c |   76 +++++++++++++++++++++++++++++++++++
 3 files changed, 95 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/platforms/44x/arches.c

diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
index 6abe913..95d1217 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -77,6 +77,16 @@ config CANYONLANDS
 	help
 	  This option enables support for the AMCC PPC460EX evaluation board.
 
+config ARCHES
+	bool "Arches"
+	depends on 44x
+	default n
+	select 460GT
+	select PCI
+	select PPC4xx_PCI_EXPRESS
+	help
+	  This option enables support for the AMCC PPC460GT Arches board.
+
 config YOSEMITE
 	bool "Yosemite"
 	depends on 44x
@@ -149,6 +159,14 @@ config 460EX
 	select IBM_NEW_EMAC_ZMII
 	select IBM_NEW_EMAC_TAH
 
+config 460GT
+	bool
+	select PPC_FPU
+	select IBM_NEW_EMAC_EMAC4
+	select IBM_NEW_EMAC_RGMII
+	select IBM_NEW_EMAC_ZMII
+	select IBM_NEW_EMAC_TAH
+
 # 44x errata/workaround config symbols, selected by the CPU models above
 config IBM440EP_ERR42
 	bool
diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
index 774165f..86a4823 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER)	+= rainier.o
 obj-$(CONFIG_WARP)	+= warp.o
 obj-$(CONFIG_WARP)	+= warp-nand.o
 obj-$(CONFIG_CANYONLANDS) += canyonlands.o
+obj-$(CONFIG_ARCHES)	+= arches.o
diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c
new file mode 100644
index 0000000..6d6aa66
--- /dev/null
+++ b/arch/powerpc/platforms/44x/arches.c
@@ -0,0 +1,76 @@
+/*
+ * Arches board specific routines
+ *
+ * (C) Copyright 2008
+ * Victor Gallardo, Applied Micro Circuits Corp., vgallardo@amcc.com.
+ * Adam Graham, Applied Micro Circuits Corp., agraham@amcc.com.
+ *
+ * Based on the Canyonlands code by
+ * Stefan Roese <sr@denx.de>
+ * Copyright 2008 DENX Software Engineering
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/time.h>
+#include <asm/uic.h>
+#include <asm/pci-bridge.h>
+#include <asm/ppc4xx.h>
+
+static __initdata struct of_device_id arches_of_bus[] = {
+	{ .compatible = "ibm,plb4", },
+	{ .compatible = "ibm,opb", },
+	{ .compatible = "ibm,ebc", },
+	{},
+};
+
+static int __init arches_device_probe(void)
+{
+	of_platform_bus_probe(NULL, arches_of_bus, NULL);
+
+	return 0;
+}
+machine_device_initcall(arches, arches_device_probe);
+
+static int __init arches_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+
+	if (!of_flat_dt_is_compatible(root, "amcc,arches"))
+		return 0;
+
+	ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
+
+	return 1;
+}
+
+define_machine(arches) {
+	.name 				= "Arches",
+	.probe 				= arches_probe,
+	.progress 			= udbg_progress,
+	.init_IRQ 			= uic_init_tree,
+	.get_irq 			= uic_get_irq,
+	.restart			= ppc4xx_reset_system,
+	.calibrate_decr			= generic_calibrate_decr,
+};
-- 
1.5.5

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Josh Boyer]

On Tue, 15 Jul 2008 22:33:26 -0700
fkan@amcc.com wrote:

> From: Victor Gallardo <vgallard@amcc.com>
>=20
> ppc4xx: Add AMCC Arches 460GT eval board support=20
>=20
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>

=46rom what I can tell, you don't even need this patch or the defconfig.
Nothing differs at this point from Glacier other than the DTS.  Since
U-Boot is your loader, it should be able to pass the different DTS to a
kernel that supports Cayonlands and have no issues.

> ---
>  arch/powerpc/platforms/44x/Kconfig  |   18 ++++++++
>  arch/powerpc/platforms/44x/Makefile |    1 +
>  arch/powerpc/platforms/44x/arches.c |   76 +++++++++++++++++++++++++++++=
++++++
>  3 files changed, 95 insertions(+), 0 deletions(-)
>  create mode 100644 arch/powerpc/platforms/44x/arches.c
>=20
> diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/=
44x/Kconfig
> index 6abe913..95d1217 100644
> --- a/arch/powerpc/platforms/44x/Kconfig
> +++ b/arch/powerpc/platforms/44x/Kconfig
> @@ -77,6 +77,16 @@ config CANYONLANDS
>  	help
>  	  This option enables support for the AMCC PPC460EX evaluation board.
>=20
> +config ARCHES
> +	bool "Arches"
> +	depends on 44x
> +	default n
> +	select 460GT
> +	select PCI
> +	select PPC4xx_PCI_EXPRESS
> +	help
> +	  This option enables support for the AMCC PPC460GT Arches board.

If you do want to have explicit support for Arches, that's fine.  Look
at how Yosemite is supported.  It just reuses Bamboo.  You could do the
same.

>  config YOSEMITE
>  	bool "Yosemite"
>  	depends on 44x
> @@ -149,6 +159,14 @@ config 460EX
>  	select IBM_NEW_EMAC_ZMII
>  	select IBM_NEW_EMAC_TAH
>=20
> +config 460GT
> +	bool
> +	select PPC_FPU
> +	select IBM_NEW_EMAC_EMAC4
> +	select IBM_NEW_EMAC_RGMII
> +	select IBM_NEW_EMAC_ZMII
> +	select IBM_NEW_EMAC_TAH

I don't see a reason to add this at all.  460EX and 460GT select the
same set of options.

>  # 44x errata/workaround config symbols, selected by the CPU models above
>  config IBM440EP_ERR42
>  	bool
> diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms=
/44x/Makefile
> index 774165f..86a4823 100644
> --- a/arch/powerpc/platforms/44x/Makefile
> +++ b/arch/powerpc/platforms/44x/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER)	+=3D rainier.o
>  obj-$(CONFIG_WARP)	+=3D warp.o
>  obj-$(CONFIG_WARP)	+=3D warp-nand.o
>  obj-$(CONFIG_CANYONLANDS) +=3D canyonlands.o
> +obj-$(CONFIG_ARCHES)	+=3D arches.o

Here you would just have:

obj-$(CONFIG_ARCHES) +=3D cayonlands.o

> diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms=
/44x/arches.c
> new file mode 100644
> index 0000000..6d6aa66
> --- /dev/null
> +++ b/arch/powerpc/platforms/44x/arches.c

And then you don't need this file at all.  Just add a
"amcc,canyonlands" string to your root node compatible property.

josh

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Grant Likely]

On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> On Tue, 15 Jul 2008 22:33:26 -0700
> fkan@amcc.com wrote:
> 
> > From: Victor Gallardo <vgallard@amcc.com>
> > 
> > ppc4xx: Add AMCC Arches 460GT eval board support 
> > 
> > Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> 
> From what I can tell, you don't even need this patch or the defconfig.
> Nothing differs at this point from Glacier other than the DTS.  Since
> U-Boot is your loader, it should be able to pass the different DTS to a
> kernel that supports Cayonlands and have no issues.
> 
> > ---
> >  arch/powerpc/platforms/44x/Kconfig  |   18 ++++++++
> >  arch/powerpc/platforms/44x/Makefile |    1 +
> >  arch/powerpc/platforms/44x/arches.c |   76 +++++++++++++++++++++++++++++++++++
> >  3 files changed, 95 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/powerpc/platforms/44x/arches.c
> > 
> > diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> > index 6abe913..95d1217 100644
> > --- a/arch/powerpc/platforms/44x/Kconfig
> > +++ b/arch/powerpc/platforms/44x/Kconfig
> > @@ -77,6 +77,16 @@ config CANYONLANDS
> >  	help
> >  	  This option enables support for the AMCC PPC460EX evaluation board.
> > 
> > +config ARCHES
> > +	bool "Arches"
> > +	depends on 44x
> > +	default n
> > +	select 460GT
> > +	select PCI
> > +	select PPC4xx_PCI_EXPRESS
> > +	help
> > +	  This option enables support for the AMCC PPC460GT Arches board.
> 
> If you do want to have explicit support for Arches, that's fine.  Look
> at how Yosemite is supported.  It just reuses Bamboo.  You could do the
> same.
> 
> >  config YOSEMITE
> >  	bool "Yosemite"
> >  	depends on 44x
> > @@ -149,6 +159,14 @@ config 460EX
> >  	select IBM_NEW_EMAC_ZMII
> >  	select IBM_NEW_EMAC_TAH
> > 
> > +config 460GT
> > +	bool
> > +	select PPC_FPU
> > +	select IBM_NEW_EMAC_EMAC4
> > +	select IBM_NEW_EMAC_RGMII
> > +	select IBM_NEW_EMAC_ZMII
> > +	select IBM_NEW_EMAC_TAH
> 
> I don't see a reason to add this at all.  460EX and 460GT select the
> same set of options.
> 
> >  # 44x errata/workaround config symbols, selected by the CPU models above
> >  config IBM440EP_ERR42
> >  	bool
> > diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> > index 774165f..86a4823 100644
> > --- a/arch/powerpc/platforms/44x/Makefile
> > +++ b/arch/powerpc/platforms/44x/Makefile
> > @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER)	+= rainier.o
> >  obj-$(CONFIG_WARP)	+= warp.o
> >  obj-$(CONFIG_WARP)	+= warp-nand.o
> >  obj-$(CONFIG_CANYONLANDS) += canyonlands.o
> > +obj-$(CONFIG_ARCHES)	+= arches.o
> 
> Here you would just have:
> 
> obj-$(CONFIG_ARCHES) += cayonlands.o
> 
> > diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c
> > new file mode 100644
> > index 0000000..6d6aa66
> > --- /dev/null
> > +++ b/arch/powerpc/platforms/44x/arches.c
> 
> And then you don't need this file at all.  Just add a
> "amcc,canyonlands" string to your root node compatible property.

No!  Don't do this because it is not true!

Instead, add your board name to canyonlands.c in canyonlands_probe().
It's not the most scalable solution, but it keeps you from lying about
your hardware in the .dts file.

I'm working on a more scalable solution for this, but for now just add
your specific board to canyonlands_probe().

Cheers,
g.

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Josh Boyer]

On Wed, 16 Jul 2008 08:15:39 -0600
Grant Likely <grant.likely@secretlab.ca> wrote:

> On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> > On Tue, 15 Jul 2008 22:33:26 -0700
> > fkan@amcc.com wrote:
> > 
> > > From: Victor Gallardo <vgallard@amcc.com>
> > > 
> > > ppc4xx: Add AMCC Arches 460GT eval board support 
> > > 
> > > Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> > 
> > From what I can tell, you don't even need this patch or the defconfig.
> > Nothing differs at this point from Glacier other than the DTS.  Since
> > U-Boot is your loader, it should be able to pass the different DTS to a
> > kernel that supports Cayonlands and have no issues.
> > 
> > > ---
> > >  arch/powerpc/platforms/44x/Kconfig  |   18 ++++++++
> > >  arch/powerpc/platforms/44x/Makefile |    1 +
> > >  arch/powerpc/platforms/44x/arches.c |   76 +++++++++++++++++++++++++++++++++++
> > >  3 files changed, 95 insertions(+), 0 deletions(-)
> > >  create mode 100644 arch/powerpc/platforms/44x/arches.c
> > > 
> > > diff --git a/arch/powerpc/platforms/44x/Kconfig b/arch/powerpc/platforms/44x/Kconfig
> > > index 6abe913..95d1217 100644
> > > --- a/arch/powerpc/platforms/44x/Kconfig
> > > +++ b/arch/powerpc/platforms/44x/Kconfig
> > > @@ -77,6 +77,16 @@ config CANYONLANDS
> > >  	help
> > >  	  This option enables support for the AMCC PPC460EX evaluation board.
> > > 
> > > +config ARCHES
> > > +	bool "Arches"
> > > +	depends on 44x
> > > +	default n
> > > +	select 460GT
> > > +	select PCI
> > > +	select PPC4xx_PCI_EXPRESS
> > > +	help
> > > +	  This option enables support for the AMCC PPC460GT Arches board.
> > 
> > If you do want to have explicit support for Arches, that's fine.  Look
> > at how Yosemite is supported.  It just reuses Bamboo.  You could do the
> > same.
> > 
> > >  config YOSEMITE
> > >  	bool "Yosemite"
> > >  	depends on 44x
> > > @@ -149,6 +159,14 @@ config 460EX
> > >  	select IBM_NEW_EMAC_ZMII
> > >  	select IBM_NEW_EMAC_TAH
> > > 
> > > +config 460GT
> > > +	bool
> > > +	select PPC_FPU
> > > +	select IBM_NEW_EMAC_EMAC4
> > > +	select IBM_NEW_EMAC_RGMII
> > > +	select IBM_NEW_EMAC_ZMII
> > > +	select IBM_NEW_EMAC_TAH
> > 
> > I don't see a reason to add this at all.  460EX and 460GT select the
> > same set of options.
> > 
> > >  # 44x errata/workaround config symbols, selected by the CPU models above
> > >  config IBM440EP_ERR42
> > >  	bool
> > > diff --git a/arch/powerpc/platforms/44x/Makefile b/arch/powerpc/platforms/44x/Makefile
> > > index 774165f..86a4823 100644
> > > --- a/arch/powerpc/platforms/44x/Makefile
> > > +++ b/arch/powerpc/platforms/44x/Makefile
> > > @@ -9,3 +9,4 @@ obj-$(CONFIG_RAINIER)	+= rainier.o
> > >  obj-$(CONFIG_WARP)	+= warp.o
> > >  obj-$(CONFIG_WARP)	+= warp-nand.o
> > >  obj-$(CONFIG_CANYONLANDS) += canyonlands.o
> > > +obj-$(CONFIG_ARCHES)	+= arches.o
> > 
> > Here you would just have:
> > 
> > obj-$(CONFIG_ARCHES) += cayonlands.o
> > 
> > > diff --git a/arch/powerpc/platforms/44x/arches.c b/arch/powerpc/platforms/44x/arches.c
> > > new file mode 100644
> > > index 0000000..6d6aa66
> > > --- /dev/null
> > > +++ b/arch/powerpc/platforms/44x/arches.c
> > 
> > And then you don't need this file at all.  Just add a
> > "amcc,canyonlands" string to your root node compatible property.
> 
> No!  Don't do this because it is not true!

Meh. You're splitting hairs.  It _is_ true from a kernel perspective.

> Instead, add your board name to canyonlands.c in canyonlands_probe().
> It's not the most scalable solution, but it keeps you from lying about
> your hardware in the .dts file.

That could also be done.  Frankly though, if you look at the existing
board.c files in there now, none of them are special.  The device tree
really provides the differences these days, not the C code.  I'm this
|| close to just killing them all and doing a 4xx_board.c file that
does the right thing based on the few boards that have differences.

> I'm working on a more scalable solution for this, but for now just add
> your specific board to canyonlands_probe().

Glad to hear it.  Care to share your thoughts?  It seems to me that
adding board.c files that differ only in board name is pretty silly, so
if your solution avoids that I'll be happy.

josh

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Grant Likely]

On Wed, Jul 16, 2008 at 10:37:52AM -0400, Josh Boyer wrote:
> On Wed, 16 Jul 2008 08:15:39 -0600
> Grant Likely <grant.likely@secretlab.ca> wrote:
> 
> > On Wed, Jul 16, 2008 at 07:50:25AM -0400, Josh Boyer wrote:
> > > And then you don't need this file at all.  Just add a
> > > "amcc,canyonlands" string to your root node compatible property.
> > 
> > No!  Don't do this because it is not true!
> 
> Meh. You're splitting hairs.  It _is_ true from a kernel perspective.

... at this particular moment in time.  It may not be true 6 months from
now.

g.

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Segher Boessenkool]

>>> And then you don't need this file at all.  Just add a
>>> "amcc,canyonlands" string to your root node compatible property.
>>
>> No!  Don't do this because it is not true!

If the board actually _is_ compatible to the canyonlands board (it
only _adds_ stuff, doesn't change things or takes away things), it
is perfectly valid to declare it compatible, since it _is_.

In my opinion, for the root compatible value, it is also okay to
declare a board compatible if it is only "largely" compatible,
just has some little differences -- esp. if you're declaring a
board to be compatible to some reference design.  This does of
course have downsides as well.

> Meh. You're splitting hairs.  It _is_ true from a kernel perspective.

That doesn't matter.  The device tree describes the hardware, it doesn't
matter what the Linux kernel does.  For one thing, the kernel isn't
necessarily the only OS (or other client) to run with this DTS; also,
the kernel is a moving target, while the DTS can be burned into ROM.

>> Instead, add your board name to canyonlands.c in canyonlands_probe().
>> It's not the most scalable solution, but it keeps you from lying about
>> your hardware in the .dts file.
>
> That could also be done.  Frankly though, if you look at the existing
> board.c files in there now, none of them are special.  The device tree
> really provides the differences these days, not the C code.

Yes.  It would be more scalable if the platform probe code checks
the device tree for the features it expects (certain CPU, certain
interrupt controller, certain chipsets / bridges), instead of it
checking the root "compatible" property.

> I'm this
> || close to just killing them all and doing a 4xx_board.c file that
> does the right thing based on the few boards that have differences.

Oh, the kernel code even considers these things to be different
platforms?  Insane :-)


Segher

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Arnd Bergmann]

On Wednesday 16 July 2008, Grant Likely wrote:
>=20
> >=20
> > And then you don't need this file at all. =A0Just add a
> > "amcc,canyonlands" string to your root node compatible property.
>=20
> No! =A0Don't do this because it is not true!
>=20
> Instead, add your board name to canyonlands.c in canyonlands_probe().
> It's not the most scalable solution, but it keeps you from lying about
> your hardware in the .dts file.
>=20
> I'm working on a more scalable solution for this, but for now just add
> your specific board to canyonlands_probe().

Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
specific type unless you need to do something special?

=46or all I can tell, bamboo, canyonlands, katmai, rainier, sequoia
and taishan setup is already identical except for their names, while
ebony and Sam440ep are almost the same, except for their RTC device
probing (which should be done in a generic way as well ;-)).

	Arnd <><

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Grant Likely]

On Wed, Jul 16, 2008 at 04:46:01PM +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> > 
> > > 
> > > And then you don't need this file at all.  Just add a
> > > "amcc,canyonlands" string to your root node compatible property.
> > 
> > No!  Don't do this because it is not true!
> > 
> > Instead, add your board name to canyonlands.c in canyonlands_probe().
> > It's not the most scalable solution, but it keeps you from lying about
> > your hardware in the .dts file.
> > 
> > I'm working on a more scalable solution for this, but for now just add
> > your specific board to canyonlands_probe().
> 
> Shouldn't it be enough to have a common compatible value in each
> of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> specific type unless you need to do something special?

This is bad for the same reason that "amcc,44x-<blah>" compatible values
are bad in device nodes.  The definition of '*-44x-*' changes over time as
new parts are added.  Compatible values should always reflect an exact
part number.

g.

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Arnd Bergmann]

On Wednesday 16 July 2008, Grant Likely wrote:
>=20
> > Shouldn't it be enough to have a common compatible value in each
> > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > specific type unless you need to do something special?
>=20
> This is bad for the same reason that "amcc,44x-<blah>" compatible values
> are bad in device nodes. =A0The definition of '*-44x-*' changes over time=
 as
> new parts are added. =A0Compatible values should always reflect an exact
> part number.

I agree in general, but I also think that all 44x boards should be
regarded as the same machine time, in the same way that all powermacs
are detected as compatible with "Power Macintosh" or "MacRISC", or
how all sorts of serial ports claim compatibility with i8250.

=46or classic SOCs like 4xx or 52xx, the SOC familiy more or less defines
the platform, and all the details about peripherals can be expressed
in the device tree elsewhere.

If one board is so different that you need a separate board setup
in the kernel, it should simply not claim compatibility with the
SOC platform.

	Arnd <><

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Josh Boyer]

On Thu, 2008-07-17 at 00:58 +0200, Arnd Bergmann wrote:
> On Wednesday 16 July 2008, Grant Likely wrote:
> > 
> > > Shouldn't it be enough to have a common compatible value in each
> > > of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
> > > specific type unless you need to do something special?
> > 
> > This is bad for the same reason that "amcc,44x-<blah>" compatible values
> > are bad in device nodes.  The definition of '*-44x-*' changes over time as
> > new parts are added.  Compatible values should always reflect an exact
> > part number.
> 
> I agree in general, but I also think that all 44x boards should be
> regarded as the same machine time, in the same way that all powermacs
> are detected as compatible with "Power Macintosh" or "MacRISC", or
> how all sorts of serial ports claim compatibility with i8250.
> 
> For classic SOCs like 4xx or 52xx, the SOC familiy more or less defines
> the platform, and all the details about peripherals can be expressed
> in the device tree elsewhere.

This is what Grant has done for 52xx and what I was talking about with
"4xx_board.c", though 4xx_soc.c is probably a better name.

My hesitation is that while it's true today that 440<chip name> defines
the SoC, it might not always be.  And the Virtex boards are craziness
with the core and FPGA setup.  So we need to be careful a bit when
chosing what do "bind" to for generics.

> If one board is so different that you need a separate board setup
> in the kernel, it should simply not claim compatibility with the
> SOC platform.

Right.  Today we only have a few "overrides" in 4xx.  Namely
Canyonlands/Glacier, and Bamboo/Yosemite (Sequoia/Rainier should also
really be that way, but they aren't).  So if we decide to go to a
different scheme, it shouldn't be a big deal to switch.

josh

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Segher Boessenkool]

>>> Shouldn't it be enough to have a common compatible value in each
>>> of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
>>> specific type unless you need to do something special?
>>
>> This is bad for the same reason that "amcc,44x-<blah>" compatible=20
>> values
>> are bad in device nodes. =A0The definition of '*-44x-*' changes over=20=

>> time as
>> new parts are added. =A0Compatible values should always reflect an =
exact
>> part number.
>
> I agree in general, but I also think that all 44x boards should be
> regarded as the same machine time, in the same way that all powermacs
> are detected as compatible with "Power Macintosh" or "MacRISC", or
> how all sorts of serial ports claim compatibility with i8250.

And they can do that because a binding for those "compatible" names
exists, that describes exactly what it means for a device to be "i8250"
or "MacRISC" (well, in that last case, maybe such a binding exists, or
maybe it doesn't, but we don't know about it anyway, sigh).


Segher

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Segher Boessenkool]

>> Shouldn't it be enough to have a common compatible value in each
>> of these boards, e.g. "amcc,generic-ppc44x" and then just ignore the
>> specific type unless you need to do something special?
>
> This is bad for the same reason that "amcc,44x-<blah>" compatible 
> values
> are bad in device nodes.  The definition of '*-44x-*' changes over 
> time as
> new parts are added.  Compatible values should always reflect an exact
> part number.

Erm, no.

"compatible" entries should always contain the real part name to reduce
the chance that separate parties come up with the same "compatible"
name for two different devices.

Other than that, the name really doesn't matter, it's just _some_
string that uniquely identifies a device; and the device bindings will
document what is what.

Of course, if no binding is written, it becomes a lot more important
that names have a sane value ;-)


Segher

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Victor Gallardo]

> From what I can tell, you don't even need this patch or the defconfig.
> Nothing differs at this point from Glacier other than the DTS.  Since
> U-Boot is your loader, it should be able to pass the different DTS to a
> kernel that supports Cayonlands and have no issues.
>
> ...
>
> If you do want to have explicit support for Arches, that's fine.  Look
> at how Yosemite is supported.  It just reuses Bamboo.  You could do the
> same.

Yes, I like this idea. I'll do this.

>> +config 460GT
>> +	bool
>> +	select PPC_FPU
>> +	select IBM_NEW_EMAC_EMAC4
>> +	select IBM_NEW_EMAC_RGMII
>> +	select IBM_NEW_EMAC_ZMII
>> +	select IBM_NEW_EMAC_TAH
>
> I don't see a reason to add this at all.  460EX and 460GT select the
> same set of options.

OK. I agree.

> Here you would just have:
>
> obj-$(CONFIG_ARCHES) += cayonlands.o

>> diff --git a/arch/powerpc/platforms/44x/arches.c
>> b/arch/powerpc/platforms/44x/arches.c
>> new file mode 100644
>> index 0000000..6d6aa66
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/44x/arches.c
>
> And then you don't need this file at all.  Just add a
> "amcc,canyonlands" string to your root node compatible property.

OK. Will update

Thanks,

Victor Gallardo
-- 
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18538794.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Josh Boyer]

On Fri, 18 Jul 2008 15:31:33 -0700 (PDT)
Victor Gallardo <vgallardo@amcc.com> wrote:

> 
> > From what I can tell, you don't even need this patch or the defconfig.
> > Nothing differs at this point from Glacier other than the DTS.  Since
> > U-Boot is your loader, it should be able to pass the different DTS to a
> > kernel that supports Cayonlands and have no issues.
> >
> > ...
> >
> > If you do want to have explicit support for Arches, that's fine.  Look
> > at how Yosemite is supported.  It just reuses Bamboo.  You could do the
> > same.
> 
> Yes, I like this idea. I'll do this.

As you might have noticed, this has generated quite a bit of discussion
on whether this is the right approach or not.  If you can wait for a
week, we plan on talking it over at OLS.  Then I can give you a better
idea as to whether we're going to stick with this or use a different
approach.

Overall your patches are fairly clean, so you've done a good job so
far.  Have a little patience with us as we figure out the right way to
go :).

josh

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Victor Gallardo]

>As you might have noticed, this has generated quite a bit of discussion
>on whether this is the right approach or not.  If you can wait for a
>week, we plan on talking it over at OLS.  Then I can give you a better
>idea as to whether we're going to stick with this or use a different
>approach.
>
>Overall your patches are fairly clean, so you've done a good job so
>far.  Have a little patience with us as we figure out the right way to
>go :).
>
>josh

OK. I watch the mailing list for updates.

Thanks,

Victor Gallardo
-- 
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18597016.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Stefan Roese]

On Wednesday 16 July 2008, fkan@amcc.com wrote:
> From: Victor Gallardo <vgallard@amcc.com>
>
> ppc4xx: Add AMCC Arches 460GT eval board support
>
> Signed-off-by: Victor Gallardo <vgallard@amcc.com>

Please put a brief description of Arches in the patch description.

Best regards,
Stefan

Re: [PATCH] Add AMCC Arches 460GT eval board support to platforms/44x

[Victor Gallardo]

OK, will do.

-Victor Gallardo


Stefan Roese wrote:
> 
> On Wednesday 16 July 2008, fkan@amcc.com wrote:
>> From: Victor Gallardo <vgallard@amcc.com>
>>
>> ppc4xx: Add AMCC Arches 460GT eval board support
>>
>> Signed-off-by: Victor Gallardo <vgallard@amcc.com>
> 
> Please put a brief description of Arches in the patch description.
> 
> Best regards,
> Stefan
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/-PATCH--Add-AMCC-Arches-460GT-eval-board-support-to-platforms-44x-tp18480745p18538706.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.