[PATCH 2/2] Add local bus device nodes to MPC837xMDS device trees.

Signed-off-by: Li Yang <redacted>
---
 arch/powerpc/boot/dts/mpc8377_mds.dts     |   66 +++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/mpc8378_mds.dts     |   66 +++++++++++++++++++++++++++++
 arch/powerpc/boot/dts/mpc8379_mds.dts     |   66 +++++++++++++++++++++++++++++
 arch/powerpc/platforms/83xx/mpc837x_mds.c |    8 +--
 4 files changed, 201 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8377_mds.dts b/arch/powerpc/boot/dts/mpc8377_mds.dts
index 677a061..3aac8b7 100644
--- a/arch/powerpc/boot/dts/mpc8377_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8377_mds.dts

@@ -47,6 +47,72 @@
 		reg = <0x00000000 0x20000000>;	// 512MB at 0
 	};
 
+	localbus@e0005000 {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc8377-elbc", "fsl,elbc", "simple-bus";
+		reg = <0xe0005000 0x1000>;
+		interrupts = <77 0x8>;
+		interrupt-parent = <&ipic>;
+
+		// booting from NOR flash
+		ranges = <0 0x0 0xfe000000 0x02000000
+		          1 0x0 0xf8000000 0x00008000
+		          3 0x0 0xe0600000 0x00008000>;
+
+		flash@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0 0x0 0x2000000>;
+			bank-width = <2>;
+			device-width = <1>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			fs@100000 {
+				reg = <0x100000 0x800000>;
+			};
+
+			kernel@1d00000 {
+				reg = <0x1d00000 0x200000>;
+			};
+
+			dtb@1f00000 {
+				reg = <0x1f00000 0x100000>;
+			};
+		};
+
+		bcsr@1,0 {
+			reg = <1 0x0 0x8000>;
+			compatible = "fsl,mpc837xmds-bcsr";
+		};
+
+		nand@3,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,mpc8377-fcm-nand",
+			             "fsl,elbc-fcm-nand";
+			reg = <3 0x0 0x8000>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			kernel@100000 {
+				reg = <0x100000 0x300000>;
+			};
+
+			fs@400000 {
+				reg = <0x400000 0x1c00000>;
+			};
+		};
+	};
+
 	soc@e0000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;

diff --git a/arch/powerpc/boot/dts/mpc8378_mds.dts b/arch/powerpc/boot/dts/mpc8378_mds.dts
index 3f9e9fe..2496e19 100644
--- a/arch/powerpc/boot/dts/mpc8378_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8378_mds.dts

@@ -47,6 +47,72 @@
 		reg = <0x00000000 0x20000000>;	// 512MB at 0
 	};
 
+	localbus@e0005000 {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc8378-elbc", "fsl,elbc", "simple-bus";
+		reg = <0xe0005000 0x1000>;
+		interrupts = <77 0x8>;
+		interrupt-parent = <&ipic>;
+
+		// booting from NOR flash
+		ranges = <0 0x0 0xfe000000 0x02000000
+		          1 0x0 0xf8000000 0x00008000
+		          3 0x0 0xe0600000 0x00008000>;
+
+		flash@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0 0x0 0x2000000>;
+			bank-width = <2>;
+			device-width = <1>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			fs@100000 {
+				reg = <0x100000 0x800000>;
+			};
+
+			kernel@1d00000 {
+				reg = <0x1d00000 0x200000>;
+			};
+
+			dtb@1f00000 {
+				reg = <0x1f00000 0x100000>;
+			};
+		};
+
+		bcsr@1,0 {
+			reg = <1 0x0 0x8000>;
+			compatible = "fsl,mpc837xmds-bcsr";
+		};
+
+		nand@3,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,mpc8378-fcm-nand",
+			             "fsl,elbc-fcm-nand";
+			reg = <3 0x0 0x8000>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			kernel@100000 {
+				reg = <0x100000 0x300000>;
+			};
+
+			fs@400000 {
+				reg = <0x400000 0x1c00000>;
+			};
+		};
+	};
+
 	soc@e0000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;

diff --git a/arch/powerpc/boot/dts/mpc8379_mds.dts b/arch/powerpc/boot/dts/mpc8379_mds.dts
index 36c1c13..5ae4644 100644
--- a/arch/powerpc/boot/dts/mpc8379_mds.dts
+++ b/arch/powerpc/boot/dts/mpc8379_mds.dts

@@ -47,6 +47,72 @@
 		reg = <0x00000000 0x20000000>;	// 512MB at 0
 	};
 
+	localbus@e0005000 {
+		#address-cells = <2>;
+		#size-cells = <1>;
+		compatible = "fsl,mpc8379-elbc", "fsl,elbc", "simple-bus";
+		reg = <0xe0005000 0x1000>;
+		interrupts = <77 0x8>;
+		interrupt-parent = <&ipic>;
+
+		// booting from NOR flash
+		ranges = <0 0x0 0xfe000000 0x02000000
+		          1 0x0 0xf8000000 0x00008000
+		          3 0x0 0xe0600000 0x00008000>;
+
+		flash@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0 0x0 0x2000000>;
+			bank-width = <2>;
+			device-width = <1>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			fs@100000 {
+				reg = <0x100000 0x800000>;
+			};
+
+			kernel@1d00000 {
+				reg = <0x1d00000 0x200000>;
+			};
+
+			dtb@1f00000 {
+				reg = <0x1f00000 0x100000>;
+			};
+		};
+
+		bcsr@1,0 {
+			reg = <1 0x0 0x8000>;
+			compatible = "fsl,mpc837xmds-bcsr";
+		};
+
+		nand@3,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,mpc8379-fcm-nand",
+			             "fsl,elbc-fcm-nand";
+			reg = <3 0x0 0x8000>;
+
+			u-boot@0 {
+				reg = <0x0 0x100000>;
+				read-only;
+			};
+
+			kernel@100000 {
+				reg = <0x100000 0x300000>;
+			};
+
+			fs@400000 {
+				reg = <0x400000 0x1c00000>;
+			};
+		};
+	};
+
 	soc@e0000000 {
 		#address-cells = <1>;
 		#size-cells = <1>;

diff --git a/arch/powerpc/platforms/83xx/mpc837x_mds.c b/arch/powerpc/platforms/83xx/mpc837x_mds.c
index 8a9c269..1f4b7e8 100644
--- a/arch/powerpc/platforms/83xx/mpc837x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc837x_mds.c

@@ -39,12 +39,9 @@ static int mpc837xmds_usb_cfg(void)
 	if (ret)
 		return ret;
 	/* Map BCSR area */
-	np = of_find_node_by_name(NULL, "bcsr");
+	np = of_find_compatible_node(NULL, NULL, "fsl,mpc837xmds-bcsr");
 	if (np) {
-		struct resource res;
-
-		of_address_to_resource(np, 0, &res);
-		bcsr_regs = ioremap(res.start, res.end - res.start + 1);
+		bcsr_regs = of_iomap(np, 0);
 		of_node_put(np);
 	}
 	if (!bcsr_regs)

@@ -96,6 +93,7 @@ static void __init mpc837x_mds_setup_arch(void)
 static struct of_device_id mpc837x_ids[] = {
 	{ .type = "soc", },
 	{ .compatible = "soc", },
+	{ .compatible = "simple-bus", },
 	{},
 };
 

-- 
1.5.4.rc4

[snip]

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

-- 
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

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

What's wrong with the already well-established generic name "flash"?

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

Fine with me, but it's very vague (hard to avoid though).


Segher

On Mar 6, 2008, at 6:27 PM, David Gibson wrote:

[snip]

quoted

+		bcsr@1,0 {
+			reg = <1 0x0 0x8000>;
+			compatible = "fsl,mpc837xmds-bcsr";
+		};
+
+		nand@3,0 {

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

This seems reasonable.

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

I don't see any reason for this.  If I have a cpld or fpga why not just call it that.  I don't see what calling it 'board-control' gets us.  There may be non-board control functionality in an fpga than what do we call it?

- k

On Mar 6, 2008, at 4:42 AM, Li Yang wrote:

Signed-off-by: Li Yang <redacted>
---
arch/powerpc/boot/dts/mpc8377_mds.dts     |   66 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8378_mds.dts     |   66 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/mpc8379_mds.dts     |   66 +++++++++++++++++++++++++++++
arch/powerpc/platforms/83xx/mpc837x_mds.c |    8 +--
4 files changed, 201 insertions(+), 5 deletions(-)

applied.

- k

quoted

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

I don't see any reason for this.  If I have a cpld or fpga why not
just call it that.  I don't see what calling it 'board-control' gets
us.  There may be non-board control functionality in an fpga than what
do we call it?

Good point.  Also, it is important to keep in mind that the "name" is
meant for human consumption only, so while it is important to use some
consistent naming (to not confuse the user), there should be quite some
leeway here.


Segher

On Fri, Mar 07, 2008 at 08:35:39AM -0600, Kumar Gala wrote:

On Mar 6, 2008, at 6:27 PM, David Gibson wrote:

[snip]

quoted

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

I don't see any reason for this.  If I have a cpld or fpga why not  
just call it that.  I don't see what calling it 'board-control' gets  
us.  There may be non-board control functionality in an fpga than what  
do we call it?

Exactly!  The device tree is supposed to describe the hardware from a
functional perspective, so the fact that something is implemented in
an fpga or cpld is irrelevant, what matters is what's inside the fpga.

If an fpga was used to implement an ethernet MAC, we'd call if
"ethernet", if something else, something else.  If it was designed to
be programmed at runtime by the OS, then we'd probably call it "fpga",
but otherwise it should be named for what's inside it.

-- 
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 Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:

quoted

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

What's wrong with the already well-established generic name "flash"?

I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise.  I am quite open to being
convinced otherwise, though.

quoted

I've seen several variants for board control devices (cpld, bcsr,
fpga, etc.) I suggest we standardise on "board-control"

Fine with me, but it's very vague (hard to avoid though).

Yes.

-- 
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 Tuesday 11 March 2008, David Gibson wrote:

On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:

quoted

quoted

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

=20
What's wrong with the already well-established generic name "flash"?

=20
I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise. =A0I am quite open to being
convinced otherwise, though.

One argument for just using "flash" is that there are much finer differences
than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
being further types of flash that don't fit the categories exactly, though
each one for different reasons.

=46or SD/MMC, there are good reasons to use something completely different,
for the others, calling them all "flash" sounds better than fitting them
into "nand" and "nor".

	Arnd <><

On Tue, Mar 11, 2008 at 01:43:49AM +0100, Arnd Bergmann wrote:

On Tuesday 11 March 2008, David Gibson wrote:

quoted

On Fri, Mar 07, 2008 at 04:39:30AM +0100, Segher Boessenkool wrote:

quoted

quoted

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

What's wrong with the already well-established generic name "flash"?

I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise.  I am quite open to being
convinced otherwise, though.

One argument for just using "flash" is that there are much finer differences
than just "NAND" and "NOR", with at least "dataflash", "OneNAND", "SD/MMC"
being further types of flash that don't fit the categories exactly, though
each one for different reasons.

For SD/MMC, there are good reasons to use something completely different,
for the others, calling them all "flash" sounds better than fitting them
into "nand" and "nor".

Ok, I'm convinced.  "flash" it is.

-- 
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

quoted

This isn't a problem with this device tree, but it's probably time we
started establishing some conventional generic names for nand flash
and board-control devices.

So, to start the ball rolling, I've seen several names for nand flash
nodes, I'd suggest we standardise on "nand-flash".

What's wrong with the already well-established generic name "flash"?

I was concerned that using "flash" for both NOR flash (which it
already is) and NAND flash might be unwise.  I am quite open to being
convinced otherwise, though.

You already said you're convinced, but I'll add another argument
anyway...

For NAND flash, there will usually be a parent node named "nand-controller"
or similar, while NOR flash will typically be direct-mapped.

There is always this tension between making the names as generic as
possible, and not losing too much information.  In my experience, you
can always make leaf nodes have very very generic names, it's only the
bus nodes where this can be harder.  And then there are exceptions like
"board-control" where there just _is_ no really good name ;-)


Segher