Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1363755 > unrolled thread

[PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Andreas Färber <afaerber@suse.de> - 2016-03-23 23:30 +0100
    Re: [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-03-24 09:20 +0100
      Re: [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Gregory CLEMENT <gregory.clement@free-electrons.com> - 2016-03-24 11:30 +0100
        Re: [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Thomas Petazzoni <thomas.petazzoni@free-electrons.com> - 2016-03-24 11:50 +0100
          Re: [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Andrew Lunn <andrew@lunn.ch> - 2016-03-24 14:40 +0100
            Re: [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db Jason Cooper <jason@lakedaemon.net> - 2016-03-24 15:00 +0100

#1363755 — [PATCH 3/4] arm64: dts: marvell: Clean up armada-7040-db

Instead of duplicating the node hierarchy, reference the nodes by label,
adding labels where necessary.

Drop some trailing or inconsistent white lines while at it.

Fixes: ec7e5a569bce ("arm64: dts: marvell: add Device Tree files for Armada 7K/8K")
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 Is it intentional that there are no aliases for the two serial nodes and no /chosen/stdout-path?
 
 arch/arm64/boot/dts/marvell/armada-7040-db.dts     | 52 ++++++++++------------
 arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi |  1 -
 arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi |  2 -
 arch/arm64/boot/dts/marvell/armada-ap806.dtsi      |  7 +--
 4 files changed, 26 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-7040-db.dts b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
index 064a251346dd..ee5778395bea 100644
--- a/arch/arm64/boot/dts/marvell/armada-7040-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-7040-db.dts
@@ -55,38 +55,34 @@
 		device_type = "memory";
 		reg = <0x0 0x0 0x0 0x80000000>;
 	};
+};
 
-	ap806 {
-		config-space {
-			spi@510600 {
-				status = "okay";
-
-				spi-flash@0 {
-					#address-cells = <1>;
-					#size-cells = <1>;
-					compatible = "n25q128a13";
-					reg = <0>; /* Chip select 0 */
-					spi-max-frequency = <10000000>;
+&i2c0 {
+	status = "okay";
+	clock-frequency = <100000>;
+};
 
-					partition@0 {
-						label = "U-Boot";
-						reg = <0 0x200000>;
-					};
-					partition@400000 {
-						label = "Filesystem";
-						reg = <0x200000 0xce0000>;
-					};
-				};
-			};
+&spi0 {
+	status = "okay";
 
-			i2c@511000 {
-				status = "okay";
-				clock-frequency = <100000>;
-			};
+	spi-flash@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "n25q128a13";
+		reg = <0>; /* Chip select 0 */
+		spi-max-frequency = <10000000>;
 
-			serial@512000 {
-				status = "okay";
-			};
+		partition@0 {
+			label = "U-Boot";
+			reg = <0 0x200000>;
+		};
+		partition@400000 {
+			label = "Filesystem";
+			reg = <0x200000 0xce0000>;
 		};
 	};
 };
+
+&uart0 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
index f25c5c17fad7..95a1ff60f6c1 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-dual.dtsi
@@ -68,4 +68,3 @@
 		};
 	};
 };
-
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
index baa7d9a516b3..ba43a4357b89 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806-quad.dtsi
@@ -79,6 +79,4 @@
 			enable-method = "psci";
 		};
 	};
-
 };
-
diff --git a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
index 556a92bcc2f6..3ecf9b1798fa 100644
--- a/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-ap806.dtsi
@@ -59,7 +59,6 @@
 		method = "smc";
 	};
 
-
 	ap806 {
 		#address-cells = <2>;
 		#size-cells = <2>;
@@ -190,7 +189,7 @@
 				status = "disabled";
 			};
 
-			serial@512000 {
+			uart0: serial@512000 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x512000 0x100>;
 				reg-shift = <2>;
@@ -200,7 +199,7 @@
 				status = "disabled";
 			};
 
-			serial@512100 {
+			uart1: serial@512100 {
 				compatible = "snps,dw-apb-uart";
 				reg = <0x512100 0x100>;
 				reg-shift = <2>;
@@ -232,6 +231,4 @@
 			};
 		};
 	};
-
 };
-
-- 
2.6.2

[toc] | [next] | [standalone]

#1364002

Hello,

On Wed, 23 Mar 2016 23:24:20 +0100, Andreas Färber wrote:
> Instead of duplicating the node hierarchy, reference the nodes by label,
> adding labels where necessary.
> 
> Drop some trailing or inconsistent white lines while at it.
> 
> Fixes: ec7e5a569bce ("arm64: dts: marvell: add Device Tree files for Armada 7K/8K")
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Signed-off-by: Andreas Färber <afaerber@suse.de>

We haven't used this solution on Marvell Armada 32-bits SoCs, so there
needs to be a discussion on whether we want to go in this direction for
the 64 bits SoCs.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1364048

Hi Thomas,
 
 On jeu., mars 24 2016, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> Hello,
>
> On Wed, 23 Mar 2016 23:24:20 +0100, Andreas Färber wrote:
>> Instead of duplicating the node hierarchy, reference the nodes by label,
>> adding labels where necessary.
>> 
>> Drop some trailing or inconsistent white lines while at it.
>> 
>> Fixes: ec7e5a569bce ("arm64: dts: marvell: add Device Tree files for Armada 7K/8K")
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Signed-off-by: Andreas Färber <afaerber@suse.de>
>
> We haven't used this solution on Marvell Armada 32-bits SoCs, so there
> needs to be a discussion on whether we want to go in this direction for
> the 64 bits SoCs.

At first view using the label helps to have simpler dts files.

Is there any cons by using it?

I agree that converting the Marvell Armada 32-bits SoCs would produce a
lot of churn. But if some binding are common there is no file at all are
in common, so we could use this solution for the 64 bits SoCs only.

Jason, Andrew, Sebastian, do you see any problem with it?

Thanks,

Gregory

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1364059

Hello,

On Thu, 24 Mar 2016 11:27:27 +0100, Gregory CLEMENT wrote:

> > We haven't used this solution on Marvell Armada 32-bits SoCs, so there
> > needs to be a discussion on whether we want to go in this direction for
> > the 64 bits SoCs.
> 
> At first view using the label helps to have simpler dts files.
> 
> Is there any cons by using it?

The only minor drawback from my point of view is that you don't see
where in the hierarchy the device you're enabling is. But it's really a
minor drawback and not everybody agrees that it is actually a drawback.

So I'm fine.

> I agree that converting the Marvell Armada 32-bits SoCs would produce a
> lot of churn. But if some binding are common there is no file at all are
> in common, so we could use this solution for the 64 bits SoCs only.

Yes, we could. I'm fine with it. I was merely pointing out that it is
moving away from our 32 bits way of doing things.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1364163

> > I agree that converting the Marvell Armada 32-bits SoCs would produce a
> > lot of churn. But if some binding are common there is no file at all are
> > in common, so we could use this solution for the 64 bits SoCs only.
> 
> Yes, we could. I'm fine with it. I was merely pointing out that it is
> moving away from our 32 bits way of doing things.

Sebastian spent a while converting dove and kirkwood to this
scheme. Most boards have i2c, nand, eth, and mdio properties
represented link this.

There are no many 64 bit boards, so now is the time to make the
change...

	Andrew

[toc] | [prev] | [next] | [standalone]

#1364176

On Thu, Mar 24, 2016 at 02:37:23PM +0100, Andrew Lunn wrote:
> > > I agree that converting the Marvell Armada 32-bits SoCs would produce a
> > > lot of churn. But if some binding are common there is no file at all are
> > > in common, so we could use this solution for the 64 bits SoCs only.
> > 
> > Yes, we could. I'm fine with it. I was merely pointing out that it is
> > moving away from our 32 bits way of doing things.
> 
> Sebastian spent a while converting dove and kirkwood to this
> scheme. Most boards have i2c, nand, eth, and mdio properties
> represented link this.
> 
> There are no many 64 bit boards, so now is the time to make the
> change...

Agreed.

thx,

Jason.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web