[PATCHv3 0/6] ARM: imx: Add Freescale LS1021A SoC and board support

[PATCHv3 0/6] ARM: imx: Add Freescale LS1021A SoC and board support

[Jingchang Lu]

This series contain the support for Freescale LS1021A CPU and LS1021A-QDS
and LS1021A-TWR board.

The LS1021A SoC combines two ARM Cortex-A7 cores that have been optimized
for high reliability and pack the highest level of integration available
for sub-3W embedded communications processors and with a comprehensive
enablement model focused on ease of programmability.

The LS1021A SoC shares IPs with i.MX family, Vybrid family and Freescale
PowerPC platform. 

For the detail information about LS1021A SoC, please refer to the RM doc.

---
changes in v3:
rewrite scfg and dcfg binding doc description.
remove sai related node leaving to the driver support.

changes in v2:
remove unused nodes.
wakeup the secondary core by IPI call to u-boot standby procedure. 
add dt-bindings for LS1021A SoC and platform gerenal configuration nodes.

----------------------------------------------------------------
Jingchang Lu (6):
	ARM: dts: Add SoC level device tree support for LS1021A
	ARM: dts: Add initial LS1021A QDS board dts support
	ARM: dts: Add initial LS1021A TWR board dts support
	dt-bindings: arm: add Freescale LS1021A SoC device tree binding
	ARM: imx: Add initial support for Freescale LS1021A
	ARM: imx: Add Freescale LS1021A SMP support

 Documentation/devicetree/bindings/arm/fsl.txt |  38 +++
 arch/arm/boot/dts/Makefile                    |   2 +
 arch/arm/boot/dts/ls1021a-qds.dts             | 285 +++++++++++++++++++++
 arch/arm/boot/dts/ls1021a-twr.dts             | 117 +++++++++
 arch/arm/boot/dts/ls1021a.dtsi                | 670 ++++++++++++++++++++++++++++++++++++++++++++++++++
 arch/arm/mach-imx/Kconfig                     |  14 ++
 arch/arm/mach-imx/Makefile                    |   4 +-
 arch/arm/mach-imx/common.h                    |   1 +
 arch/arm/mach-imx/mach-ls1021a.c              |  34 +++
 arch/arm/mach-imx/platsmp.c                   |  32 +++
 10 files changed, 1205 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts
 create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts
 create mode 100644 arch/arm/boot/dts/ls1021a.dtsi
 create mode 100644 arch/arm/mach-imx/mach-ls1021a.c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

Add Freescale LS1021A SoC device tree support

Signed-off-by: Nikhil Badola <nikhil.badola-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Chenhui Zhao <chenhui.zhao-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Suresh Gupta <suresh.gupta-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Shaveta Leekha <shaveta-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Ruchika Gupta <ruchika.gupta-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Chao Fu <b44548-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jingchang Lu <jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 arch/arm/boot/dts/ls1021a.dtsi | 670 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 670 insertions(+)
 create mode 100644 arch/arm/boot/dts/ls1021a.dtsi

diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
new file mode 100644
index 0000000..bc6ac30
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -0,0 +1,670 @@
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * 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 "skeleton64.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	compatible = "fsl,ls1021a";
+	interrupt-parent = <&gic>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &lpuart0;
+		serial1 = &lpuart1;
+		serial2 = &lpuart2;
+		serial3 = &lpuart3;
+		serial4 = &lpuart4;
+		serial5 = &lpuart5;
+		ethernet0 = &enet0;
+		ethernet1 = &enet1;
+		ethernet2 = &enet2;
+		sysclk = &sysclk;
+	};
+
+	memory@80000000 {
+		device_type = "memory";
+		reg = <0x0 0x80000000 0x0 0x20000000>;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@f00 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0xf00>;
+		};
+
+		cpu@f01 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0xf01>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupts = 	<GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>,
+				<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_LOW)>;
+	};
+
+	pmu {
+		compatible = "arm,cortex-a7-pmu";
+		interrupts = <GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+				<GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		interrupt-parent = <&gic>;
+		ranges;
+
+		gic: interrupt-controller@1400000 {
+			compatible = "arm,cortex-a7-gic";
+			#interrupt-cells = <3>;
+			interrupt-controller;
+			reg = <0x0 0x1401000 0x0 0x1000>,
+				<0x0 0x1402000 0x0 0x1000>,
+				<0x0 0x1404000 0x0 0x2000>,
+				<0x0 0x1406000 0x0 0x2000>;
+			interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+
+		};
+
+		ifc: ifc@1530000 {
+			compatible = "fsl,ifc", "simple-bus";
+			reg = <0x0 0x1530000 0x0 0x10000>;
+			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		dcfg: dcfg@1ee0000 {
+			compatible = "fsl,ls1021a-dcfg";
+			reg = <0x0 0x1ee0000 0x0 0x10000>;
+		};
+
+		esdhc: esdhc@1560000 {
+			compatible = "fsl,esdhc";
+			reg = <0x0 0x1560000 0x0 0x10000>;
+			interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			voltage-ranges = <1800 1800 3300 3300>;
+			sdhci,auto-cmd12;
+			big-endian;
+			bus-width = <4>;
+			status = "disabled";
+		};
+
+		scfg: scfg@1570000 {
+			compatible = "fsl,ls1021a-scfg";
+			reg = <0x0 0x1570000 0x0 0x10000>;
+		};
+
+		crypto: crypto@1700000 {
+			compatible = "fsl,sec-v5.3", "fsl,sec-v5.0", "fsl,sec-v4.0";
+			fsl,sec-era = <4>;
+			#address-cells = <1>;
+			#size-cells = <1>;
+			reg		 = <0x0 0x1700000 0x0 0x100000>;
+			ranges		 = <0x0 0x0 0x1700000 0x100000>;
+			interrupts	 = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+
+			sec_jr0: jr@10000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x10000 0x10000>;
+				interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr1: jr@20000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x20000 0x10000>;
+				interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr2: jr@30000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x30000 0x10000>;
+				interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+			sec_jr3: jr@40000 {
+				compatible = "fsl,sec-v5.3-job-ring",
+				     "fsl,sec-v5.0-job-ring",
+				     "fsl,sec-v4.0-job-ring";
+				reg = <0x40000 0x10000>;
+				interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		clockgen: clocking@1ee1000 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <0x0 0x0 0x1ee1000 0x10000>;
+
+			sysclk: sysclk {
+				compatible = "fixed-clock";
+				#clock-cells = <0>;
+				clock-frequency = <100000000>;
+				clock-output-names = "sysclk";
+			};
+
+			cga_pll1: pll1@800 {
+				compatible = "fsl,qoriq-core-pll-2.0";
+				#clock-cells = <1>;
+				reg = <0x800 0x10>;
+				clocks = <&sysclk>;
+				clock-output-names = "cga-pll1", "cga-pll1-div2",
+						"cga-pll1-div3", "cga-pll1-div4";
+			};
+
+			platform_clk: pll@c00 {
+				compatible = "fsl,qoriq-core-pll-2.0";
+				#clock-cells = <1>;
+				reg = <0xc00 0x10>;
+				clocks = <&sysclk>;
+				clock-output-names = "platform-clk", "platform-clk-div2";
+			};
+
+			cluster1_clk: clk0c0@0 {
+				compatible = "fsl,qoriq-core-mux-2.0";
+				#clock-cells = <1>;
+				reg = <0x0 0x10>;
+				clock-names = "pll1cga", "pll1cga-div2";
+				clocks = <&cga_pll1 0>, <&cga_pll1 2>;
+				clock-output-names = "cluster1-clk";
+
+			};
+		};
+
+		dspi0: dspi@2100000 {
+			compatible = "fsl,vf610-dspi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2100000 0x0 0x10000>;
+			interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "dspi";
+			clocks = <&platform_clk 1>;
+			spi-num-chipselects = <5>;
+			big-endian;
+			status = "disabled";
+		};
+
+		dspi1: dspi@2110000 {
+			compatible = "fsl,vf610-dspi";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2110000 0x0 0x10000>;
+			interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "dspi";
+			clocks = <&platform_clk 1>;
+			spi-num-chipselects = <5>;
+			big-endian;
+			status = "disabled";
+		};
+
+		i2c0: i2c@2180000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2180000 0x0 0x10000>;
+			interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		i2c1: i2c@2190000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2190000 0x0 0x10000>;
+			interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		i2c2: i2c@21a0000 {
+			compatible = "fsl,vf610-i2c";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x21a0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "i2c";
+			clocks = <&platform_clk 1>;
+			status = "disabled";
+		};
+
+		uart0: serial@21c0500 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21c0500 0x0 0x100>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart1: serial@21c0600 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21c0600 0x0 0x100>;
+			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart2: serial@21d0500 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21d0500 0x0 0x100>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		uart3: serial@21d0600 {
+			compatible = "fsl,16550-FIFO64", "ns16550a";
+			reg = <0x0 0x21d0600 0x0 0x100>;
+			interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+			clock-frequency = <0>;
+			fifo-size = <15>;
+			status = "disabled";
+		};
+
+		lpuart0: serial@2950000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2950000 0x0 0x1000>;
+			interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&sysclk>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart1: serial@2960000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2960000 0x0 0x1000>;
+			interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart2: serial@2970000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2970000 0x0 0x1000>;
+			interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart3: serial@2980000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2980000 0x0 0x1000>;
+			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart4: serial@2990000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x2990000 0x0 0x1000>;
+			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		lpuart5: serial@29a0000 {
+			compatible = "fsl,ls1021a-lpuart";
+			reg = <0x0 0x29a0000 0x0 0x1000>;
+			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "ipg";
+			status = "disabled";
+		};
+
+		ftm0_1: ftm0_1@29d0000 {
+			compatible = "fsl,ftm-timer";
+			reg = <0x0 0x29d0000 0x0 0x10000>,
+				<0x0 0x29e0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm-evt", "ftm-src",
+			        "ftm-evt-counter-en", "ftm-src-counter-en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+			       <&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm3: ftm@2a00000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a00000 0x0 0x10000>;
+			interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm6: ftm@2a30000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a30000 0x0 0x10000>;
+			interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		pwm7: ftm@2a40000 {
+			compatible = "fsl,vf610-ftm-pwm";
+			#pwm-cells = <3>;
+			reg = <0x0 0x2a40000 0x0 0x10000>;
+			interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>;
+			clock-names = "ftm_sys", "ftm_ext",
+				"ftm_fix", "ftm_cnt_clk_en";
+			clocks = <&platform_clk 1>, <&platform_clk 1>,
+				<&platform_clk 1>, <&platform_clk 1>;
+			big-endian;
+			status = "disabled";
+		};
+
+		wdog0: wdog@2ad0000 {
+			compatible = "fsl,imx21-wdt";
+			reg = <0x0 0x2ad0000 0x0 0x10000>;
+			interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "wdog";
+			big-endian;
+		};
+
+		sai1: sai@2b50000 {
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0x2b50000 0x0 0x10000>;
+			interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "sai";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 47>,
+				<&edma0 1 46>;
+			big-endian-regs;
+			status = "disabled";
+		};
+
+		sai2: sai@2b60000 {
+			compatible = "fsl,vf610-sai";
+			reg = <0x0 0x2b60000 0x0 0x10000>;
+			interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&platform_clk 1>;
+			clock-names = "sai";
+			dma-names = "tx", "rx";
+			dmas = <&edma0 1 45>,
+				<&edma0 1 44>;
+			big-endian-regs;
+			status = "disabled";
+		};
+
+		edma0: edma@2c00000 {
+			#dma-cells = <2>;
+			compatible = "fsl,vf610-edma";
+			reg = <0x0 0x2c00000 0x0 0x10000>,
+				<0x0 0x2c10000 0x0 0x10000>,
+				<0x0 0x2c20000 0x0 0x10000>;
+			interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-names = "edma-tx", "edma-err";
+			dma-channels = <32>;
+			big-endian;
+			clock-names = "dmamux0", "dmamux1";
+			clocks = <&platform_clk 1>,
+				<&platform_clk 1>;
+		};
+
+		mdio0: mdio@2d24000 {
+			compatible = "gianfar";
+			device_type = "mdio";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0 0x2d24000 0x0 0x4000>;
+		};
+
+		enet0: ethernet@2d10000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d10000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		enet1: ethernet@2d50000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d50000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>;
+			};
+
+		};
+
+		enet2: ethernet@2d90000 {
+			compatible = "fsl,etsec2";
+			device_type = "network";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			interrupt-parent = <&gic>;
+			model = "eTSEC";
+			fsl,dma-endian-le;
+			fsl,num_rx_queues = <0x1>;
+			fsl,num_tx_queues = <0x1>;
+			ranges;
+
+			queue-group@0 {
+				#address-cells = <1>;
+				#size-cells = <1>;
+				reg = <0x0 0x2d90000 0x0 0x8000>;
+				fsl,rx-bit-map = <0xff>;
+				fsl,tx-bit-map = <0xff>;
+				interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 158 IRQ_TYPE_LEVEL_HIGH>,
+					<GIC_SPI 159 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		usb@8600000 {
+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
+			reg = <0x0 0x8600000 0x0 0x1000>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
+			dr_mode = "host";
+			phy_type = "ulpi";
+		};
+
+		usb@3100000 {
+			compatible = "fsl,fsl-dwc3";
+			#address-cells = <2>;
+			#size-cells = <2>;
+			ranges;
+
+			dwc3 {
+				compatible = "snps,dwc3";
+				reg = <0x0 0x3100000 0x0 0x10000>;
+				interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
+				dr_mode = "host";
+				maximum-speed = "high-speed";
+			};
+		};
+	};
+
+	dcsr {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "fsl,dcsr", "simple-bus";
+
+		ranges = <0x0 0x0 0x20000000 0x1000000>;
+
+		dcsr-epu@0 {
+			compatible = "fsl,ls1021a-dcsr-epu";
+			reg = <0x0 0x10000>;
+		};
+
+		dcsr-gdi@100000 {
+			compatible = "fsl,ls1021a-dcsr-gdi";
+			reg = <0x100000 0x10000>;
+		};
+
+		dcsr-dddi@120000 {
+			compatible = "fsl,ls1021a-dcsr-dddi";
+			reg = <0x120000 0x10000>;
+		};
+
+		dcsr-dcfg@220000 {
+			compatible = "fsl,ls1021a-dcsr-dcfg";
+			reg = <0x220000 0x1000>;
+		};
+
+		dcsr-clock@221000 {
+			compatible = "fsl,ls1021a-dcsr-clock";
+			reg = <0x221000 0x1000>;
+		};
+
+		dcsr-rcpm@222000 {
+			compatible = "fsl,ls1021a-dcsr-rcpm";
+			reg = <0x222000 0x1000 0x223000 0x1000>;
+		};
+
+		dcsr-ccp@225000 {
+			compatible = "fsl,ls1021a-dcsr-ccp";
+			reg = <0x225000 0x1000>;
+		};
+
+		dcsr-fusectrl@226000 {
+			compatible = "fsl,ls1021a-dcsr-fusectrl";
+			reg = <0x226000 0x1000>;
+		};
+
+		dcsr-dap@300000 {
+			compatible = "fsl,ls1021a-dcsr-dap";
+			reg = <0x300000 0x10000>;
+		};
+
+		dcsr-cstf@350000 {
+			compatible = "fsl,ls1021a-dcsr-cstf";
+			reg = <0x350000 0x1000 0x3a7000 0x1000>;
+		};
+
+		dcsr-a7rom@360000 {
+			compatible = "fsl,ls1021a-dcsr-a7rom";
+			reg = <0x360000 0x10000>;
+		};
+
+		dcsr-a7cpu@370000 {
+			compatible = "fsl,ls1021a-dcsr-a7cpu";
+			reg = <0x370000 0x8000>;
+		};
+
+		dcsr-a7cti@378000 {
+			compatible = "fsl,ls1021a-dcsr-a7cti";
+			reg = <0x378000 0x4000>;
+		};
+
+		dcsr-etm@37c000 {
+			compatible = "fsl,ls1021a-dcsr-etm";
+			reg = <0x37c000 0x1000 0x37d000 0x3000>;
+		};
+
+		dcsr-hugorom@3a0000 {
+			compatible = "fsl,ls1021a-dcsr-hugorom";
+			reg = <0x3a0000 0x1000>;
+		};
+
+		dcsr-etf@3a1000 {
+			compatible = "fsl,ls1021a-dcsr-etf";
+			reg = <0x3a1000 0x1000 0x3a2000 0x1000>;
+		};
+
+		dcsr-etr@3a3000 {
+			compatible = "fsl,ls1021a-dcsr-etr";
+			reg = <0x3a3000 0x1000>;
+		};
+
+		dcsr-cti@3a4000 {
+			compatible = "fsl,ls1021a-dcsr-cti";
+			reg = <0x3a4000 0x1000 0x3a5000 0x1000 0x3a6000 0x1000>;
+		};
+
+		dcsr-atbrepl@3a8000 {
+			compatible = "fsl,ls1021a-dcsr-atbrepl";
+			reg = <0x3a8000 0x1000>;
+		};
+
+		dcsr-tsgen-ctrl@3a9000 {
+			compatible = "fsl,ls1021a-dcsr-tsgen-ctrl";
+			reg = <0x3a9000 0x1000>;
+		};
+
+		dcsr-tsgen-read@3aa000 {
+			compatible = "fsl,ls1021a-dcsr-tsgen-read";
+			reg = <0x3aa000 0x1000>;
+		};
+	};
+};
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Arnd Bergmann]

On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:

> +		dcfg: dcfg@1ee0000 {
> +			compatible = "fsl,ls1021a-dcfg";
> +			reg = <0x0 0x1ee0000 0x0 0x10000>;
> +		};
> +		scfg: scfg@1570000 {
> +			compatible = "fsl,ls1021a-scfg";
> +			reg = <0x0 0x1570000 0x0 0x10000>;
> +		};

Should these be marked as 'compatible = "syscon"' as well?

> +	dcsr {
> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		compatible = "fsl,dcsr", "simple-bus";
> +
> +		ranges = <0x0 0x0 0x20000000 0x1000000>;
> +
> +		dcsr-epu@0 {
> +			compatible = "fsl,ls1021a-dcsr-epu";
> +			reg = <0x0 0x10000>;
> +		};

The binding document only specifies a generic "fsl,dcsr-epu", not
"fsl,ls1021a-dcsr-epu". It also mandates that "interrupts"
must be present and contain three interrupt lines.

Please fix either the DT or the binding, so they match.	

> +		dcsr-gdi@100000 {
> +			compatible = "fsl,ls1021a-dcsr-gdi";
> +			reg = <0x100000 0x10000>;
> +		};
> +
> +		dcsr-dddi@120000 {
> +			compatible = "fsl,ls1021a-dcsr-dddi";
> +			reg = <0x120000 0x10000>;
> +		};
> +
> +		dcsr-dcfg@220000 {
> +			compatible = "fsl,ls1021a-dcsr-dcfg";
> +			reg = <0x220000 0x1000>;
> +		};
> +
> +		dcsr-clock@221000 {
> +			compatible = "fsl,ls1021a-dcsr-clock";
> +			reg = <0x221000 0x1000>;
> +		};

None of these are part of the dcsr.txt binding.

> +		dcsr-rcpm@222000 {
> +			compatible = "fsl,ls1021a-dcsr-rcpm";
> +			reg = <0x222000 0x1000 0x223000 0x1000>;
> +		};

Missing generic fsl,dcsr-rcpm compatible value again.

> +		dcsr-ccp@225000 {
> +			compatible = "fsl,ls1021a-dcsr-ccp";
> +			reg = <0x225000 0x1000>;
> +		};

I'm not checking any devices below this one, I assume they are mostly
incomplete, so please go through the whole list and make sure they
all match the documentation.
I can't really find any code using the dcsr in Linux. Is there
an out of tree driver that you plan to submit?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2966 bytes --]


>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Tuesday, September 09, 2014 7:50 PM
>To: linux-arm-kernel@lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree@vger.kernel.org;
>Zhao Chenhui-B35336; Fu Chao-B44548; Leekha Shaveta-B20052; Gupta Suresh-
>B42813; Sharma Bhupesh-B45370; Xiubo Li-B47053; Gupta Ruchika-R66431; Lu
>Jingchang-B35083; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
>
>> +		dcfg: dcfg@1ee0000 {
>> +			compatible = "fsl,ls1021a-dcfg";
>> +			reg = <0x0 0x1ee0000 0x0 0x10000>;
>> +		};
>> +		scfg: scfg@1570000 {
>> +			compatible = "fsl,ls1021a-scfg";
>> +			reg = <0x0 0x1570000 0x0 0x10000>;
>> +		};
>
>Should these be marked as 'compatible = "syscon"' as well?
Yes, some driver may reference them by the syscon driver, 
I will add the "syscon" compatible for driver has another reference way, thanks.

>
>> +	dcsr {
>> +		#address-cells = <1>;
>> +		#size-cells = <1>;
>> +		compatible = "fsl,dcsr", "simple-bus";
>> +
>> +		ranges = <0x0 0x0 0x20000000 0x1000000>;
>> +
>> +		dcsr-epu@0 {
>> +			compatible = "fsl,ls1021a-dcsr-epu";
>> +			reg = <0x0 0x10000>;
>> +		};
>
>The binding document only specifies a generic "fsl,dcsr-epu", not
>"fsl,ls1021a-dcsr-epu". It also mandates that "interrupts"
>must be present and contain three interrupt lines.
>
>Please fix either the DT or the binding, so they match.
>
>> +		dcsr-gdi@100000 {
>> +			compatible = "fsl,ls1021a-dcsr-gdi";
>> +			reg = <0x100000 0x10000>;
>> +		};
>> +
>> +		dcsr-dddi@120000 {
>> +			compatible = "fsl,ls1021a-dcsr-dddi";
>> +			reg = <0x120000 0x10000>;
>> +		};
>> +
>> +		dcsr-dcfg@220000 {
>> +			compatible = "fsl,ls1021a-dcsr-dcfg";
>> +			reg = <0x220000 0x1000>;
>> +		};
>> +
>> +		dcsr-clock@221000 {
>> +			compatible = "fsl,ls1021a-dcsr-clock";
>> +			reg = <0x221000 0x1000>;
>> +		};
>
>None of these are part of the dcsr.txt binding.
>
>> +		dcsr-rcpm@222000 {
>> +			compatible = "fsl,ls1021a-dcsr-rcpm";
>> +			reg = <0x222000 0x1000 0x223000 0x1000>;
>> +		};
>
>Missing generic fsl,dcsr-rcpm compatible value again.
>
>> +		dcsr-ccp@225000 {
>> +			compatible = "fsl,ls1021a-dcsr-ccp";
>> +			reg = <0x225000 0x1000>;
>> +		};
>
>I'm not checking any devices below this one, I assume they are mostly
>incomplete, so please go through the whole list and make sure they all
>match the documentation.
>I can't really find any code using the dcsr in Linux. Is there an out of
>tree driver that you plan to submit?
>
>	Arnd

I will remove these dcsr related nodes and leave them to be added later when
All ok. Thanks.


Best Regards,
Jingchang
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Arnd Bergmann]

On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
> +       aliases {
> +               serial0 = &lpuart0;
> +               serial1 = &lpuart1;
> +               serial2 = &lpuart2;
> +               serial3 = &lpuart3;
> +               serial4 = &lpuart4;
> +               serial5 = &lpuart5;
> +               ethernet0 = &enet0;
> +               ethernet1 = &enet1;
> +               ethernet2 = &enet2;
> +               sysclk = &sysclk;
> +       };
> +
> +       memory@80000000 {
> +               device_type = "memory";
> +               reg = <0x0 0x80000000 0x0 0x20000000>;
> +       };
> +
> 


One more thing: these should all go into the board specific files.

The installed memory is almost always a property of the board, not the
SoC, and a lot of boards only connect a subset of the serial ports,
or they may have them in a different order.

In particular, you only provide aliases for the six out of the
ten available uarts, which seems arbitrary.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Tuesday, September 09, 2014 7:53 PM
>To: linux-arm-kernel@lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree@vger.kernel.org;
>Zhao Chenhui-B35336; Fu Chao-B44548; Leekha Shaveta-B20052; Gupta Suresh-
>B42813; Sharma Bhupesh-B45370; Xiubo Li-B47053; Gupta Ruchika-R66431; Lu
>Jingchang-B35083; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
>> +       aliases {
>> +               serial0 = &lpuart0;
>> +               serial1 = &lpuart1;
>> +               serial2 = &lpuart2;
>> +               serial3 = &lpuart3;
>> +               serial4 = &lpuart4;
>> +               serial5 = &lpuart5;
>> +               ethernet0 = &enet0;
>> +               ethernet1 = &enet1;
>> +               ethernet2 = &enet2;
>> +               sysclk = &sysclk;
>> +       };
>> +
>> +       memory@80000000 {
>> +               device_type = "memory";
>> +               reg = <0x0 0x80000000 0x0 0x20000000>;
>> +       };
>> +
>>
>
>
>One more thing: these should all go into the board specific files.
>
>The installed memory is almost always a property of the board, not the SoC,
>and a lot of boards only connect a subset of the serial ports, or they may
>have them in a different order.
>
>In particular, you only provide aliases for the six out of the ten
>available uarts, which seems arbitrary.
>
>	Arnd

The memory size info will be fixed up in u-boot before booting the kernel image,
so I add the memory node in the SoC level device tree and keep only one copy. 
The lpuart derives the line number from the node's alias id, 8250 serial driver
doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.
Thanks.

Best Regards,
Jingchang

Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Arnd Bergmann]

On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
> >One more thing: these should all go into the board specific files.
> >
> >The installed memory is almost always a property of the board, not the SoC,
> >and a lot of boards only connect a subset of the serial ports, or they may
> >have them in a different order.
> >
> >In particular, you only provide aliases for the six out of the ten
> >available uarts, which seems arbitrary.
> >
> 
> The memory size info will be fixed up in u-boot before booting the kernel image,
> so I add the memory node in the SoC level device tree and keep only one copy. 

Right. I wonder if it would make sense to just leave a placeholder in there
that does not look like a plausible memory size. I believe the common case today
is that we actually want to have the correct memory size in the board-level
dts file because the boot loader does not change that value. If your boot loader
does it, we probably don't want any default that may confuse users at all,
in particular in the per-soc file.

> The lpuart derives the line number from the node's alias id, 8250 serial driver
> doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.

This is really bad though, for two reasons:

a) you are relying on current behavior of two kernel drivers that we may want to
change in the future. Unfortunately the two drivers don't do this consistently
today, but that's something we should fix in the kernel, not work around in
the hardware description.

b) for the lpuart case, you put a fixed device order in the soc-specific file,
without any guarantee that the board uses just the first x devices rather than
another random subset. The alias values are really meant to to correspond to
how the machine calls things, not how the SoC sees it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Sascha Hauer]

On Thu, Sep 11, 2014 at 12:36:50PM +0200, Arnd Bergmann wrote:
> On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
> > >One more thing: these should all go into the board specific files.
> > >
> > >The installed memory is almost always a property of the board, not the SoC,
> > >and a lot of boards only connect a subset of the serial ports, or they may
> > >have them in a different order.
> > >
> > >In particular, you only provide aliases for the six out of the ten
> > >available uarts, which seems arbitrary.
> > >
> > 
> > The memory size info will be fixed up in u-boot before booting the kernel image,
> > so I add the memory node in the SoC level device tree and keep only one copy. 
> 
> Right. I wonder if it would make sense to just leave a placeholder in there
> that does not look like a plausible memory size.

The placeholder is already in skeleton.dtsi, no need to add it at SoC
level.

> I believe the common case today
> is that we actually want to have the correct memory size in the board-level
> dts file because the boot loader does not change that value. If your boot loader
> does it, we probably don't want any default that may confuse users at all,
> in particular in the per-soc file.
> 
> > The lpuart derives the line number from the node's alias id, 8250 serial driver
> > doesn't rely on it, so only aliases for the lpuart are added, not arbitrary.
> 
> This is really bad though, for two reasons:
> 
> a) you are relying on current behavior of two kernel drivers that we may want to
> change in the future. Unfortunately the two drivers don't do this consistently
> today, but that's something we should fix in the kernel, not work around in
> the hardware description.
> 
> b) for the lpuart case, you put a fixed device order in the soc-specific file,
> without any guarantee that the board uses just the first x devices rather than
> another random subset. The alias values are really meant to to correspond to
> how the machine calls things, not how the SoC sees it.

All i.MX SoCs have the aliases defined how the SoC sees the devices and
i.MX is not alone here.

I know that some people rather like to see the aliases correspond to the
numbers printed on the case or PCB, thus dropping the aliases from the
SoC dtsi and putting them into the board dts instead.

I think both the UART number from the datasheet and the number printed
on the case are valuable informations, we should come up with a way to
express both informations instead of argueing about the meaning of the
'serialx' alias. This shouldn't even be too hard, we could create
multiple aliases for the same device and let udev create links for
all of them.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Sascha Hauer [mailto:s.hauer@pengutronix.de]
>Sent: Thursday, September 11, 2014 7:12 PM
>To: Arnd Bergmann
>Cc: Lu Jingchang-B35083; linux-arm-kernel@lists.infradead.org; Guo Shawn-
>R65073; devicetree@vger.kernel.org; Zhao Chenhui-B35336; Fu Chao-B44548;
>Leekha Shaveta-B20052; Gupta Suresh-B42813; Sharma Bhupesh-B45370; Xiubo
>Li-B47053; Gupta Ruchika-R66431; Badola Nikhil-B46172
>Subject: Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>On Thu, Sep 11, 2014 at 12:36:50PM +0200, Arnd Bergmann wrote:
>> On Thursday 11 September 2014 08:21:58 Jingchang Lu wrote:
>> > >One more thing: these should all go into the board specific files.
>> > >
>> > >The installed memory is almost always a property of the board, not
>> > >the SoC, and a lot of boards only connect a subset of the serial
>> > >ports, or they may have them in a different order.
>> > >
>> > >In particular, you only provide aliases for the six out of the ten
>> > >available uarts, which seems arbitrary.
>> > >
>> >
>> > The memory size info will be fixed up in u-boot before booting the
>> > kernel image, so I add the memory node in the SoC level device tree
>and keep only one copy.
>>
>> Right. I wonder if it would make sense to just leave a placeholder in
>> there that does not look like a plausible memory size.
>
>The placeholder is already in skeleton.dtsi, no need to add it at SoC
>level.
Thanks, I will remove the node in the SoC dtsi and use just that in
the skeleton64.dtsi instead.

>
>> I believe the common case today
>> is that we actually want to have the correct memory size in the
>> board-level dts file because the boot loader does not change that
>> value. If your boot loader does it, we probably don't want any default
>> that may confuse users at all, in particular in the per-soc file.
>>
>> > The lpuart derives the line number from the node's alias id, 8250
>> > serial driver doesn't rely on it, so only aliases for the lpuart are
>added, not arbitrary.
>>
>> This is really bad though, for two reasons:
>>
>> a) you are relying on current behavior of two kernel drivers that we
>> may want to change in the future. Unfortunately the two drivers don't
>> do this consistently today, but that's something we should fix in the
>> kernel, not work around in the hardware description.
>>
>> b) for the lpuart case, you put a fixed device order in the
>> soc-specific file, without any guarantee that the board uses just the
>> first x devices rather than another random subset. The alias values
>> are really meant to to correspond to how the machine calls things, not
>how the SoC sees it.
>
>All i.MX SoCs have the aliases defined how the SoC sees the devices and
>i.MX is not alone here.
>
>I know that some people rather like to see the aliases correspond to the
>numbers printed on the case or PCB, thus dropping the aliases from the SoC
>dtsi and putting them into the board dts instead.
>
>I think both the UART number from the datasheet and the number printed on
>the case are valuable informations, we should come up with a way to
>express both informations instead of argueing about the meaning of the
>'serialx' alias. This shouldn't even be too hard, we could create multiple
>aliases for the same device and let udev create links for all of them.
>
>Sascha

Then I will keep the only alias for the lpuart to make them working well currently.
Thanks.

Best Regards,
Jingchang

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[nikhil.badola-KZfg59tc24xl57MIdRCFDg]

>-----Original Message-----
>From: Jingchang Lu [mailto:jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org]
>Sent: Tuesday, September 09, 2014 2:42 PM
>To: Guo Shawn-R65073
>Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Lu
>Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta Suresh-
>B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-
>B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
>
>From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>
>Add Freescale LS1021A SoC device tree support
>+
>+		usb@8600000 {
>+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
>+			reg = <0x0 0x8600000 0x0 0x1000>;
>+			#address-cells = <1>;
>+			#size-cells = <0>;
>+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
>+			dr_mode = "host";
>+			phy_type = "ulpi";
>+		};
>+

Please remove following from the above node :  
			#address-cells = <1>;
			#size-cells = <0>;

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Badola Nikhil-B46172
>Sent: Thursday, September 11, 2014 6:11 PM
>To: Lu Jingchang-B35083; Guo Shawn-R65073
>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
>Jingchang-B35083; Zhao Chenhui-B35336; Gupta Suresh-B42813; Leekha
>Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-B45370; Fu Chao-
>B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>>-----Original Message-----
>>From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
>>Sent: Tuesday, September 09, 2014 2:42 PM
>>To: Guo Shawn-R65073
>>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
>>Lu Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta
>>Suresh- B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma
>>Bhupesh- B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>>Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>>LS1021A
>>
>>From: Jingchang Lu <b35083@freescale.com>
>>
>>Add Freescale LS1021A SoC device tree support
>>+
>>+		usb@8600000 {
>>+			compatible = "fsl-usb2-dr-v2.5", "fsl-usb2-dr";
>>+			reg = <0x0 0x8600000 0x0 0x1000>;
>>+			#address-cells = <1>;
>>+			#size-cells = <0>;
>>+			interrupts = <GIC_SPI 171 IRQ_TYPE_LEVEL_HIGH>;
>>+			dr_mode = "host";
>>+			phy_type = "ulpi";
>>+		};
>>+
>
>Please remove following from the above node :
>			#address-cells = <1>;
>			#size-cells = <0>;

Ok, thanks.



Best Regards,
Jingchang

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[suresh.gupta]

> -----Original Message-----
> From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
> Sent: Tuesday, September 09, 2014 2:42 PM
> To: Guo Shawn-R65073
> Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
> Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta Suresh-
> B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-
> B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
> Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
> 
> From: Jingchang Lu <b35083@freescale.com>
> 
> Add Freescale LS1021A SoC device tree support
> 
> +
> +		usb@3100000 {
> +			compatible = "fsl,fsl-dwc3";
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +			ranges;
> +
> +			dwc3 {
> +				compatible = "snps,dwc3";
> +				reg = <0x0 0x3100000 0x0 0x10000>;
> +				interrupts = <GIC_SPI 93
> IRQ_TYPE_LEVEL_HIGH>;
> +				dr_mode = "host";
> +				maximum-speed = "high-speed";
> +			};
> +		};
> +	};
> +
> +
[SuresH]  Can you please pick this node form ls1-linux -> ls1-dev branch
This node should look like


	usb3@3100000 {
                        compatible = "snps,dwc3";
                        reg = <0x0 0x3100000 0x0 0x10000>;
                        interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
                        dr_mode = "host";
                };

RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Gupta Suresh-B42813
>Sent: Thursday, September 11, 2014 4:42 PM
>To: Lu Jingchang-B35083; Guo Shawn-R65073
>Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org; Lu
>Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Leekha
>Shaveta-B20052; Gupta Ruchika-R66431; Sharma Bhupesh-B45370; Fu Chao-
>B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>Subject: RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>LS1021A
>
>
>
>> -----Original Message-----
>> From: Jingchang Lu [mailto:jingchang.lu@freescale.com]
>> Sent: Tuesday, September 09, 2014 2:42 PM
>> To: Guo Shawn-R65073
>> Cc: linux-arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
>> Lu Jingchang-B35083; Badola Nikhil-B46172; Zhao Chenhui-B35336; Gupta
>> Suresh- B42813; Leekha Shaveta-B20052; Gupta Ruchika-R66431; Sharma
>> Bhupesh- B45370; Fu Chao-B44548; Xiubo Li-B47053; Lu Jingchang-B35083
>> Subject: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for
>> LS1021A
>>
>> From: Jingchang Lu <b35083@freescale.com>
>>
>> Add Freescale LS1021A SoC device tree support
>>
>> +
>> +		usb@3100000 {
>> +			compatible = "fsl,fsl-dwc3";
>> +			#address-cells = <2>;
>> +			#size-cells = <2>;
>> +			ranges;
>> +
>> +			dwc3 {
>> +				compatible = "snps,dwc3";
>> +				reg = <0x0 0x3100000 0x0 0x10000>;
>> +				interrupts = <GIC_SPI 93
>> IRQ_TYPE_LEVEL_HIGH>;
>> +				dr_mode = "host";
>> +				maximum-speed = "high-speed";
>> +			};
>> +		};
>> +	};
>> +
>> +
>[SuresH]  Can you please pick this node form ls1-linux -> ls1-dev branch
>This node should look like
>
>
>	usb3@3100000 {
>                        compatible = "snps,dwc3";
>                        reg = <0x0 0x3100000 0x0 0x10000>;
>                        interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
>                        dr_mode = "host";
>                };

Ok, I will update it in the next version.

Best Regards,
Jingchang

[PATCHv3 2/6] ARM: dts: Add initial LS1021A QDS board dts support

[Jingchang Lu]

From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

Signed-off-by: Alison Wang <alison.wang-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Chao Fu <B44548-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jason Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jaiprakash Singh <b44839-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jingchang Lu <jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/ls1021a-qds.dts | 285 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 286 insertions(+)
 create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 75c7b74..d2609c4 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -245,6 +245,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6q-tx6q-1110.dtb \
 	imx6sl-evk.dtb \
 	imx6sx-sdb.dtb \
+	ls1021a-qds.dtb \
 	vf610-colibri-eval-v3.dtb \
 	vf610-cosmic.dtb \
 	vf610-twr.dtb
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
new file mode 100644
index 0000000..a0a95f5
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -0,0 +1,285 @@
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "ls1021a.dtsi"
+
+/ {
+	model = "LS1021A QDS Board";
+
+	aliases {
+		enet0_rgmii_phy = &rgmii_phy1;
+		enet1_rgmii_phy = &rgmii_phy2;
+		enet2_rgmii_phy = &rgmii_phy3;
+		enet0_sgmii_phy = &sgmii_phy1c;
+		enet1_sgmii_phy = &sgmii_phy1d;
+	};
+
+	soc {
+		leds {
+			compatible = "pwm-leds";
+			led0 {
+				label = "led0";
+				pwms = <&pwm3 0 150000 0>;
+				max-brightness = <100>;
+			};
+			led1 {
+				label = "led1";
+				pwms = <&pwm3 1 150000 0>;
+				max-brightness = <100>;
+			};
+			led2 {
+				label = "led2";
+				pwms = <&pwm3 2 150000 0>;
+				max-brightness = <100>;
+			};
+			led3 {
+				label = "led3";
+				pwms = <&pwm3 3 150000 0>;
+				max-brightness = <100>;
+			};
+			led4 {
+				label = "led4";
+				pwms = <&pwm3 4 150000 0>;
+				max-brightness = <100>;
+			};
+			led5 {
+				label = "led5";
+				pwms = <&pwm3 5 150000 0>;
+				max-brightness = <100>;
+			};
+			led6 {
+				label = "led6";
+				pwms = <&pwm3 6 150000 0>;
+				max-brightness = <100>;
+			};
+			led7 {
+				label = "led7";
+				pwms = <&pwm3 7 150000 0>;
+				max-brightness = <100>;
+			};
+		};
+	};
+};
+
+&dspi0 {
+	bus-num = <0>;
+	status = "okay";
+
+	dspiflash: at45db021d@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "atmel,at45db021d", "atmel,at45", "atmel,dataflash";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		reg = <0>;
+	};
+};
+
+&enet0 {
+	tbi-handle = <&tbi0>;
+	phy-handle = <&sgmii_phy1c>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet1 {
+	tbi-handle = <&tbi0>;
+	phy-handle = <&sgmii_phy1d>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet2 {
+	phy-handle = <&rgmii_phy3>;
+	phy-connection-type = "rgmii-id";
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+	pca9547@77 {
+		compatible = "philips,pca9547";
+		reg = <0x77>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0>;
+
+			rtc@68 {
+				compatible = "dallas,ds3232";
+				reg = <0x68>;
+				interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		i2c@2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x2>;
+
+			ina220@40 {
+				compatible = "ti,ina220";
+				reg = <0x40>;
+				shunt-resistor = <1000>;
+			};
+
+			ina220@41 {
+				compatible = "ti,ina220";
+				reg = <0x41>;
+				shunt-resistor = <1000>;
+			};
+		};
+
+		i2c@3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x3>;
+
+			eeprom@56 {
+				compatible = "at24,24c512";
+				reg = <0x56>;
+			};
+
+			eeprom@57 {
+				compatible = "at24,24c512";
+				reg = <0x57>;
+			};
+
+			adt7461a@4c {
+				compatible = "adt7461a";
+				reg = <0x4c>;
+			};
+		};
+
+		i2c@4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x4>;
+		};
+	};
+};
+
+&ifc {
+	status = "okay";
+	#address-cells = <2>;
+	#size-cells = <1>;
+	/* NOR, NAND Flashes and FPGA on board */
+	ranges = <0x0 0x0 0x0 0x60000000 0x08000000
+		0x2 0x0 0x0 0x7e800000 0x00010000
+		0x3 0x0 0x0 0x7fb00000 0x00000100>;
+
+		nor@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0x0 0x0 0x8000000>;
+			bank-width = <2>;
+			device-width = <1>;
+		};
+
+		nand@2,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,ifc-nand";
+			reg = <0x2 0x0 0x10000>;
+		};
+
+		fpga: board-control@3,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			reg = <0x3 0x0 0x0000100>;
+			bank-width = <1>;
+			device-width = <1>;
+			ranges = <0 3 0 0x100>;
+
+			mdio-mux-emi1 {
+				compatible = "mdio-mux-mmioreg";
+				mdio-parent-bus = <&mdio0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0x54 1>; /* BRDCFG4 */
+				mux-mask = <0xe0>; /* EMI1[2:0] */
+
+				/* Onboard PHYs */
+				ls1021amdio0: mdio@0 {
+					reg = <0>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy1: ethernet-phy@1 {
+						reg = <0x1>;
+					};
+				};
+				ls1021amdio1: mdio@20 {
+					reg = <0x20>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy2: ethernet-phy@2 {
+						reg = <0x2>;
+					};
+				};
+				ls1021amdio2: mdio@40 {
+					reg = <0x40>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy3: ethernet-phy@3 {
+						reg = <0x3>;
+					};
+				};
+				ls1021amdio3: mdio@60 {
+					reg = <0x60>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					sgmii_phy1c: ethernet-phy@1c {
+						reg = <0x1c>;
+					};
+				};
+				ls1021amdio4: mdio@80 {
+					reg = <0x80>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					sgmii_phy1d: ethernet-phy@1d {
+						reg = <0x1d>;
+					};
+				};
+			};
+		};
+};
+
+&lpuart0 {
+	status = "okay";
+};
+
+&mdio0 {
+	tbi0: tbi-phy@8 {
+		reg = <0x8>;
+		device_type = "tbi-phy";
+	};
+};
+
+&pwm3 {
+	status = "okay";
+};
+
+&pwm7 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 4/6] dt-bindings: arm: add Freescale LS1021A SoC device tree binding

[Jingchang Lu]

Signed-off-by: Jingchang Lu <jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 Documentation/devicetree/bindings/arm/fsl.txt | 38 +++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index e935d7d..2e0ba09 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -74,3 +74,41 @@ Required root node properties:
 i.MX6q generic board
 Required root node properties:
     - compatible = "fsl,imx6q";
+
+
+Freescale LS1021A Platform Device Tree Bindings
+------------------------------------------------
+
+Required root node compatible properties:
+  - compatible = "fsl,ls1021a";
+
+Freescale LS1021A SoC-specific Device Tree Bindings
+-------------------------------------------
+
+Freescale SCFG
+  scfg is the supplemental configuration unit, that provides SoC specific
+configuration and status registers for the chip. Such as getting PEX port
+status.
+  Required properties:
+  - compatible: should be "fsl,ls1021a-scfg"
+  - reg: should contain base address and length of SCFG memory-mapped registers
+
+Example:
+	scfg: scfg@1570000 {
+		compatible = "fsl,ls1021a-scfg";
+		reg = <0x0 0x1570000 0x0 0x10000>;
+	};
+
+Freescale DCFG
+  dcfg is the device configuration unit, that provides general purpose
+configuration and status for the device. Such as setting the secondary
+core start address and release the secondary core from holdoff and startup.
+  Required properties:
+  - compatible: should be "fsl,ls1021a-dcfg"
+  - reg : should contain base address and length of DCFG memory-mapped registers
+
+Example:
+	dcfg: dcfg@1ee0000 {
+		compatible = "fsl,ls1021a-dcfg";
+		reg = <0x0 0x1ee0000 0x0 0x10000>;
+	};
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Jingchang Lu]

From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

The LS1021A SoC is a dual-core Cortex-A7 based processor,
this add the initial support for it.

Signed-off-by: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 arch/arm/mach-imx/Kconfig        | 14 ++++++++++++++
 arch/arm/mach-imx/Makefile       |  2 ++
 arch/arm/mach-imx/mach-ls1021a.c | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 49 insertions(+)
 create mode 100644 arch/arm/mach-imx/mach-ls1021a.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 3da9f71..ba7a089 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -651,6 +651,20 @@ config SOC_VF610
 	help
 	  This enable support for Freescale Vybrid VF610 processor.
 
+config SOC_LS1021A
+	bool "Freescale LS1021A support"
+	select CPU_V7
+	select ARM_GIC
+	select CLKSRC_OF
+	select HAVE_ARM_ARCH_TIMER
+	select HAVE_SMP
+	select MIGHT_HAVE_PCI
+	select PCI_DOMAINS if PCI
+	select ZONE_DMA if ARM_LPAE
+
+	help
+	  This enable support for Freescale LS1021A processor.
+
 endif
 
 source "arch/arm/mach-imx/devices/Kconfig"
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index dd674c7..3e12532 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -111,4 +111,6 @@ obj-$(CONFIG_SOC_IMX53) += mach-imx53.o
 
 obj-$(CONFIG_SOC_VF610) += clk-vf610.o mach-vf610.o
 
+obj-$(CONFIG_SOC_LS1021A) += mach-ls1021a.o
+
 obj-y += devices/
diff --git a/arch/arm/mach-imx/mach-ls1021a.c b/arch/arm/mach-imx/mach-ls1021a.c
new file mode 100644
index 0000000..2ffc20f
--- /dev/null
+++ b/arch/arm/mach-imx/mach-ls1021a.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * 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/of_platform.h>
+#include <asm/mach/arch.h>
+
+#include "common.h"
+
+static void __init ls1021a_init_machine(void)
+{
+	mxc_arch_reset_init_dt();
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char *ls1021a_dt_compat[] __initdata = {
+	"fsl,ls1021a",
+	NULL,
+};
+
+DT_MACHINE_START(LS1021A, "Freescale LS1021A")
+#ifdef CONFIG_ZONE_DMA
+	.dma_zone_size	= SZ_128M,
+#endif
+	.init_machine   = ls1021a_init_machine,
+	.dt_compat	= ls1021a_dt_compat,
+	.restart	= mxc_restart,
+MACHINE_END
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Arnd Bergmann]

On Tuesday 09 September 2014 17:12:31 Jingchang Lu wrote:
> +#include "common.h"
> +
> +static void __init ls1021a_init_machine(void)
> +{
> +       mxc_arch_reset_init_dt();
> +       of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char *ls1021a_dt_compat[] __initdata = {
> +       "fsl,ls1021a",
> +       NULL,
> +};

Please don't add any new users of mxc_arch_reset_init_dt(). We now
have infrastructure to register a system-reset handler from the
watchdog driver, so please do that instead, and clean up the
existing users as well.

> +DT_MACHINE_START(LS1021A, "Freescale LS1021A")
> +#ifdef CONFIG_ZONE_DMA
> +       .dma_zone_size  = SZ_128M,
> +#endif
> +       .init_machine   = ls1021a_init_machine,
> +       .dt_compat      = ls1021a_dt_compat,
> +       .restart        = mxc_restart,
> +MACHINE_END

I believe someone recently posted a patch to derive the dma_zone_size
from device tree. Can yo try to find that and see if that will work
for you?

Can you explain what the reason is for needing a DMA zone?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Jingchang Lu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1967 bytes --]

>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Tuesday, September 09, 2014 7:41 PM
>To: linux-arm-kernel@lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; Lu Jingchang-B35083;
>devicetree@vger.kernel.org
>Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale
>LS1021A
>
>On Tuesday 09 September 2014 17:12:31 Jingchang Lu wrote:
>> +#include "common.h"
>> +
>> +static void __init ls1021a_init_machine(void) {
>> +       mxc_arch_reset_init_dt();
>> +       of_platform_populate(NULL, of_default_bus_match_table, NULL,
>> +NULL); }
>> +
>> +static const char *ls1021a_dt_compat[] __initdata = {
>> +       "fsl,ls1021a",
>> +       NULL,
>> +};
>
>Please don't add any new users of mxc_arch_reset_init_dt(). We now have
>infrastructure to register a system-reset handler from the watchdog driver,
>so please do that instead, and clean up the existing users as well.
I just notice the restart_handler support, I will use that instead, thanks.

>
>> +DT_MACHINE_START(LS1021A, "Freescale LS1021A") #ifdef CONFIG_ZONE_DMA
>> +       .dma_zone_size  = SZ_128M,
>> +#endif
>> +       .init_machine   = ls1021a_init_machine,
>> +       .dt_compat      = ls1021a_dt_compat,
>> +       .restart        = mxc_restart,
>> +MACHINE_END
>
>I believe someone recently posted a patch to derive the dma_zone_size from
>device tree. Can yo try to find that and see if that will work for you?
>
>Can you explain what the reason is for needing a DMA zone?
>
>	Arnd
With LPAE enabled on our SoC, we meet the system complaint of
"coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask 0xffffffffffffffff",
and I notice that CONFIG_ZONE_DMA and dma_zone_size is a common resolve for this.
Thanks.



Best Regards,
Jingchang



N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Arnd Bergmann]

On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote:

> >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A")
> >> + #ifdef CONFIG_ZONE_DMA
> >> +       .dma_zone_size  = SZ_128M,
> >> +#endif
> >> +       .init_machine   = ls1021a_init_machine,
> >> +       .dt_compat      = ls1021a_dt_compat,
> >> +       .restart        = mxc_restart,
> >> +MACHINE_END
> >
> >I believe someone recently posted a patch to derive the dma_zone_size from
> >device tree. Can yo try to find that and see if that will work for you?
> >
> >Can you explain what the reason is for needing a DMA zone?
>
> With LPAE enabled on our SoC, we meet the system complaint of
> "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask 0xffffffffffffffff",
> and I notice that CONFIG_ZONE_DMA and dma_zone_size is a common resolve for this.

Ok, I see. The actual point of dma_zone_size however is slightly
different, and I think you should not use it like this. We normally
only use ZONE_DMA if there are devices that have a limitation smaller
than 4GB, and that appear to be the case for your system.

The message you quote is only present in arch/powerpc, so I'm not sure
what symptoms you are actually seeing. Please try removing the
dma_zone_size setting for your platform and report if it works or
what the symptom is if it does not work with the latest kernel.

We definitely need to get this to work out of the box without
a dma_zone_size hack.

Can you describe what the memory layout is of your platform? Can you
have RAM installed above the 4GB physical address boundary? If you
can, are there any devices that are unable to perform DMA into that
memory without the use of an IOMMU?

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Jingchang Lu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2963 bytes --]



>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Wednesday, September 10, 2014 3:42 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073;
>devicetree@vger.kernel.org
>Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale
>LS1021A
>
>On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote:
>
>> >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A")  #ifdef
>> >> +CONFIG_ZONE_DMA
>> >> +       .dma_zone_size  = SZ_128M,
>> >> +#endif
>> >> +       .init_machine   = ls1021a_init_machine,
>> >> +       .dt_compat      = ls1021a_dt_compat,
>> >> +       .restart        = mxc_restart,
>> >> +MACHINE_END
>> >
>> >I believe someone recently posted a patch to derive the dma_zone_size
>> >from device tree. Can yo try to find that and see if that will work for
>you?
>> >
>> >Can you explain what the reason is for needing a DMA zone?
>>
>> With LPAE enabled on our SoC, we meet the system complaint of
>> "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask
>> 0xffffffffffffffff", and I notice that CONFIG_ZONE_DMA and dma_zone_size
>is a common resolve for this.
>
>Ok, I see. The actual point of dma_zone_size however is slightly different,
>and I think you should not use it like this. We normally only use ZONE_DMA
>if there are devices that have a limitation smaller than 4GB, and that
>appear to be the case for your system.
>
>The message you quote is only present in arch/powerpc, so I'm not sure
>what symptoms you are actually seeing. Please try removing the
>dma_zone_size setting for your platform and report if it works or what the
>symptom is if it does not work with the latest kernel.
>
>We definitely need to get this to work out of the box without a
>dma_zone_size hack.
>
>Can you describe what the memory layout is of your platform? Can you have
>RAM installed above the 4GB physical address boundary? If you can, are
>there any devices that are unable to perform DMA into that memory without
>the use of an IOMMU?
>
>	Arnd
Our first LS1021A support is based on kernel-3.12, where when LPAE enabled
it will compare the device's coherent_dma_mask with arm_dma_limit, which is
64-bit 0xffffffffffffffff without CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can
limit the comparison and avoid the warning.
All device can address 32-bit address space on LS1021A, With you comment above,
I remove the dma_zone_size and only reserve the CONFIG_ZONE_DMA On kernel-3.12,
finding all works well, so I will remove the dma_zone_size setting on 3.12. Thanks.

I have a look on latest kernel, finding get_coherent_dma_mask() has limited the mask
to (u64)DMA_BIT_MASK(32), does this mean the CONFIG_ZONE_DMA is not needed for me
here? Thanks.

Best Regards,
Jingchang
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Arnd Bergmann]

On Thursday 11 September 2014 09:53:56 Jingchang Lu wrote:
> >From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> >
> >Ok, I see. The actual point of dma_zone_size however is slightly different,
> >and I think you should not use it like this. We normally only use ZONE_DMA
> >if there are devices that have a limitation smaller than 4GB, and that
> >appear to be the case for your system.
> >
> >The message you quote is only present in arch/powerpc, so I'm not sure
> >what symptoms you are actually seeing. Please try removing the
> >dma_zone_size setting for your platform and report if it works or what the
> >symptom is if it does not work with the latest kernel.
> >
> >We definitely need to get this to work out of the box without a
> >dma_zone_size hack.
> >
> >Can you describe what the memory layout is of your platform? Can you have
> >RAM installed above the 4GB physical address boundary? If you can, are
> >there any devices that are unable to perform DMA into that memory without
> >the use of an IOMMU?
> >
> Our first LS1021A support is based on kernel-3.12, where when LPAE enabled
> it will compare the device's coherent_dma_mask with arm_dma_limit, which is
> 64-bit 0xffffffffffffffff without CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can
> limit the comparison and avoid the warning.
> All device can address 32-bit address space on LS1021A, With you comment above,
> I remove the dma_zone_size and only reserve the CONFIG_ZONE_DMA On kernel-3.12,
> finding all works well, so I will remove the dma_zone_size setting on 3.12. Thanks.

Ok, good.
 
> I have a look on latest kernel, finding get_coherent_dma_mask() has limited the mask
> to (u64)DMA_BIT_MASK(32), does this mean the CONFIG_ZONE_DMA is not needed for me
> here? Thanks.

You only need to enable CONFIG_ZONE_DMA in the case of RAM above the 4GB
boundary. I would suggest you do the same as some of the other platforms
by adding

	select ZONE_DMA if ARM_LPAE

into your Kconfig file. If LPAE is disabled, you know that you won't
need ZONE_DMA.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Thursday, September 11, 2014 6:45 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073;
>devicetree@vger.kernel.org
>Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale
>LS1021A
>
>On Thursday 11 September 2014 09:53:56 Jingchang Lu wrote:
>> >From: Arnd Bergmann [mailto:arnd@arndb.de]
>> >
>> >Ok, I see. The actual point of dma_zone_size however is slightly
>> >different, and I think you should not use it like this. We normally
>> >only use ZONE_DMA if there are devices that have a limitation smaller
>> >than 4GB, and that appear to be the case for your system.
>> >
>> >The message you quote is only present in arch/powerpc, so I'm not
>> >sure what symptoms you are actually seeing. Please try removing the
>> >dma_zone_size setting for your platform and report if it works or
>> >what the symptom is if it does not work with the latest kernel.
>> >
>> >We definitely need to get this to work out of the box without a
>> >dma_zone_size hack.
>> >
>> >Can you describe what the memory layout is of your platform? Can you
>> >have RAM installed above the 4GB physical address boundary? If you
>> >can, are there any devices that are unable to perform DMA into that
>> >memory without the use of an IOMMU?
>> >
>> Our first LS1021A support is based on kernel-3.12, where when LPAE
>> enabled it will compare the device's coherent_dma_mask with
>> arm_dma_limit, which is 64-bit 0xffffffffffffffff without
>> CONFIG_ZONE_DMA, with CONFIG_ZONE_DMA can limit the comparison and avoid
>the warning.
>> All device can address 32-bit address space on LS1021A, With you
>> comment above, I remove the dma_zone_size and only reserve the
>> CONFIG_ZONE_DMA On kernel-3.12, finding all works well, so I will remove
>the dma_zone_size setting on 3.12. Thanks.
>
>Ok, good.
>
>> I have a look on latest kernel, finding get_coherent_dma_mask() has
>> limited the mask to (u64)DMA_BIT_MASK(32), does this mean the
>> CONFIG_ZONE_DMA is not needed for me here? Thanks.
>
>You only need to enable CONFIG_ZONE_DMA in the case of RAM above the 4GB
>boundary. I would suggest you do the same as some of the other platforms
>by adding
>
>	select ZONE_DMA if ARM_LPAE
>
>into your Kconfig file. If LPAE is disabled, you know that you won't need
>ZONE_DMA.
>
>	Arnd

I will do that. Thanks.

Best Regards,
Jingchang

RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A

[Jingchang Lu]

>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd@arndb.de]
>Sent: Wednesday, September 10, 2014 3:42 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel@lists.infradead.org; Guo Shawn-R65073;
>devicetree@vger.kernel.org
>Subject: Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale
>LS1021A
>
>On Wednesday 10 September 2014 03:31:19 Jingchang Lu wrote:
>
>> >> +DT_MACHINE_START(LS1021A, "Freescale LS1021A")  #ifdef
>> >> +CONFIG_ZONE_DMA
>> >> +       .dma_zone_size  = SZ_128M,
>> >> +#endif
>> >> +       .init_machine   = ls1021a_init_machine,
>> >> +       .dt_compat      = ls1021a_dt_compat,
>> >> +       .restart        = mxc_restart,
>> >> +MACHINE_END
>> >
>> >I believe someone recently posted a patch to derive the dma_zone_size
>> >from device tree. Can yo try to find that and see if that will work for
>you?
>> >
>> >Can you explain what the reason is for needing a DMA zone?
>>
>> With LPAE enabled on our SoC, we meet the system complaint of
>> "coherent DMA mask 0xffffffff is smaller than system GFP_DMA mask
>> 0xffffffffffffffff", and I notice that CONFIG_ZONE_DMA and dma_zone_size
>is a common resolve for this.
>
>Ok, I see. The actual point of dma_zone_size however is slightly different,
>and I think you should not use it like this. We normally only use ZONE_DMA
>if there are devices that have a limitation smaller than 4GB, and that
>appear to be the case for your system.
>
>The message you quote is only present in arch/powerpc, so I'm not sure
>what symptoms you are actually seeing. Please try removing the
>dma_zone_size setting for your platform and report if it works or what the
>symptom is if it does not work with the latest kernel.
>
>We definitely need to get this to work out of the box without a
>dma_zone_size hack.
>
>Can you describe what the memory layout is of your platform? Can you have
>RAM installed above the 4GB physical address boundary? If you can, are
>there any devices that are unable to perform DMA into that memory without
>the use of an IOMMU?
>
>	Arnd

Our platform has implemented the Large physical Address Extension, with 40-bit
address space, SDRAM can be above 4GB address, but currently we only use the DDR
controller1 at 0x80000000 below 4GB on our QDS and TWR board. Others is above 4GB
address. PCIE address is also above 4GB address and we are adding support to it.
Thanks.

Best Regards,
Jingchang

[PATCHv3 6/6] ARM: imx: Add Freescale LS1021A SMP support

[Jingchang Lu]

From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

Freescale LS1021A SoCs deploy two cortex-A7 processors,
this adds bring-up support for the secondary core.

Signed-off-by: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
 arch/arm/mach-imx/Makefile       |  2 +-
 arch/arm/mach-imx/common.h       |  1 +
 arch/arm/mach-imx/mach-ls1021a.c |  1 +
 arch/arm/mach-imx/platsmp.c      | 32 ++++++++++++++++++++++++++++++++
 4 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 3e12532..e1e59de 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -90,7 +90,7 @@ obj-$(CONFIG_HAVE_IMX_ANATOP) += anatop.o
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
 obj-$(CONFIG_HAVE_IMX_SRC) += src.o
-ifdef CONFIG_SOC_IMX6
+ifneq ($(CONFIG_SOC_IMX6)$(CONFIG_SOC_LS1021A),)
 AFLAGS_headsmp.o :=-Wa,-march=armv7-a
 obj-$(CONFIG_SMP) += headsmp.o platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
index 1dabf43..c473ca5 100644
--- a/arch/arm/mach-imx/common.h
+++ b/arch/arm/mach-imx/common.h
@@ -157,5 +157,6 @@ static inline void imx_init_l2cache(void) {}
 #endif
 
 extern struct smp_operations imx_smp_ops;
+extern struct smp_operations ls1021a_smp_ops;
 
 #endif
diff --git a/arch/arm/mach-imx/mach-ls1021a.c b/arch/arm/mach-imx/mach-ls1021a.c
index 2ffc20f..d284cdb 100644
--- a/arch/arm/mach-imx/mach-ls1021a.c
+++ b/arch/arm/mach-imx/mach-ls1021a.c
@@ -27,6 +27,7 @@ DT_MACHINE_START(LS1021A, "Freescale LS1021A")
 #ifdef CONFIG_ZONE_DMA
 	.dma_zone_size	= SZ_128M,
 #endif
+	.smp		= smp_ops(ls1021a_smp_ops),
 	.init_machine   = ls1021a_init_machine,
 	.dt_compat	= ls1021a_dt_compat,
 	.restart	= mxc_restart,
diff --git a/arch/arm/mach-imx/platsmp.c b/arch/arm/mach-imx/platsmp.c
index 771bd25..62376f0 100644
--- a/arch/arm/mach-imx/platsmp.c
+++ b/arch/arm/mach-imx/platsmp.c
@@ -16,6 +16,8 @@
 #include <asm/page.h>
 #include <asm/smp_scu.h>
 #include <asm/mach/map.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
 
 #include "common.h"
 #include "hardware.h"
@@ -94,3 +96,33 @@ struct smp_operations  imx_smp_ops __initdata = {
 	.cpu_kill		= imx_cpu_kill,
 #endif
 };
+
+#define DCFG_CCSR_SCRATCHRW1	0x200
+
+static int ls1021a_boot_secondary(unsigned int cpu, struct task_struct *idle)
+{
+	arch_send_wakeup_ipi_mask(cpumask_of(cpu));
+
+	return 0;
+}
+
+static void __init ls1021a_smp_prepare_cpus(unsigned int max_cpus)
+{
+	struct device_node *np;
+	void __iomem *dcfg_base;
+	unsigned long paddr;
+
+	np = of_find_compatible_node(NULL, NULL, "fsl,ls1021a-dcfg");
+	dcfg_base = of_iomap(np, 0);
+	BUG_ON(!dcfg_base);
+
+	paddr = virt_to_phys(secondary_startup);
+	writel_relaxed(cpu_to_be32(paddr), dcfg_base + DCFG_CCSR_SCRATCHRW1);
+
+	iounmap(dcfg_base);
+}
+
+struct smp_operations  ls1021a_smp_ops __initdata = {
+	.smp_prepare_cpus	= ls1021a_smp_prepare_cpus,
+	.smp_boot_secondary	= ls1021a_boot_secondary,
+};
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 3/6] ARM: dts: Add initial LS1021A TWR board dts support

[Jingchang Lu]

Signed-off-by: Chen Lu <B46807@freescale.com>
Signed-off-by: Chao Fu <B44548@freescale.com>
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
 arch/arm/boot/dts/Makefile        |   1 +
 arch/arm/boot/dts/ls1021a-twr.dts | 117 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 118 insertions(+)
 create mode 100755 arch/arm/boot/dts/ls1021a-twr.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d2609c4..a972457 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -246,6 +246,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6sl-evk.dtb \
 	imx6sx-sdb.dtb \
 	ls1021a-qds.dtb \
+	ls1021a-twr.dtb \
 	vf610-colibri-eval-v3.dtb \
 	vf610-cosmic.dtb \
 	vf610-twr.dtb
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
new file mode 100755
index 0000000..1a7e9fb
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -0,0 +1,117 @@
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "ls1021a.dtsi"
+
+/ {
+	model = "LS1021A TWR Board";
+
+	aliases {
+		enet2_rgmii_phy = &rgmii_phy1;
+		enet0_sgmii_phy = &sgmii_phy2;
+		enet1_sgmii_phy = &sgmii_phy0;
+	};
+};
+
+&dspi1 {
+	bus-num = <0>;
+	status = "okay";
+
+	dspiflash: s25fl064k@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "spansion,s25fl064k";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		reg = <0>;
+	};
+};
+
+&enet0 {
+	tbi-handle = <&tbi1>;
+	phy-handle = <&sgmii_phy2>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet1 {
+	tbi-handle = <&tbi1>;
+	phy-handle = <&sgmii_phy0>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet2 {
+	phy-handle = <&rgmii_phy1>;
+	phy-connection-type = "rgmii-id";
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+};
+
+&i2c1 {
+	status = "okay";
+};
+
+&ifc {
+	status = "okay";
+	#address-cells = <2>;
+	#size-cells = <1>;
+	/* NOR, and CPLD on board */
+	ranges = <0x0 0x0 0x0 0x60000000 0x08000000>;
+
+		nor@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0x0 0x0 0x8000000>;
+			bank-width = <2>;
+			device-width = <1>;
+		};
+};
+
+&lpuart0 {
+	status = "okay";
+};
+
+&mdio0 {
+	sgmii_phy0: ethernet-phy@0 {
+		reg = <0x0>;
+	};
+	rgmii_phy1: ethernet-phy@1 {
+		reg = <0x1>;
+	};
+	sgmii_phy2: ethernet-phy@2 {
+		reg = <0x2>;
+	};
+	tbi1: tbi-phy@1f {
+		reg = <0x1f>;
+		device_type = "tbi-phy";
+	};
+};
+
+&pwm6 {
+	status = "okay";
+};
+
+&pwm7 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
-- 
1.8.0

[PATCHv3 2/6] ARM: dts: Add initial LS1021A QDS board dts support

[Jingchang Lu]

From: Jingchang Lu <b35083-KZfg59tc24xl57MIdRCFDg@public.gmane.org>

Signed-off-by: Alison Wang <alison.wang-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Chao Fu <B44548-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jason Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Xiubo Li <Li.Xiubo-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jaiprakash Singh <b44839-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Jingchang Lu <jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
changes in v3:
 remove IFC partition info.

 arch/arm/boot/dts/Makefile        |   3 +-
 arch/arm/boot/dts/ls1021a-qds.dts | 323 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 325 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/ls1021a-qds.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 82f498b..af0d999 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -239,7 +239,8 @@ dtb-$(CONFIG_ARCH_MXC) += \
 	imx6sx-sdb.dtb \
 	vf610-colibri.dtb \
 	vf610-cosmic.dtb \
-	vf610-twr.dtb
+	vf610-twr.dtb \
+	ls1021a-qds.dtb
 dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
 	imx23-olinuxino.dtb \
 	imx23-stmp378x_devb.dtb \
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
new file mode 100644
index 0000000..a3e54a5
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -0,0 +1,323 @@
+/*
+ * Copyright 2013-2014 Freescale Semiconductor, Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "ls1021a.dtsi"
+
+/ {
+	model = "LS1021A QDS Board";
+
+	aliases {
+		enet0_rgmii_phy = &rgmii_phy1;
+		enet1_rgmii_phy = &rgmii_phy2;
+		enet2_rgmii_phy = &rgmii_phy3;
+		enet0_sgmii_phy = &sgmii_phy1c;
+		enet1_sgmii_phy = &sgmii_phy1d;
+	};
+
+	regulators {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		reg_3p3v: regulator@0 {
+			compatible = "regulator-fixed";
+			reg = <0>;
+			regulator-name = "3P3V";
+			regulator-min-microvolt = <3300000>;
+			regulator-max-microvolt = <3300000>;
+			regulator-always-on;
+		};
+	};
+
+	sound {
+		compatible = "fsl,vf610-sgtl5000";
+		simple-audio-card,name = "FSL-VF610-TWR-BOARD";
+		simple-audio-card,routing =
+			"MIC_IN", "Microphone Jack",
+			"Microphone Jack", "Mic Bias",
+			"LINE_IN", "Line In Jack",
+			"Headphone Jack", "HP_OUT",
+			"Speaker Ext", "LINE_OUT";
+
+		simple-audio-card,cpu = <&sai2>;
+
+		simple-audio-card,codec = <&codec>;
+	};
+
+	soc {
+		leds {
+			compatible = "pwm-leds";
+			led0 {
+				label = "led0";
+				pwms = <&pwm3 0 150000 0>;
+				max-brightness = <100>;
+			};
+			led1 {
+				label = "led1";
+				pwms = <&pwm3 1 150000 0>;
+				max-brightness = <100>;
+			};
+			led2 {
+				label = "led2";
+				pwms = <&pwm3 2 150000 0>;
+				max-brightness = <100>;
+			};
+			led3 {
+				label = "led3";
+				pwms = <&pwm3 3 150000 0>;
+				max-brightness = <100>;
+			};
+			led4 {
+				label = "led4";
+				pwms = <&pwm3 4 150000 0>;
+				max-brightness = <100>;
+			};
+			led5 {
+				label = "led5";
+				pwms = <&pwm3 5 150000 0>;
+				max-brightness = <100>;
+			};
+			led6 {
+				label = "led6";
+				pwms = <&pwm3 6 150000 0>;
+				max-brightness = <100>;
+			};
+			led7 {
+				label = "led7";
+				pwms = <&pwm3 7 150000 0>;
+				max-brightness = <100>;
+			};
+		};
+	};
+};
+
+&dspi0 {
+	bus-num = <0>;
+	status = "okay";
+
+	dspiflash: at45db021d@0 {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		compatible = "atmel,at45db021d", "atmel,at45", "atmel,dataflash";
+		spi-max-frequency = <16000000>;
+		spi-cpol;
+		spi-cpha;
+		reg = <0>;
+	};
+};
+
+&enet0 {
+	tbi-handle = <&tbi0>;
+	phy-handle = <&sgmii_phy1c>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet1 {
+	tbi-handle = <&tbi0>;
+	phy-handle = <&sgmii_phy1d>;
+	phy-connection-type = "sgmii";
+	status = "okay";
+};
+
+&enet2 {
+	phy-handle = <&rgmii_phy3>;
+	phy-connection-type = "rgmii-id";
+	status = "okay";
+};
+
+&i2c0 {
+	status = "okay";
+	pca9547@77 {
+		compatible = "philips,pca9547";
+		reg = <0x77>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x0>;
+
+			rtc@68 {
+				compatible = "dallas,ds3232";
+				reg = <0x68>;
+				interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		i2c@2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x2>;
+
+			ina220@40 {
+				compatible = "ti,ina220";
+				reg = <0x40>;
+				shunt-resistor = <1000>;
+			};
+
+			ina220@41 {
+				compatible = "ti,ina220";
+				reg = <0x41>;
+				shunt-resistor = <1000>;
+			};
+		};
+
+		i2c@3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x3>;
+
+			eeprom@56 {
+				compatible = "at24,24c512";
+				reg = <0x56>;
+			};
+
+			eeprom@57 {
+				compatible = "at24,24c512";
+				reg = <0x57>;
+			};
+
+			adt7461a@4c {
+				compatible = "adt7461a";
+				reg = <0x4c>;
+			};
+		};
+
+		i2c@4 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0x4>;
+
+			codec: sgtl5000@0a {
+				compatible = "fsl,sgtl5000";
+				reg = <0x0a>;
+				VDDA-supply = <&reg_3p3v>;
+				VDDIO-supply = <&reg_3p3v>;
+				clocks = <&platform_clk 1>;
+			};
+		};
+	};
+};
+
+&ifc {
+	status = "okay";
+	#address-cells = <2>;
+	#size-cells = <1>;
+	/* NOR, NAND Flashes and FPGA on board */
+	ranges = <0x0 0x0 0x0 0x60000000 0x08000000
+		0x2 0x0 0x0 0x7e800000 0x00010000
+		0x3 0x0 0x0 0x7fb00000 0x00000100>;
+
+		nor@0,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "cfi-flash";
+			reg = <0x0 0x0 0x8000000>;
+			bank-width = <2>;
+			device-width = <1>;
+		};
+
+		nand@2,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "fsl,ifc-nand";
+			reg = <0x2 0x0 0x10000>;
+		};
+
+		fpga: board-control@3,0 {
+			#address-cells = <1>;
+			#size-cells = <1>;
+			compatible = "simple-bus";
+			reg = <0x3 0x0 0x0000100>;
+			bank-width = <1>;
+			device-width = <1>;
+			ranges = <0 3 0 0x100>;
+
+			mdio-mux-emi1 {
+				compatible = "mdio-mux-mmioreg";
+				mdio-parent-bus = <&mdio0>;
+				#address-cells = <1>;
+				#size-cells = <0>;
+				reg = <0x54 1>; /* BRDCFG4 */
+				mux-mask = <0xe0>; /* EMI1[2:0] */
+
+				/* Onboard PHYs */
+				ls1021amdio0: mdio@0 {
+					reg = <0>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy1: ethernet-phy@1 {
+						reg = <0x1>;
+					};
+				};
+				ls1021amdio1: mdio@20 {
+					reg = <0x20>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy2: ethernet-phy@2 {
+						reg = <0x2>;
+					};
+				};
+				ls1021amdio2: mdio@40 {
+					reg = <0x40>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					rgmii_phy3: ethernet-phy@3 {
+						reg = <0x3>;
+					};
+				};
+				ls1021amdio3: mdio@60 {
+					reg = <0x60>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					sgmii_phy1c: ethernet-phy@1c {
+						reg = <0x1c>;
+					};
+				};
+				ls1021amdio4: mdio@80 {
+					reg = <0x80>;
+					#address-cells = <1>;
+					#size-cells = <0>;
+					sgmii_phy1d: ethernet-phy@1d {
+						reg = <0x1d>;
+					};
+				};
+			};
+		};
+};
+
+&lpuart0 {
+	status = "okay";
+};
+
+&mdio0 {
+	tbi0: tbi-phy@8 {
+		reg = <0x8>;
+		device_type = "tbi-phy";
+	};
+};
+
+&pwm3 {
+	status = "okay";
+};
+
+&pwm7 {
+	status = "okay";
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&uart1 {
+	status = "okay";
+};
-- 
1.8.0

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html