* [PATCHv3 0/6] ARM: imx: Add Freescale LS1021A SoC and board support
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 0/6] ARM: imx: Add Freescale LS1021A SoC and board support
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jingchang Lu, Nikhil Badola,
Chenhui Zhao, Suresh Gupta, Shaveta Leekha, Ruchika Gupta,
Bhupesh Sharma, Chao Fu, Xiubo Li, 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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Jingchang Lu <b35083@freescale.com>
Add Freescale LS1021A SoC device tree support
Signed-off-by: Nikhil Badola <nikhil.badola@freescale.com>
Signed-off-by: Chenhui Zhao <chenhui.zhao@freescale.com>
Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: Shaveta Leekha <shaveta@freescale.com>
Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Chao Fu <b44548@freescale.com>
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
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 at 80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x20000000>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at f00 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0xf00>;
+ };
+
+ cpu at 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 at 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 at 1530000 {
+ compatible = "fsl,ifc", "simple-bus";
+ reg = <0x0 0x1530000 0x0 0x10000>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ dcfg: dcfg at 1ee0000 {
+ compatible = "fsl,ls1021a-dcfg";
+ reg = <0x0 0x1ee0000 0x0 0x10000>;
+ };
+
+ esdhc: esdhc at 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 at 1570000 {
+ compatible = "fsl,ls1021a-scfg";
+ reg = <0x0 0x1570000 0x0 0x10000>;
+ };
+
+ crypto: crypto at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 2d24000 {
+ compatible = "gianfar";
+ device_type = "mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0 0x2d24000 0x0 0x4000>;
+ };
+
+ enet0: ethernet at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 0 {
+ compatible = "fsl,ls1021a-dcsr-epu";
+ reg = <0x0 0x10000>;
+ };
+
+ dcsr-gdi at 100000 {
+ compatible = "fsl,ls1021a-dcsr-gdi";
+ reg = <0x100000 0x10000>;
+ };
+
+ dcsr-dddi at 120000 {
+ compatible = "fsl,ls1021a-dcsr-dddi";
+ reg = <0x120000 0x10000>;
+ };
+
+ dcsr-dcfg at 220000 {
+ compatible = "fsl,ls1021a-dcsr-dcfg";
+ reg = <0x220000 0x1000>;
+ };
+
+ dcsr-clock at 221000 {
+ compatible = "fsl,ls1021a-dcsr-clock";
+ reg = <0x221000 0x1000>;
+ };
+
+ dcsr-rcpm at 222000 {
+ compatible = "fsl,ls1021a-dcsr-rcpm";
+ reg = <0x222000 0x1000 0x223000 0x1000>;
+ };
+
+ dcsr-ccp at 225000 {
+ compatible = "fsl,ls1021a-dcsr-ccp";
+ reg = <0x225000 0x1000>;
+ };
+
+ dcsr-fusectrl at 226000 {
+ compatible = "fsl,ls1021a-dcsr-fusectrl";
+ reg = <0x226000 0x1000>;
+ };
+
+ dcsr-dap at 300000 {
+ compatible = "fsl,ls1021a-dcsr-dap";
+ reg = <0x300000 0x10000>;
+ };
+
+ dcsr-cstf at 350000 {
+ compatible = "fsl,ls1021a-dcsr-cstf";
+ reg = <0x350000 0x1000 0x3a7000 0x1000>;
+ };
+
+ dcsr-a7rom at 360000 {
+ compatible = "fsl,ls1021a-dcsr-a7rom";
+ reg = <0x360000 0x10000>;
+ };
+
+ dcsr-a7cpu at 370000 {
+ compatible = "fsl,ls1021a-dcsr-a7cpu";
+ reg = <0x370000 0x8000>;
+ };
+
+ dcsr-a7cti at 378000 {
+ compatible = "fsl,ls1021a-dcsr-a7cti";
+ reg = <0x378000 0x4000>;
+ };
+
+ dcsr-etm at 37c000 {
+ compatible = "fsl,ls1021a-dcsr-etm";
+ reg = <0x37c000 0x1000 0x37d000 0x3000>;
+ };
+
+ dcsr-hugorom at 3a0000 {
+ compatible = "fsl,ls1021a-dcsr-hugorom";
+ reg = <0x3a0000 0x1000>;
+ };
+
+ dcsr-etf at 3a1000 {
+ compatible = "fsl,ls1021a-dcsr-etf";
+ reg = <0x3a1000 0x1000 0x3a2000 0x1000>;
+ };
+
+ dcsr-etr at 3a3000 {
+ compatible = "fsl,ls1021a-dcsr-etr";
+ reg = <0x3a3000 0x1000>;
+ };
+
+ dcsr-cti at 3a4000 {
+ compatible = "fsl,ls1021a-dcsr-cti";
+ reg = <0x3a4000 0x1000 0x3a5000 0x1000 0x3a6000 0x1000>;
+ };
+
+ dcsr-atbrepl at 3a8000 {
+ compatible = "fsl,ls1021a-dcsr-atbrepl";
+ reg = <0x3a8000 0x1000>;
+ };
+
+ dcsr-tsgen-ctrl at 3a9000 {
+ compatible = "fsl,ls1021a-dcsr-tsgen-ctrl";
+ reg = <0x3a9000 0x1000>;
+ };
+
+ dcsr-tsgen-read at 3aa000 {
+ compatible = "fsl,ls1021a-dcsr-tsgen-read";
+ reg = <0x3aa000 0x1000>;
+ };
+ };
+};
--
1.8.0
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 2/6] ARM: dts: Add initial LS1021A QDS board dts support
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jingchang Lu, Alison Wang,
Chao Fu, Jason Jin, Xiubo Li, Bhupesh Sharma, Jaiprakash Singh,
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 2/6] ARM: dts: Add initial LS1021A QDS board dts support
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Jingchang Lu <b35083@freescale.com>
Signed-off-by: Alison Wang <alison.wang@freescale.com>
Signed-off-by: Chao Fu <B44548@freescale.com>
Signed-off-by: Jason Jin <Jason.Jin@freescale.com>
Signed-off-by: Xiubo Li <Li.Xiubo@freescale.com>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@freescale.com>
Signed-off-by: Jaiprakash Singh <b44839@freescale.com>
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
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 at 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 at 77 {
+ compatible = "philips,pca9547";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c at 0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+
+ rtc at 68 {
+ compatible = "dallas,ds3232";
+ reg = <0x68>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ i2c at 2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+
+ ina220 at 40 {
+ compatible = "ti,ina220";
+ reg = <0x40>;
+ shunt-resistor = <1000>;
+ };
+
+ ina220 at 41 {
+ compatible = "ti,ina220";
+ reg = <0x41>;
+ shunt-resistor = <1000>;
+ };
+ };
+
+ i2c at 3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ eeprom at 56 {
+ compatible = "at24,24c512";
+ reg = <0x56>;
+ };
+
+ eeprom at 57 {
+ compatible = "at24,24c512";
+ reg = <0x57>;
+ };
+
+ adt7461a at 4c {
+ compatible = "adt7461a";
+ reg = <0x4c>;
+ };
+ };
+
+ i2c at 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 at 0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ nand at 2,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,ifc-nand";
+ reg = <0x2 0x0 0x10000>;
+ };
+
+ fpga: board-control at 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 at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rgmii_phy1: ethernet-phy at 1 {
+ reg = <0x1>;
+ };
+ };
+ ls1021amdio1: mdio at 20 {
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rgmii_phy2: ethernet-phy at 2 {
+ reg = <0x2>;
+ };
+ };
+ ls1021amdio2: mdio at 40 {
+ reg = <0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rgmii_phy3: ethernet-phy at 3 {
+ reg = <0x3>;
+ };
+ };
+ ls1021amdio3: mdio at 60 {
+ reg = <0x60>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy1c: ethernet-phy at 1c {
+ reg = <0x1c>;
+ };
+ };
+ ls1021amdio4: mdio at 80 {
+ reg = <0x80>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ sgmii_phy1d: ethernet-phy at 1d {
+ reg = <0x1d>;
+ };
+ };
+ };
+ };
+};
+
+&lpuart0 {
+ status = "okay";
+};
+
+&mdio0 {
+ tbi0: tbi-phy at 8 {
+ reg = <0x8>;
+ device_type = "tbi-phy";
+ };
+};
+
+&pwm3 {
+ status = "okay";
+};
+
+&pwm7 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
1.8.0
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 3/6] ARM: dts: Add initial LS1021A TWR board dts support
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo; +Cc: devicetree, Chao Fu, Chen Lu, linux-arm-kernel, 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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 3/6] ARM: dts: Add initial LS1021A TWR board dts support
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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 at 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 at 0 {
+ reg = <0x0>;
+ };
+ rgmii_phy1: ethernet-phy at 1 {
+ reg = <0x1>;
+ };
+ sgmii_phy2: ethernet-phy at 2 {
+ reg = <0x2>;
+ };
+ tbi1: tbi-phy at 1f {
+ reg = <0x1f>;
+ device_type = "tbi-phy";
+ };
+};
+
+&pwm6 {
+ status = "okay";
+};
+
+&pwm7 {
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
--
1.8.0
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 4/6] dt-bindings: arm: add Freescale LS1021A SoC device tree binding
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, 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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 4/6] dt-bindings: arm: add Freescale LS1021A SoC device tree binding
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Jingchang Lu <jingchang.lu@freescale.com>
---
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 at 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 at 1ee0000 {
+ compatible = "fsl,ls1021a-dcfg";
+ reg = <0x0 0x1ee0000 0x0 0x10000>;
+ };
--
1.8.0
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, 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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Jingchang Lu <b35083@freescale.com>
The LS1021A SoC is a dual-core Cortex-A7 based processor,
this add the initial support for it.
Signed-off-by: Jingchang Lu <b35083@freescale.com>
---
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 6/6] ARM: imx: Add Freescale LS1021A SMP support
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 9:12 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: shawn.guo-KZfg59tc24xl57MIdRCFDg
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, 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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* [PATCHv3 6/6] ARM: imx: Add Freescale LS1021A SMP support
@ 2014-09-09 9:12 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
From: Jingchang Lu <b35083@freescale.com>
Freescale LS1021A SoCs deploy two cortex-A7 processors,
this adds bring-up support for the secondary core.
Signed-off-by: Jingchang Lu <b35083@freescale.com>
---
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
^ permalink raw reply related [flat|nested] 52+ messages in thread
* Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 11:41 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:41 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Jingchang Lu, shawn.guo-KZfg59tc24xl57MIdRCFDg, Jingchang Lu,
devicetree-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-09 11:41 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:41 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 11:50 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:50 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Jingchang Lu, shawn.guo-KZfg59tc24xl57MIdRCFDg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chenhui Zhao, Chao Fu,
Shaveta Leekha, Suresh Gupta, Bhupesh Sharma, Xiubo Li,
Ruchika Gupta, Jingchang Lu, Nikhil Badola
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-09 11:50 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:50 UTC (permalink / raw)
To: linux-arm-kernel
On Tuesday 09 September 2014 17:12:27 Jingchang Lu wrote:
> + dcfg: dcfg at 1ee0000 {
> + compatible = "fsl,ls1021a-dcfg";
> + reg = <0x0 0x1ee0000 0x0 0x10000>;
> + };
> + scfg: scfg at 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 at 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 at 100000 {
> + compatible = "fsl,ls1021a-dcsr-gdi";
> + reg = <0x100000 0x10000>;
> + };
> +
> + dcsr-dddi at 120000 {
> + compatible = "fsl,ls1021a-dcsr-dddi";
> + reg = <0x120000 0x10000>;
> + };
> +
> + dcsr-dcfg at 220000 {
> + compatible = "fsl,ls1021a-dcsr-dcfg";
> + reg = <0x220000 0x1000>;
> + };
> +
> + dcsr-clock at 221000 {
> + compatible = "fsl,ls1021a-dcsr-clock";
> + reg = <0x221000 0x1000>;
> + };
None of these are part of the dcsr.txt binding.
> + dcsr-rcpm at 222000 {
> + compatible = "fsl,ls1021a-dcsr-rcpm";
> + reg = <0x222000 0x1000 0x223000 0x1000>;
> + };
Missing generic fsl,dcsr-rcpm compatible value again.
> + dcsr-ccp at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-09 11:53 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:53 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Jingchang Lu, shawn.guo-KZfg59tc24xl57MIdRCFDg,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chenhui Zhao, Chao Fu,
Shaveta Leekha, Suresh Gupta, Bhupesh Sharma, Xiubo Li,
Ruchika Gupta, Jingchang Lu, Nikhil Badola
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-09 11:53 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-09 11:53 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-09 11:41 ` Arnd Bergmann
@ 2014-09-10 3:31 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-10 3:31 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Shawn Guo, devicetree-u79uwXL29TY76Z2rM5mHXA
[-- 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-10 3:31 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-10 3:31 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Tuesday, September 09, 2014 7:41 PM
>To: linux-arm-kernel at lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; Lu Jingchang-B35083;
>devicetree at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-10 3:31 ` Jingchang Lu
@ 2014-09-10 7:42 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-10 7:42 UTC (permalink / raw)
To: Jingchang Lu
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-10 7:42 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-10 7:42 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 11:50 ` Arnd Bergmann
@ 2014-09-11 8:21 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:21 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Shawn Guo, devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg, Chao Fu,
shaveta-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
nikhil.badola-KZfg59tc24xl57MIdRCFDg
[-- 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 8:21 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:21 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Tuesday, September 09, 2014 7:50 PM
>To: linux-arm-kernel at lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree at 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 at 1ee0000 {
>> + compatible = "fsl,ls1021a-dcfg";
>> + reg = <0x0 0x1ee0000 0x0 0x10000>;
>> + };
>> + scfg: scfg at 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 at 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 at 100000 {
>> + compatible = "fsl,ls1021a-dcsr-gdi";
>> + reg = <0x100000 0x10000>;
>> + };
>> +
>> + dcsr-dddi at 120000 {
>> + compatible = "fsl,ls1021a-dcsr-dddi";
>> + reg = <0x120000 0x10000>;
>> + };
>> +
>> + dcsr-dcfg at 220000 {
>> + compatible = "fsl,ls1021a-dcsr-dcfg";
>> + reg = <0x220000 0x1000>;
>> + };
>> +
>> + dcsr-clock at 221000 {
>> + compatible = "fsl,ls1021a-dcsr-clock";
>> + reg = <0x221000 0x1000>;
>> + };
>
>None of these are part of the dcsr.txt binding.
>
>> + dcsr-rcpm at 222000 {
>> + compatible = "fsl,ls1021a-dcsr-rcpm";
>> + reg = <0x222000 0x1000 0x223000 0x1000>;
>> + };
>
>Missing generic fsl,dcsr-rcpm compatible value again.
>
>> + dcsr-ccp at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 11:53 ` Arnd Bergmann
@ 2014-09-11 8:21 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:21 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Shawn Guo, devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg, Chao Fu,
shaveta-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
nikhil.badola-KZfg59tc24xl57MIdRCFDg
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 8:21 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:21 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Tuesday, September 09, 2014 7:53 PM
>To: linux-arm-kernel at lists.infradead.org
>Cc: Lu Jingchang-B35083; Guo Shawn-R65073; devicetree at 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 at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-11 8:41 ` suresh.gupta at freescale.com
-1 siblings, 0 replies; 52+ messages in thread
From: suresh.gupta @ 2014-09-11 8:41 UTC (permalink / raw)
To: Shawn Guo
Cc: devicetree, chenhui.zhao, Chao Fu, shaveta, Ruchika Gupta,
bhupesh.sharma, Li.Xiubo, Jingchang Lu, nikhil.badola,
linux-arm-kernel
> -----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";
};
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 8:41 ` suresh.gupta at freescale.com
0 siblings, 0 replies; 52+ messages in thread
From: suresh.gupta at freescale.com @ 2014-09-11 8:41 UTC (permalink / raw)
To: linux-arm-kernel
> -----Original Message-----
> From: Jingchang Lu [mailto:jingchang.lu at freescale.com]
> Sent: Tuesday, September 09, 2014 2:42 PM
> To: Guo Shawn-R65073
> Cc: linux-arm-kernel at lists.infradead.org; devicetree at 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 at 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 at 3100000 {
compatible = "snps,dwc3";
reg = <0x0 0x3100000 0x0 0x10000>;
interrupts = <GIC_SPI 93 IRQ_TYPE_LEVEL_HIGH>;
dr_mode = "host";
};
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-11 8:41 ` suresh.gupta at freescale.com
@ 2014-09-11 8:58 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:58 UTC (permalink / raw)
To: suresh.gupta-KZfg59tc24xl57MIdRCFDg, Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
nikhil.badola-KZfg59tc24xl57MIdRCFDg,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg,
shaveta-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg, Chao Fu,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 8:58 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 8:58 UTC (permalink / raw)
To: linux-arm-kernel
>-----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 at lists.infradead.org; devicetree at 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 at freescale.com]
>> Sent: Tuesday, September 09, 2014 2:42 PM
>> To: Guo Shawn-R65073
>> Cc: linux-arm-kernel at lists.infradead.org; devicetree at 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 at 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 at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-10 7:42 ` Arnd Bergmann
@ 2014-09-11 9:53 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 9:53 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA
[-- 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-11 9:53 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 9:53 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Wednesday, September 10, 2014 3:42 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel at lists.infradead.org; Guo Shawn-R65073;
>devicetree at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-10 7:42 ` Arnd Bergmann
@ 2014-09-11 10:05 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 10:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-11 10:05 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-11 10:05 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Wednesday, September 10, 2014 3:42 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel at lists.infradead.org; Guo Shawn-R65073;
>devicetree at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-09 9:12 ` Jingchang Lu
@ 2014-09-11 10:10 ` nikhil.badola at freescale.com
-1 siblings, 0 replies; 52+ messages in thread
From: nikhil.badola-KZfg59tc24xl57MIdRCFDg @ 2014-09-11 10:10 UTC (permalink / raw)
To: Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jingchang Lu,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
shaveta-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg, Chao Fu,
Li.Xiubo-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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 10:10 ` nikhil.badola at freescale.com
0 siblings, 0 replies; 52+ messages in thread
From: nikhil.badola at freescale.com @ 2014-09-11 10:10 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Jingchang Lu [mailto:jingchang.lu at freescale.com]
>Sent: Tuesday, September 09, 2014 2:42 PM
>To: Guo Shawn-R65073
>Cc: linux-arm-kernel at lists.infradead.org; devicetree at 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 at 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>;
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-11 8:21 ` Jingchang Lu
@ 2014-09-11 10:36 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-11 10:36 UTC (permalink / raw)
To: Jingchang Lu
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg, Chao Fu,
shaveta-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
nikhil.badola-KZfg59tc24xl57MIdRCFDg
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 10:36 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-11 10:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-11 9:53 ` Jingchang Lu
@ 2014-09-11 10:44 ` Arnd Bergmann
-1 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-11 10:44 UTC (permalink / raw)
To: Jingchang Lu
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-11 10:44 ` Arnd Bergmann
0 siblings, 0 replies; 52+ messages in thread
From: Arnd Bergmann @ 2014-09-11 10:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 11 September 2014 09:53:56 Jingchang Lu wrote:
> >From: Arnd Bergmann [mailto:arnd at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-11 10:36 ` Arnd Bergmann
@ 2014-09-11 11:12 ` Sascha Hauer
-1 siblings, 0 replies; 52+ messages in thread
From: Sascha Hauer @ 2014-09-11 11:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jingchang Lu, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Shawn Guo, devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg, Chao Fu,
shaveta-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
nikhil.badola-KZfg59tc24xl57MIdRCFDg
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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-11 11:12 ` Sascha Hauer
0 siblings, 0 replies; 52+ messages in thread
From: Sascha Hauer @ 2014-09-11 11:12 UTC (permalink / raw)
To: linux-arm-kernel
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 |
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-11 10:10 ` nikhil.badola at freescale.com
@ 2014-09-12 1:46 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 1:46 UTC (permalink / raw)
To: nikhil.badola-KZfg59tc24xl57MIdRCFDg, Shawn Guo
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
shaveta-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg, Chao Fu,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-12 1:46 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 1:46 UTC (permalink / raw)
To: linux-arm-kernel
>-----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 at lists.infradead.org; devicetree at 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 at freescale.com]
>>Sent: Tuesday, September 09, 2014 2:42 PM
>>To: Guo Shawn-R65073
>>Cc: linux-arm-kernel at lists.infradead.org; devicetree at 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 at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
2014-09-11 10:44 ` Arnd Bergmann
@ 2014-09-12 3:17 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 3:17 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A
@ 2014-09-12 3:17 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 3:17 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Arnd Bergmann [mailto:arnd at arndb.de]
>Sent: Thursday, September 11, 2014 6:45 PM
>To: Lu Jingchang-B35083
>Cc: linux-arm-kernel at lists.infradead.org; Guo Shawn-R65073;
>devicetree at 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 at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* RE: [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
2014-09-11 11:12 ` Sascha Hauer
@ 2014-09-12 9:59 ` Jingchang Lu
-1 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 9:59 UTC (permalink / raw)
To: Sascha Hauer, Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
chenhui.zhao-KZfg59tc24xl57MIdRCFDg, Chao Fu,
shaveta-KZfg59tc24xl57MIdRCFDg,
suresh.gupta-KZfg59tc24xl57MIdRCFDg,
bhupesh.sharma-KZfg59tc24xl57MIdRCFDg,
Li.Xiubo-KZfg59tc24xl57MIdRCFDg, Ruchika Gupta,
nikhil.badola-KZfg59tc24xl57MIdRCFDg
>-----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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-12 9:59 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-12 9:59 UTC (permalink / raw)
To: linux-arm-kernel
>-----Original Message-----
>From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
>Sent: Thursday, September 11, 2014 7:12 PM
>To: Arnd Bergmann
>Cc: Lu Jingchang-B35083; linux-arm-kernel at lists.infradead.org; Guo Shawn-
>R65073; devicetree at 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-09 8:39 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 8:39 UTC (permalink / raw)
To: shawn.guo; +Cc: mark.rutland, devicetree, linux-arm-kernel
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 untested node and mtd partation info.
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, 1216 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
^ permalink raw reply [flat|nested] 52+ messages in thread
* [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A
@ 2014-09-09 8:39 ` Jingchang Lu
0 siblings, 0 replies; 52+ messages in thread
From: Jingchang Lu @ 2014-09-09 8:39 UTC (permalink / raw)
To: linux-arm-kernel
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 untested node and mtd partation info.
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, 1216 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
^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2014-09-12 9:59 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-09 9:12 [PATCHv3 0/6] ARM: imx: Add Freescale LS1021A SoC and board support Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
[not found] ` <1410253952-15631-1-git-send-email-jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-09-09 9:12 ` [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
[not found] ` <1410253952-15631-2-git-send-email-jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-09-09 11:50 ` Arnd Bergmann
2014-09-09 11:50 ` Arnd Bergmann
2014-09-11 8:21 ` Jingchang Lu
2014-09-11 8:21 ` Jingchang Lu
2014-09-09 11:53 ` Arnd Bergmann
2014-09-09 11:53 ` Arnd Bergmann
2014-09-11 8:21 ` Jingchang Lu
2014-09-11 8:21 ` Jingchang Lu
[not found] ` <cd69af536cd248b8add94a468fa97095-AZ66ij2kwab4MB1ZSnT4iOO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-09-11 10:36 ` Arnd Bergmann
2014-09-11 10:36 ` Arnd Bergmann
2014-09-11 11:12 ` Sascha Hauer
2014-09-11 11:12 ` Sascha Hauer
[not found] ` <20140911111202.GA4958-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2014-09-12 9:59 ` Jingchang Lu
2014-09-12 9:59 ` Jingchang Lu
2014-09-11 10:10 ` nikhil.badola-KZfg59tc24xl57MIdRCFDg
2014-09-11 10:10 ` nikhil.badola at freescale.com
[not found] ` <1444adbcf7cd4b578a131db11e662490-RQSpjbwlmjRJV8q+uXLxw5wN6zqB+hSMnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
2014-09-12 1:46 ` Jingchang Lu
2014-09-12 1:46 ` Jingchang Lu
2014-09-11 8:41 ` suresh.gupta
2014-09-11 8:41 ` suresh.gupta at freescale.com
[not found] ` <fa256d13e4304175b14369b9d3b55729-AZ66ij2kwaYNjdDjpj1h++O6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-09-11 8:58 ` Jingchang Lu
2014-09-11 8:58 ` Jingchang Lu
2014-09-09 9:12 ` [PATCHv3 2/6] ARM: dts: Add initial LS1021A QDS board dts support Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
2014-09-09 9:12 ` [PATCHv3 4/6] dt-bindings: arm: add Freescale LS1021A SoC device tree binding Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
2014-09-09 9:12 ` [PATCHv3 5/6] ARM: imx: Add initial support for Freescale LS1021A Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
[not found] ` <1410253952-15631-6-git-send-email-jingchang.lu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-09-09 11:41 ` Arnd Bergmann
2014-09-09 11:41 ` Arnd Bergmann
2014-09-10 3:31 ` Jingchang Lu
2014-09-10 3:31 ` Jingchang Lu
[not found] ` <daf5ec5b70164b3e9a810def41909c48-AZ66ij2kwab4MB1ZSnT4iOO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-09-10 7:42 ` Arnd Bergmann
2014-09-10 7:42 ` Arnd Bergmann
2014-09-11 9:53 ` Jingchang Lu
2014-09-11 9:53 ` Jingchang Lu
[not found] ` <517628172fb3416ea7b12b4ae24e098a-AZ66ij2kwab4MB1ZSnT4iOO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-09-11 10:44 ` Arnd Bergmann
2014-09-11 10:44 ` Arnd Bergmann
2014-09-12 3:17 ` Jingchang Lu
2014-09-12 3:17 ` Jingchang Lu
2014-09-11 10:05 ` Jingchang Lu
2014-09-11 10:05 ` Jingchang Lu
2014-09-09 9:12 ` [PATCHv3 6/6] ARM: imx: Add Freescale LS1021A SMP support Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
2014-09-09 9:12 ` [PATCHv3 3/6] ARM: dts: Add initial LS1021A TWR board dts support Jingchang Lu
2014-09-09 9:12 ` Jingchang Lu
-- strict thread matches above, loose matches on Subject: below --
2014-09-09 8:39 [PATCHv3 1/6] ARM: dts: Add SoC level device tree support for LS1021A Jingchang Lu
2014-09-09 8:39 ` Jingchang Lu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.