[PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Stefan Roese]

The patch adds the Glacier dts. The Glacier is nearly identical to the
Canyonlands (460EX). Here the differences:

- 4 ethernet ports instead of 2
- no SATA port
- no USB port

Signed-off-by: Stefan Roese <sr@denx.de>
---
 arch/powerpc/boot/dts/glacier.dts |  464 +++++++++++++++++++++++++++++++++++++
 1 files changed, 464 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/glacier.dts

diff --git a/arch/powerpc/boot/dts/glacier.dts b/arch/powerpc/boot/dts/glacier.dts
new file mode 100644
index 0000000..7381cdd
--- /dev/null
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -0,0 +1,464 @@
+/*
+ * Device Tree Source for AMCC Glacier (460GT)
+ *
+ * Copyright 2008 DENX Software Engineering, Stefan Roese <sr@denx.de>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <1>;
+	model = "amcc,glacier";
+	compatible = "amcc,canyonlands";
+	dcr-parent = <&/cpus/cpu@0>;
+
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		ethernet2 = &EMAC2;
+		ethernet3 = &EMAC3;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			model = "PowerPC,460GT";
+			reg = <0>;
+			clock-frequency = <0>; /* Filled in by U-Boot */
+			timebase-frequency = <0>; /* Filled in by U-Boot */
+			i-cache-line-size = <20>;
+			d-cache-line-size = <20>;
+			i-cache-size = <8000>;
+			d-cache-size = <8000>;
+			dcr-controller;
+			dcr-access-method = "native";
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0 0 0>; /* Filled in by U-Boot */
+	};
+
+	UIC0: interrupt-controller0 {
+		compatible = "ibm,uic-460gt","ibm,uic";
+		interrupt-controller;
+		cell-index = <0>;
+		dcr-reg = <0c0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+	};
+
+	UIC1: interrupt-controller1 {
+		compatible = "ibm,uic-460gt","ibm,uic";
+		interrupt-controller;
+		cell-index = <1>;
+		dcr-reg = <0d0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <1e 4 1f 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	UIC2: interrupt-controller2 {
+		compatible = "ibm,uic-460gt","ibm,uic";
+		interrupt-controller;
+		cell-index = <2>;
+		dcr-reg = <0e0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <a 4 b 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	UIC3: interrupt-controller3 {
+		compatible = "ibm,uic-460gt","ibm,uic";
+		interrupt-controller;
+		cell-index = <3>;
+		dcr-reg = <0f0 009>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+		interrupts = <10 4 11 4>; /* cascade */
+		interrupt-parent = <&UIC0>;
+	};
+
+	SDR0: sdr {
+		compatible = "ibm,sdr-460gt";
+		dcr-reg = <00e 002>;
+	};
+
+	CPR0: cpr {
+		compatible = "ibm,cpr-460gt";
+		dcr-reg = <00c 002>;
+	};
+
+	plb {
+		compatible = "ibm,plb-460gt", "ibm,plb4";
+		#address-cells = <2>;
+		#size-cells = <1>;
+		ranges;
+		clock-frequency = <0>; /* Filled in by U-Boot */
+
+		SDRAM0: sdram {
+			compatible = "ibm,sdram-460gt", "ibm,sdram-405gp";
+			dcr-reg = <010 2>;
+		};
+
+		MAL0: mcmal {
+			compatible = "ibm,mcmal-460gt", "ibm,mcmal2";
+			dcr-reg = <180 62>;
+			num-tx-chans = <4>;
+			num-rx-chans = <20>;
+			#address-cells = <0>;
+			#size-cells = <0>;
+			interrupt-parent = <&UIC2>;
+			interrupts = <	/*TXEOB*/ 6 4
+					/*RXEOB*/ 7 4
+					/*SERR*/  3 4
+					/*TXDE*/  4 4
+					/*RXDE*/  5 4>;
+			desc-base-addr-high = <8>;
+		};
+
+		POB0: opb {
+			compatible = "ibm,opb-460gt", "ibm,opb";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <b0000000 4 b0000000 50000000>;
+			clock-frequency = <0>; /* Filled in by U-Boot */
+
+			EBC0: ebc {
+				compatible = "ibm,ebc-460gt", "ibm,ebc";
+				dcr-reg = <012 2>;
+				#address-cells = <2>;
+				#size-cells = <1>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				interrupts = <6 4>;
+				interrupt-parent = <&UIC1>;
+			};
+
+			UART0: serial@ef600300 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600300 8>;
+				virtual-reg = <ef600300>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1 4>;
+			};
+
+			UART1: serial@ef600400 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600400 8>;
+				virtual-reg = <ef600400>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC0>;
+				interrupts = <1 4>;
+			};
+
+			UART2: serial@ef600500 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600500 8>;
+				virtual-reg = <ef600500>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1d 4>;
+			};
+
+			UART3: serial@ef600600 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600600 8>;
+				virtual-reg = <ef600600>;
+				clock-frequency = <0>; /* Filled in by U-Boot */
+				current-speed = <0>; /* Filled in by U-Boot */
+				interrupt-parent = <&UIC1>;
+				interrupts = <1e 4>;
+			};
+
+			IIC0: i2c@ef600700 {
+				compatible = "ibm,iic-460gt", "ibm,iic";
+				reg = <ef600700 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <2 4>;
+			};
+
+			IIC1: i2c@ef600800 {
+				compatible = "ibm,iic-460gt", "ibm,iic";
+				reg = <ef600800 14>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <3 4>;
+			};
+
+			ZMII0: emac-zmii@ef600d00 {
+				compatible = "ibm,zmii-460gt", "ibm,zmii";
+				reg = <ef600d00 c>;
+			};
+
+			RGMII0: emac-rgmii@ef601500 {
+				compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+				reg = <ef601500 8>;
+				has-mdio;
+			};
+
+			RGMII1: emac-rgmii@ef601600 {
+				compatible = "ibm,rgmii-460gt", "ibm,rgmii";
+				reg = <ef601600 8>;
+				has-mdio;
+			};
+
+			TAH0: emac-tah@ef601350 {
+				compatible = "ibm,tah-460gt", "ibm,tah";
+				reg = <ef601350 30>;
+			};
+
+			TAH1: emac-tah@ef601450 {
+				compatible = "ibm,tah-460gt", "ibm,tah";
+				reg = <ef601450 30>;
+			};
+
+			EMAC0: ethernet@ef600e00 {
+				device_type = "network";
+				compatible = "ibm,emac-460gt", "ibm,emac4";
+				interrupt-parent = <&EMAC0>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 10 4
+						 /*Wake*/   1 &UIC2 14 4>;
+				reg = <ef600e00 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <0>;
+				mal-rx-channel = <0>;
+				cell-index = <0>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				rgmii-device = <&RGMII0>;
+				rgmii-channel = <0>;
+				tah-device = <&TAH0>;
+				tah-channel = <0>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+
+			EMAC1: ethernet@ef600f00 {
+				device_type = "network";
+				compatible = "ibm,emac-460gt", "ibm,emac4";
+				interrupt-parent = <&EMAC1>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 11 4
+						 /*Wake*/   1 &UIC2 15 4>;
+				reg = <ef600f00 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <1>;
+				mal-rx-channel = <8>;
+				cell-index = <1>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				rgmii-device = <&RGMII0>;
+				rgmii-channel = <1>;
+				tah-device = <&TAH1>;
+				tah-channel = <0>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+
+			EMAC2: ethernet@ef601100 {
+				device_type = "network";
+				compatible = "ibm,emac-460gt", "ibm,emac4";
+				interrupt-parent = <&EMAC2>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 12 4
+						 /*Wake*/   1 &UIC2 16 4>;
+				reg = <ef601100 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <2>;
+				mal-rx-channel = <10>;
+				cell-index = <2>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				rgmii-device = <&RGMII1>;
+				rgmii-channel = <0>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+
+			EMAC3: ethernet@ef601200 {
+				device_type = "network";
+				compatible = "ibm,emac-460gt", "ibm,emac4";
+				interrupt-parent = <&EMAC3>;
+				interrupts = <0 1>;
+				#interrupt-cells = <1>;
+				#address-cells = <0>;
+				#size-cells = <0>;
+				interrupt-map = </*Status*/ 0 &UIC2 13 4
+						 /*Wake*/   1 &UIC2 17 4>;
+				reg = <ef601200 70>;
+				local-mac-address = [000000000000]; /* Filled in by U-Boot */
+				mal-device = <&MAL0>;
+				mal-tx-channel = <3>;
+				mal-rx-channel = <18>;
+				cell-index = <3>;
+				max-frame-size = <2328>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "rgmii";
+				phy-map = <00000000>;
+				rgmii-device = <&RGMII1>;
+				rgmii-channel = <1>;
+				has-inverted-stacr-oc;
+				has-new-stacr-staopc;
+			};
+		};
+
+		PCIX0: pci@c0ec00000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pcix-460gt", "ibm,plb-pcix";
+			primary;
+			large-inbound-windows;
+			enable-msi-hole;
+			reg = <c 0ec00000   8	/* Config space access */
+			       0 0 0		/* no IACK cycles */
+			       c 0ed00000   4   /* Special cycles */
+			       c 0ec80000 100	/* Internal registers */
+			       c 0ec80100  fc>;	/* Internal messaging registers */
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000d 80000000 0 80000000
+				  01000000 0 00000000 0000000c 08000000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 0 to 0x3f */
+			bus-range = <0 3f>;
+
+			/* All PCI interrupts are routed to ext IRQ 2 -> UIC1-0 */
+			interrupt-map-mask = <0000 0 0 0>;
+			interrupt-map = < 0000 0 0 0 &UIC1 0 8 >;
+		};
+
+		PCIE0: pciex@d00000000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+			primary;
+			port = <0>; /* port number */
+			reg = <d 00000000 20000000	/* Config space access */
+			       c 08010000 00001000>;	/* Registers */
+			dcr-reg = <100 020>;
+			sdr-base = <300>;
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000e 00000000 0 80000000
+				  01000000 0 00000000 0000000f 80000000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 40 to 0x7f */
+			bus-range = <40 7f>;
+
+			/* Legacy interrupts (note the weird polarity, the bridge seems
+			 * to invert PCIe legacy interrupts).
+			 * We are de-swizzling here because the numbers are actually for
+			 * port of the root complex virtual P2P bridge. But I want
+			 * to avoid putting a node for it in the tree, so the numbers
+			 * below are basically de-swizzled numbers.
+			 * The real slot is on idsel 0, so the swizzling is 1:1
+			 */
+			interrupt-map-mask = <0000 0 0 7>;
+			interrupt-map = <
+				0000 0 0 1 &UIC3 c 4 /* swizzled int A */
+				0000 0 0 2 &UIC3 d 4 /* swizzled int B */
+				0000 0 0 3 &UIC3 e 4 /* swizzled int C */
+				0000 0 0 4 &UIC3 f 4 /* swizzled int D */>;
+		};
+
+		PCIE1: pciex@d20000000 {
+			device_type = "pci";
+			#interrupt-cells = <1>;
+			#size-cells = <2>;
+			#address-cells = <3>;
+			compatible = "ibm,plb-pciex-460ex", "ibm,plb-pciex";
+			primary;
+			port = <1>; /* port number */
+			reg = <d 20000000 20000000	/* Config space access */
+			       c 08011000 00001000>;	/* Registers */
+			dcr-reg = <120 020>;
+			sdr-base = <340>;
+
+			/* Outbound ranges, one memory and one IO,
+			 * later cannot be changed
+			 */
+			ranges = <02000000 0 80000000 0000000e 80000000 0 80000000
+				  01000000 0 00000000 0000000f 80010000 0 00010000>;
+
+			/* Inbound 2GB range starting at 0 */
+			dma-ranges = <42000000 0 0 0 0 0 80000000>;
+
+			/* This drives busses 80 to 0xbf */
+			bus-range = <80 bf>;
+
+			/* Legacy interrupts (note the weird polarity, the bridge seems
+			 * to invert PCIe legacy interrupts).
+			 * We are de-swizzling here because the numbers are actually for
+			 * port of the root complex virtual P2P bridge. But I want
+			 * to avoid putting a node for it in the tree, so the numbers
+			 * below are basically de-swizzled numbers.
+			 * The real slot is on idsel 0, so the swizzling is 1:1
+			 */
+			interrupt-map-mask = <0000 0 0 7>;
+			interrupt-map = <
+				0000 0 0 1 &UIC3 10 4 /* swizzled int A */
+				0000 0 0 2 &UIC3 11 4 /* swizzled int B */
+				0000 0 0 3 &UIC3 12 4 /* swizzled int C */
+				0000 0 0 4 &UIC3 13 4 /* swizzled int D */>;
+		};
+	};
+};
-- 
1.5.4.4

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Benjamin Herrenschmidt]

On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> +               cpu@0 {
> +                       device_type = "cpu";
> +                       model = "PowerPC,460GT";
> +                       reg = <0>;
> 

I wonder if we should do something here to differenciate the SoC chip
from the core. After all, all those 4xx mostly have the same core (there
are 2 or 3 revisions of the core maybe ...) but they tend to have all
different PVR which is a pain and won't scale...

Maybe AMCC could do something in HW (splitting the PVR from whatever
indicates what "chip" it is, and keeping the PVR purely for the core
rev) but I'm wondering if we should also do something in the DTS..
Stefan can you talk to your AMCC contacts about this ?

As for the DTS, maybe a "compatible" property in the CPU might make some
sense with a content along the lines of "ppc440x6" or whatever rev of
the 440 core it is.

What do you think ?

Cheers,
Ben.

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Stefan Roese]

On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
> On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> > +               cpu@0 {
> > +                       device_type = "cpu";
> > +                       model = "PowerPC,460GT";
> > +                       reg = <0>;
>
> I wonder if we should do something here to differenciate the SoC chip
> from the core. After all, all those 4xx mostly have the same core (there
> are 2 or 3 revisions of the core maybe ...) but they tend to have all
> different PVR which is a pain and won't scale...
>
> Maybe AMCC could do something in HW (splitting the PVR from whatever
> indicates what "chip" it is, and keeping the PVR purely for the core
> rev) but I'm wondering if we should also do something in the DTS..
> Stefan can you talk to your AMCC contacts about this ?

Yes, I'll do that. Not sure about the outcome though.

> As for the DTS, maybe a "compatible" property in the CPU might make some
> sense with a content along the lines of "ppc440x6" or whatever rev of
> the 440 core it is.
>
> What do you think ?

Good idea. I'll try to come up with a list for all existing 4xx SoC's and it's 
core versions.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office@denx.de
=====================================================================

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Josh Boyer]

On Fri, 21 Mar 2008 11:54:33 +0100
Stefan Roese <sr@denx.de> wrote:

> On Friday 21 March 2008, Benjamin Herrenschmidt wrote:
> > On Wed, 2008-03-19 at 17:15 +0100, Stefan Roese wrote:
> > > +               cpu@0 {
> > > +                       device_type = "cpu";
> > > +                       model = "PowerPC,460GT";
> > > +                       reg = <0>;
> >
> > I wonder if we should do something here to differenciate the SoC chip
> > from the core. After all, all those 4xx mostly have the same core (there
> > are 2 or 3 revisions of the core maybe ...) but they tend to have all
> > different PVR which is a pain and won't scale...
> >
> > Maybe AMCC could do something in HW (splitting the PVR from whatever
> > indicates what "chip" it is, and keeping the PVR purely for the core
> > rev) but I'm wondering if we should also do something in the DTS..
> > Stefan can you talk to your AMCC contacts about this ?
> 
> Yes, I'll do that. Not sure about the outcome though.
> 
> > As for the DTS, maybe a "compatible" property in the CPU might make some
> > sense with a content along the lines of "ppc440x6" or whatever rev of
> > the 440 core it is.
> >
> > What do you think ?
> 
> Good idea. I'll try to come up with a list for all existing 4xx SoC's and it's 
> core versions.

I don't really care either way, but what does that buy us?  Merely
documentation?

josh

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Segher Boessenkool]

>>> As for the DTS, maybe a "compatible" property in the CPU might make 
>>> some
>>> sense with a content along the lines of "ppc440x6" or whatever rev of
>>> the 440 core it is.
>>>
>>> What do you think ?
>>
>> Good idea. I'll try to come up with a list for all existing 4xx SoC's 
>> and it's
>> core versions.
>
> I don't really care either way, but what does that buy us?  Merely
> documentation?

Obviously, as long as the kernel doesn't use the device tree for probing
the CPUs available, additions to the device tree here don't affect the
kernel at all ;-P


Segher

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Josh Boyer]

On Fri, 21 Mar 2008 18:28:38 +0100
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> >>> As for the DTS, maybe a "compatible" property in the CPU might make 
> >>> some
> >>> sense with a content along the lines of "ppc440x6" or whatever rev of
> >>> the 440 core it is.
> >>>
> >>> What do you think ?
> >>
> >> Good idea. I'll try to come up with a list for all existing 4xx SoC's 
> >> and it's
> >> core versions.
> >
> > I don't really care either way, but what does that buy us?  Merely
> > documentation?
> 
> Obviously, as long as the kernel doesn't use the device tree for probing
> the CPUs available, additions to the device tree here don't affect the
> kernel at all ;-P

Yes, of course.  I meant were there other plans for it.  Ben and I had
a brief discussion of some of the possible uses and it seems pretty
sane.

josh

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Segher Boessenkool]

> As for the DTS, maybe a "compatible" property in the CPU might make 
> some
> sense with a content along the lines of "ppc440x6" or whatever rev of
> the 440 core it is.

Good idea, but please _also_ put the exact name in there, first; so
something like

	compatible = "AMCC,PowerPC,460GT", "AMCC,ppc440x6";

That way, you can still probe for specific versions where necessary.
This is completely in line with the "generic naming" recommended
practice; the PowerPC binding predates that RP, it really needs to
be updated.

Any reason we keep the device_type here, btw?


Segher

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Benjamin Herrenschmidt]

On Fri, 2008-03-21 at 12:46 +0100, Segher Boessenkool wrote:
> > As for the DTS, maybe a "compatible" property in the CPU might make 
> > some
> > sense with a content along the lines of "ppc440x6" or whatever rev of
> > the 440 core it is.
> 
> Good idea, but please _also_ put the exact name in there, first; so
> something like
> 
> 	compatible = "AMCC,PowerPC,460GT", "AMCC,ppc440x6";
> 
> That way, you can still probe for specific versions where necessary.
> This is completely in line with the "generic naming" recommended
> practice; the PowerPC binding predates that RP, it really needs to
> be updated.
> 
> Any reason we keep the device_type here, btw?

BTW, Should we sort compatible from the most specific to the most
specific or the other way around ?

Ben.

Re: [PATCH] [POWERPC] Add AMCC Glacier 460GT eval board dts

[Segher Boessenkool]

> BTW, Should we sort compatible from the most specific to the most
> specific or the other way around ?

Most specific first.


Segher