[PATCH V3 01/10] dt-bindings: fsl: add compatible for imx7ulp evk

[PATCH V3 01/10] dt-bindings: fsl: add compatible for imx7ulp evk

[A.s. Dong]

Cc: devicetree@vger.kernel.org
Cc: Shawn Guo <shawnguo@kernel.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
 Documentation/devicetree/bindings/arm/fsl.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt
index 7b964d8..9c7c788 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -101,6 +101,10 @@ i.MX7 SabreSD Board
 Required root node properties:
     - compatible = "fsl,imx7d-sdb", "fsl,imx7d";
 
+i.MX7ULP Evaluation Kit
+Required root node properties:
+    - compatible = "fsl,imx7ulp-evk", "fsl,imx7ulp";
+
 Generic i.MX boards
 -------------------
 
@@ -123,6 +127,10 @@ i.MX6q generic board
 Required root node properties:
     - compatible = "fsl,imx6q";
 
+i.MX7ULP generic board
+Required root node properties:
+    - compatible = "fsl,imx7ulp";
+
 Freescale Vybrid Platform Device Tree Bindings
 ----------------------------------------------
 
-- 
2.7.4

[PATCH V3 02/10] dt-bindings: fsl: add imx7ulp pm related components bindings

[A.s. Dong]

Add imx7ulp pm related components bindings

Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2->v3:
 * no changes
v1->v2:
 * new patch
---
 .../bindings/arm/freescale/fsl,imx7ulp-pm.txt      | 23 ++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.txt

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.txt
new file mode 100644
index 0000000..75195be
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,imx7ulp-pm.txt
@@ -0,0 +1,23 @@
+Freescale i.MX7ULP Power Management Components
+----------------------------------------------
+
+The Multi-System Mode Controller (MSMC) is responsible for sequencing
+the MCU into and out of all stop and run power modes. Specifically, it
+monitors events to trigger transitions between power modes while
+controlling the power, clocks, and memories of the MCU to achieve the
+power consumption and functionality of that mode.
+
+The WFI or WFE instruction is used to invoke a Sleep, Deep Sleep or
+Standby modes for either Cortex family. Run, Wait, and Stop are the
+common terms used for the primary operating modes of Kinetis
+microcontrollers.
+
+Required properties:
+- compatible:	Should be "fsl,imx7ulp-smc1".
+- reg:		Specifies base physical address and size of the register sets.
+
+Example:
+smc1: smc1@40410000 {
+	compatible = "fsl,imx7ulp-smc1";
+	reg = <0x40410000 0x1000>;
+};
-- 
2.7.4

[PATCH V3 03/10] dt-bindings: gpio: vf610: add optional clocks property

[A.s. Dong]

On some SoCs(e.g. MX7ULP), GPIO clock is gatable and maybe
disabled by default. Users have to make sure it's enabled before
being able to access controller registers, otherwise an external
abort error may occur. Let's add the optional clocks property to
handle this case.

For ULP GPIO clock, it includes two separate clocks: one is for
GPIO controller Input/Output function clock while another is
GPIO port control clock for interrupt function.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stefan Agner <stefan@agner.ch>
Cc: linux-gpio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
v2->v3:
 * no changes
v1->v2:
 * new patch
---
 Documentation/devicetree/bindings/gpio/gpio-vf610.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.txt b/Documentation/devicetree/bindings/gpio/gpio-vf610.txt
index 0ccbae4..ae254aa 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-vf610.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.txt
@@ -24,6 +24,12 @@ Required properties for GPIO node:
       4 = active high level-sensitive.
       8 = active low level-sensitive.
 
+Optional properties:
+-clocks:	Must contain an entry for each entry in clock-names.
+		See common clock-bindings.txt for details.
+-clock-names:	A list of clock names. For imx7ulp, it must contain
+		"gpio", "port".
+
 Note: Each GPIO port should have an alias correctly numbered in "aliases"
 node.
 
-- 
2.7.4

[PATCH V3 05/10] dt-bindings: pinctrl: imx7ulp: back to imx legacy binding for consistency

[A.s. Dong]

We already had an earlier conclusion that all new i.MX Socs will keep
using the legacy i.MX Pinctrl bindings instead of generic pin config.
However, MX7ULP generic pin config binding support has already been in
tree before that time. Per SoC maintainers' suggestions, in order to
get a better consistency for all i.MX devices, we'd like to go back to
imx legacy binding for MX7ULP as well.

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Stefan Agner <stefan@agner.ch>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: linux-gpio@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
 v3: new patch
---
 .../bindings/pinctrl/fsl,imx7ulp-pinctrl.txt       | 66 ++++++++++------------
 1 file changed, 29 insertions(+), 37 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt
index 44ad670a..bfa3703 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7ulp-pinctrl.txt
@@ -7,55 +7,47 @@ Note:
 This binding doc is only for the IOMUXC1 support in A7 Domain and it only
 supports generic pin config.
 
-Please also refer pinctrl-bindings.txt in this directory for generic pinctrl
-binding.
-
-=== Pin Controller Node ===
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding
+part and usage.
 
 Required properties:
-- compatible:	"fsl,imx7ulp-iomuxc1"
-- reg:		Should contain the base physical address and size of the iomuxc
-		registers.
-
-=== Pin Configuration Node ===
-- pinmux: One integers array, represents a group of pins mux setting.
-	The format is pinmux = <PIN_FUNC_ID>, PIN_FUNC_ID is a pin working on
-	a specific function.
-
-	NOTE: i.MX7ULP PIN_FUNC_ID consists of 4 integers as it shares one mux
-	and config register as follows:
-	<mux_conf_reg input_reg mux_mode input_val>
-
-	Refer to imx7ulp-pinfunc.h in in device tree source folder for all
-	available imx7ulp PIN_FUNC_ID.
-
-Optional Properties:
-- drive-strength		Integer. Controls Drive Strength
-					0: Standard
-					1: Hi Driver
-- drive-push-pull		Bool. Enable Pin Push-pull
-- drive-open-drain		Bool. Enable Pin Open-drian
-- slew-rate:			Integer. Controls Slew Rate
-					0: Standard
-					1: Slow
-- bias-disable:			Bool. Pull disabled
-- bias-pull-down:		Bool. Pull down on pin
-- bias-pull-up:			Bool. Pull up on pin
+- compatible:	"fsl,imx7ulp-iomuxc1".
+- fsl,pins:	Each entry consists of 5 integers which represents the mux
+		and config setting for one pin. The first 4 integers
+		<mux_conf_reg input_reg mux_mode input_val> are specified
+		using a PIN_FUNC_ID macro, which can be found in
+		imx7ulp-pinfunc.h in the device tree source folder.
+		The last integer CONFIG is the pad setting value like
+		pull-up on this pin.
+
+		Please refer to i.MX7ULP Reference Manual for detailed
+		CONFIG settings.
+
+CONFIG bits definition:
+PAD_CTL_OBE		(1 << 17)
+PAD_CTL_IBE		(1 << 16)
+PAD_CTL_LK		(1 << 16)
+PAD_CTL_DSE_HI		(1 << 6)
+PAD_CTL_DSE_STD		(0 << 6)
+PAD_CTL_ODE		(1 << 5)
+PAD_CTL_PUSH_PULL	(0 << 5)
+PAD_CTL_SRE_SLOW	(1 << 2)
+PAD_CTL_SRE_STD		(0 << 2)
+PAD_CTL_PE		(1 << 0)
 
 Examples:
 #include "imx7ulp-pinfunc.h"
 
 /* Pin Controller Node */
-iomuxc1: iomuxc@40ac0000 {
+iomuxc1: pinctrl@40ac0000 {
 	compatible = "fsl,imx7ulp-iomuxc1";
 	reg = <0x40ac0000 0x1000>;
 
 	/* Pin Configuration Node */
 	pinctrl_lpuart4: lpuart4grp {
-		pinmux = <
-			IMX7ULP_PAD_PTC3__LPUART4_RX
-			IMX7ULP_PAD_PTC2__LPUART4_TX
+		fsl,pins = <
+			IMX7ULP_PAD_PTC3__LPUART4_RX	0x1
+			IMX7ULP_PAD_PTC2__LPUART4_TX	0x1
 		>;
-		bias-pull-up;
 	};
 };
-- 
2.7.4

[PATCH V3 08/10] dts: imx: add common imx7ulp dtsi support

[A.s. Dong]

The i.MX 7ULP family of processors features NXP's advanced implementation
of the Arm Cortex-A7 core, the Arm Cortex-M4 core, as well as a 3D and 2D
Graphics Processing Units (GPUs).

This patch aims to add the initial support including:
1) CLK
2) GPIO PTC, PTD, PTE, PTF
3) uSDHC 1/2
4) LPUART 4/5/6/7
5) LPI2C 6/7

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2->v3:
 * change to generic node names
 * remove arch timer due to:
   1) arch timer is fixed to 1Mhz which is lower accurate than TPM timer (3Mhz).
   2) no firmware progrem CNTFREQ
   3) cpuidle driver is still not in tree will may cause system hang
v1->v2:
 * update clk part due to binding change
 * separate soc.dtsi from board.dts
---
 arch/arm/boot/dts/imx7ulp.dtsi | 314 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 314 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7ulp.dtsi

diff --git a/arch/arm/boot/dts/imx7ulp.dtsi b/arch/arm/boot/dts/imx7ulp.dtsi
new file mode 100644
index 0000000..c06fd3e
--- /dev/null
+++ b/arch/arm/boot/dts/imx7ulp.dtsi
@@ -0,0 +1,314 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ *   Dong Aisheng <aisheng.dong@nxp.com>
+ */
+
+#include <dt-bindings/clock/imx7ulp-clock.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#include "imx7ulp-pinfunc.h"
+
+/ {
+	interrupt-parent = <&intc>;
+
+	#address-cells = <1>;
+	#size-cells = <1>;
+
+	aliases {
+		gpio0 = &gpio_ptc;
+		gpio1 = &gpio_ptd;
+		gpio2 = &gpio_pte;
+		gpio3 = &gpio_ptf;
+		i2c0 = &lpi2c6;
+		i2c1 = &lpi2c7;
+		mmc0 = &usdhc0;
+		mmc1 = &usdhc1;
+		serial0 = &lpuart4;
+		serial1 = &lpuart5;
+		serial2 = &lpuart6;
+		serial3 = &lpuart7;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	intc: interrupt-controller@40021000 {
+		compatible = "arm,cortex-a7-gic";
+		#interrupt-cells = <3>;
+		interrupt-controller;
+		reg = <0x40021000 0x1000>,
+		      <0x40022000 0x1000>;
+	};
+
+	rosc: clock-rosc {
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+		clock-output-names = "rosc";
+		#clock-cells = <0>;
+	};
+
+	sosc: clock-sosc {
+		compatible = "fixed-clock";
+		clock-frequency = <24000000>;
+		clock-output-names = "sosc";
+		#clock-cells = <0>;
+	};
+
+	sirc: clock-sirc {
+		compatible = "fixed-clock";
+		clock-frequency = <16000000>;
+		clock-output-names = "sirc";
+		#clock-cells = <0>;
+	};
+
+	firc: clock-firc {
+		compatible = "fixed-clock";
+		clock-frequency = <48000000>;
+		clock-output-names = "firc";
+		#clock-cells = <0>;
+	};
+
+	upll: clock-upll {
+		compatible = "fixed-clock";
+		clock-frequency = <480000000>;
+		clock-output-names = "upll";
+		#clock-cells = <0>;
+	};
+
+	mpll: clock-mpll {
+		compatible = "fixed-clock";
+		clock-frequency = <480000000>;
+		clock-output-names = "mpll";
+		#clock-cells = <0>;
+	};
+
+	ahbbridge0: bus@40000000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x40000000 0x800000>;
+		ranges;
+
+		lpuart4: serial@402d0000 {
+			compatible = "fsl,imx7ulp-lpuart";
+			reg = <0x402d0000 0x1000>;
+			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc2 IMX7ULP_CLK_LPUART4>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPUART4>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>;
+			assigned-clock-rates = <24000000>;
+			status = "disabled";
+		};
+
+		lpuart5: serial@402e0000 {
+			compatible = "fsl,imx7ulp-lpuart";
+			reg = <0x402e0000 0x1000>;
+			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc2 IMX7ULP_CLK_LPUART5>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPUART5>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		tpm5: tpm@40260000 {
+			compatible = "fsl,imx7ulp-tpm";
+			reg = <0x40260000 0x1000>;
+			interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
+				 <&pcc2 IMX7ULP_CLK_LPTPM5>;
+			clock-names = "ipg", "per";
+		};
+
+		usdhc0: mmc@40370000 {
+			compatible = "fsl,imx7ulp-usdhc", "fsl,imx6sx-usdhc";
+			reg = <0x40370000 0x10000>;
+			interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
+				 <&scg1 IMX7ULP_CLK_NIC1_DIV>,
+				 <&pcc2 IMX7ULP_CLK_USDHC0>;
+			clock-names ="ipg", "ahb", "per";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC0>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_NIC1_DIV>;
+			bus-width = <4>;
+			fsl,tuning-start-tap = <20>;
+			fsl,tuning-step= <2>;
+			status = "disabled";
+		};
+
+		usdhc1: mmc@40380000 {
+			compatible = "fsl,imx7ulp-usdhc", "fsl,imx6sx-usdhc";
+			reg = <0x40380000 0x10000>;
+			interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
+				 <&scg1 IMX7ULP_CLK_NIC1_DIV>,
+				 <&pcc2 IMX7ULP_CLK_USDHC1>;
+			clock-names ="ipg", "ahb", "per";
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC1>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_NIC1_DIV>;
+			bus-width = <4>;
+			fsl,tuning-start-tap = <20>;
+			fsl,tuning-step= <2>;
+			status = "disabled";
+		};
+
+		scg1: clock-controller@403e0000 {
+			compatible = "fsl,imx7ulp-scg1";
+			reg = <0x403e0000 0x10000>;
+			clocks = <&rosc>, <&sosc>, <&sirc>,
+				 <&firc>, <&upll>, <&mpll>;
+			clock-names = "rosc", "sosc", "sirc",
+				      "firc", "upll", "mpll";
+			#clock-cells = <1>;
+		};
+
+		pcc2: clock-controller@403f0000 {
+			compatible = "fsl,imx7ulp-pcc2";
+			reg = <0x403f0000 0x10000>;
+			#clock-cells = <1>;
+			assigned-clocks = <&pcc2 IMX7ULP_CLK_LPTPM5>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_SOSC_BUS_CLK>;
+		};
+
+		smc1: smc1@40410000 {
+			compatible = "fsl,imx7ulp-smc1";
+			reg = <0x40410000 0x1000>;
+		};
+
+		pcc3: clock-controller@40b30000 {
+			compatible = "fsl,imx7ulp-pcc3";
+			reg = <0x40b30000 0x10000>;
+			#clock-cells = <1>;
+		};
+	};
+
+	ahbbridge1: bus@40800000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x40800000 0x800000>;
+		ranges;
+
+		lpi2c6: i2c@40a40000 {
+			compatible = "fsl,imx7ulp-lpi2c";
+			reg = <0x40a40000 0x10000>;
+			interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C6>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		lpi2c7: i2c@40a50000 {
+			compatible = "fsl,imx7ulp-lpi2c";
+			reg = <0x40a50000 0x10000>;
+			interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPI2C7>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		lpuart6: serial@40a60000 {
+			compatible = "fsl,imx7ulp-lpuart";
+			reg = <0x40a60000 0x1000>;
+			interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc3 IMX7ULP_CLK_LPUART6>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPUART6>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		lpuart7: serial@40a70000 {
+			compatible = "fsl,imx7ulp-lpuart";
+			reg = <0x40a70000 0x1000>;
+			interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+			clocks = <&pcc3  IMX7ULP_CLK_LPUART7>;
+			clock-names = "ipg";
+			assigned-clocks = <&pcc3 IMX7ULP_CLK_LPUART7>;
+			assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC>;
+			assigned-clock-rates = <48000000>;
+			status = "disabled";
+		};
+
+		iomuxc1: pinctrl@40ac0000 {
+			compatible = "fsl,imx7ulp-iomuxc1";
+			reg = <0x40ac0000 0x1000>;
+		};
+
+		gpio_ptc: gpio@40ae0000 {
+			compatible = "fsl,imx7ulp-gpio", "fsl,vf610-gpio";
+			reg = <0x40ae0000 0x1000 0x400f0000 0x40>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupts = <GIC_SPI 48 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
+				 <&pcc3 IMX7ULP_CLK_PCTLC>;
+			clock-names = "gpio", "port";
+			gpio-ranges = <&iomuxc1 0 0 32>;
+		};
+
+		gpio_ptd: gpio@40af0000 {
+			compatible = "fsl,imx7ulp-gpio", "fsl,vf610-gpio";
+			reg = <0x40af0000 0x1000 0x400f0040 0x40>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
+				 <&pcc3 IMX7ULP_CLK_PCTLD>;
+			clock-names = "gpio", "port";
+			gpio-ranges = <&iomuxc1 0 32 32>;
+		};
+
+		gpio_pte: gpio@40b00000 {
+			compatible = "fsl,imx7ulp-gpio", "fsl,vf610-gpio";
+			reg = <0x40b00000 0x1000 0x400f0080 0x40>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
+				 <&pcc3 IMX7ULP_CLK_PCTLE>;
+			clock-names = "gpio", "port";
+			gpio-ranges = <&iomuxc1 0 64 32>;
+		};
+
+		gpio_ptf: gpio@40b10000 {
+			compatible = "fsl,imx7ulp-gpio", "fsl,vf610-gpio";
+			reg = <0x40b10000 0x1000 0x400f00c0 0x40>;
+			gpio-controller;
+			#gpio-cells = <2>;
+			interrupts = <GIC_SPI 51 IRQ_TYPE_LEVEL_HIGH>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			clocks = <&pcc2 IMX7ULP_CLK_RGPIO2P1>,
+				 <&pcc3 IMX7ULP_CLK_PCTLF>;
+			clock-names = "gpio", "port";
+			gpio-ranges = <&iomuxc1 0 96 32>;
+		};
+	};
+};
-- 
2.7.4

[PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

The NXP i.MX 7ULP Evaluation Kit (EVK) provides a platform for rapid
evaluation of the i.MX 7ULP, which features NXP's advanced implementation
of the Arm Cortex-A7 core, the Arm Cortex-M4 core, as well as a 3D and
2D Graphics Processing Units (GPUs).

The EVK enables HDMI output for simple out-of-the-box to bring up but
allows reconfiguration for MIPI displays. The EVK is designed as a
System-On-Module(SOM) board that connects to an associated baseboard.
The SOM provides 1 GB LPDDR3, 8 MB Quad SPI flash, Micro SD 3.0 card
socket, WiFi/ Bluetooth capability, USB 2.0 OTG with Type C connector
and an NXP PF1550 power management IC (PMIC). The baseboard provides
additional capabilities including a full SD/MMC 3.0 card socket, audio
codec, multiple sensors, an HDMI connector, and an alternate MIPI display
connector. Additionally, the EVK facilitates software development with the
ultimate goal of faster time to market through the support of both
Linux OS and AndroidTM rich operating systems, as well as FreeRTOS.

This patch aims to support the preliminary booting up features
as follows:
GPIO
LPUART
FEC
SD/MMC

See more board details:
https://www.nxp.com/products/processors-and-microcontrollers/
arm-based-processors-and-mcus/i.mx-applications-processors/
i.mx-7-processors/evaluation-kit-for-the-i.mx-7ulp-applications
-processor:MCIMX7ULP-EVK

Cc: Rob Herring <robh+dt@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
---
ChangeLog:
v2->v3:
 * remove "Generic DT based system"
 * add device_type property for memory node
 * back to old pinctrl binding according to SoC maintainer's suggestions
v1->v2:
 * switch to SPDX license
 * pad name update
 * fix Character '_' not recommended in node name
 * separate from soc.dtsi file
---
 arch/arm/boot/dts/Makefile        |  2 +
 arch/arm/boot/dts/imx7ulp-evk.dts | 77 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7ulp-evk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d7268ae..39eac9c 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -573,6 +573,8 @@ dtb-$(CONFIG_SOC_IMX7D) += \
 	imx7d-sdb-sht11.dtb \
 	imx7s-colibri-eval-v3.dtb \
 	imx7s-warp.dtb
+dtb-$(CONFIG_SOC_IMX7ULP) += \
+	imx7ulp-evk.dtb
 dtb-$(CONFIG_SOC_LS1021A) += \
 	ls1021a-moxa-uc-8410a.dtb \
 	ls1021a-qds.dtb \
diff --git a/arch/arm/boot/dts/imx7ulp-evk.dts b/arch/arm/boot/dts/imx7ulp-evk.dts
new file mode 100644
index 0000000..07796f3
--- /dev/null
+++ b/arch/arm/boot/dts/imx7ulp-evk.dts
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ *   Dong Aisheng <aisheng.dong@nxp.com>
+ */
+
+/dts-v1/;
+
+#include "imx7ulp.dtsi"
+
+/ {
+	model = "NXP i.MX7ULP EVK";
+	compatible = "fsl,imx7ulp-evk", "fsl,imx7ulp";
+
+	chosen {
+		stdout-path = &lpuart4;
+	};
+
+	memory@60000000 {
+		device_type = "memory";
+		reg = <0x60000000 0x40000000>;
+	};
+
+	reg_vsd_3v3: regulator-vsd-3v3 {
+		compatible = "regulator-fixed";
+		regulator-name = "VSD_3V3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usdhc0_rst>;
+		gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>;
+		enable-active-high;
+	};
+};
+
+&lpuart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_lpuart4>;
+	status = "okay";
+};
+
+&usdhc0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_usdhc0>;
+	cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>;
+	vmmc-supply = <&reg_vsd_3v3>;
+	status = "okay";
+};
+
+&iomuxc1 {
+	pinctrl_lpuart4: lpuart4grp {
+		fsl,pins = <
+			IMX7ULP_PAD_PTC3__LPUART4_RX	0x1
+			IMX7ULP_PAD_PTC2__LPUART4_TX	0x1
+		>;
+		bias-pull-up;
+	};
+
+	pinctrl_usdhc0: usdhc0grp {
+		fsl,pins = <
+			IMX7ULP_PAD_PTD1__SDHC0_CMD	0x41
+			IMX7ULP_PAD_PTD2__SDHC0_CLK	0x40
+			IMX7ULP_PAD_PTD7__SDHC0_D3	0x41
+			IMX7ULP_PAD_PTD8__SDHC0_D2	0x41
+			IMX7ULP_PAD_PTD9__SDHC0_D1	0x41
+			IMX7ULP_PAD_PTD10__SDHC0_D0	0x41
+			IMX7ULP_PAD_PTC10__PTC10	0x1	/* CD */
+		>;
+	};
+
+	pinctrl_usdhc0_rst: usdhc0-gpio-rst-grp {
+		fsl,pins = <
+			IMX7ULP_PAD_PTD0__PTD0		0x1
+		>;
+	};
+};
-- 
2.7.4

Re: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[Fabio Estevam]

Hi Dong,

On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> wrote:

> +       reg_vsd_3v3: regulator-vsd-3v3 {
> +               compatible = "regulator-fixed";
> +               regulator-name = "VSD_3V3";
> +               regulator-min-microvolt = <3300000>;
> +               regulator-max-microvolt = <3300000>;
> +               pinctrl-names = "default";
> +               pinctrl-0 = <&pinctrl_usdhc0_rst>;
> +               gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>;
> +               enable-active-high;

You model this as a regulator...

> +&usdhc0 {
> +       pinctrl-names = "default";
> +       pinctrl-0 = <&pinctrl_usdhc0>;
> +       cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>;
> +       vmmc-supply = <&reg_vsd_3v3>;

but as this pins controls the reset of the SD port it seems that using
mmc-pwrseq would be more appropriate.

This way you could pass 'reset-gpios' inside the pwrseq node, which
would describe the hardware more accurately.

Re: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[Fabio Estevam]

On Thu, Nov 1, 2018 at 7:28 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Dong,
>
> On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com> wrote:
>
> > +       reg_vsd_3v3: regulator-vsd-3v3 {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "VSD_3V3";
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&pinctrl_usdhc0_rst>;
> > +               gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>;
> > +               enable-active-high;
>
> You model this as a regulator...
>
> > +&usdhc0 {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&pinctrl_usdhc0>;
> > +       cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>;
> > +       vmmc-supply = <&reg_vsd_3v3>;
>
> but as this pins controls the reset of the SD port it seems that using
> mmc-pwrseq would be more appropriate.
>
> This way you could pass 'reset-gpios' inside the pwrseq node, which
> would describe the hardware more accurately.

Just looked at the schematics and the SD0_nRST signals is only used
when the eMMC is populated.

As you are only defining SD0_DATA0-DATA3 it means you are using the
microSD option (option 1 as per the schematics).

In the microSD option the SD0_nRST is not used, so better not to
describe it in device tree.

RE: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Thursday, November 1, 2018 6:28 PM
[...]
> Hi Dong,
> 
> On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com>
> wrote:
> 
> > +       reg_vsd_3v3: regulator-vsd-3v3 {
> > +               compatible = "regulator-fixed";
> > +               regulator-name = "VSD_3V3";
> > +               regulator-min-microvolt = <3300000>;
> > +               regulator-max-microvolt = <3300000>;
> > +               pinctrl-names = "default";
> > +               pinctrl-0 = <&pinctrl_usdhc0_rst>;
> > +               gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>;
> > +               enable-active-high;
> 
> You model this as a regulator...
> 
> > +&usdhc0 {
> > +       pinctrl-names = "default";
> > +       pinctrl-0 = <&pinctrl_usdhc0>;
> > +       cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>;
> > +       vmmc-supply = <&reg_vsd_3v3>;
> 
> but as this pins controls the reset of the SD port it seems that using
> mmc-pwrseq would be more appropriate.
> 
> This way you could pass 'reset-gpios' inside the pwrseq node, which would
> describe the hardware more accurately.

This seems a bit confusing to me.
That GPIO is used to control the SD card power on/off. So it's naturally a
GPIO regulator. Looking at exist IMX dts, you will find all similar board doing
like this. Pwrseq seems more like to be used for WiFi/eMMC card.
Am I missed something?

Regards
Dong Aisheg

RE: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Thursday, November 1, 2018 6:36 PM
[...]
> 
> On Thu, Nov 1, 2018 at 7:28 AM Fabio Estevam <festevam@gmail.com>
> wrote:
> >
> > Hi Dong,
> >
> > On Wed, Oct 31, 2018 at 11:46 AM A.s. Dong <aisheng.dong@nxp.com>
> wrote:
> >
> > > +       reg_vsd_3v3: regulator-vsd-3v3 {
> > > +               compatible = "regulator-fixed";
> > > +               regulator-name = "VSD_3V3";
> > > +               regulator-min-microvolt = <3300000>;
> > > +               regulator-max-microvolt = <3300000>;
> > > +               pinctrl-names = "default";
> > > +               pinctrl-0 = <&pinctrl_usdhc0_rst>;
> > > +               gpio = <&gpio_ptd 0 GPIO_ACTIVE_HIGH>;
> > > +               enable-active-high;
> >
> > You model this as a regulator...
> >
> > > +&usdhc0 {
> > > +       pinctrl-names = "default";
> > > +       pinctrl-0 = <&pinctrl_usdhc0>;
> > > +       cd-gpios = <&gpio_ptc 10 GPIO_ACTIVE_LOW>;
> > > +       vmmc-supply = <&reg_vsd_3v3>;
> >
> > but as this pins controls the reset of the SD port it seems that using
> > mmc-pwrseq would be more appropriate.
> >
> > This way you could pass 'reset-gpios' inside the pwrseq node, which
> > would describe the hardware more accurately.
> 
> Just looked at the schematics and the SD0_nRST signals is only used when the
> eMMC is populated.
> 
> As you are only defining SD0_DATA0-DATA3 it means you are using the
> microSD option (option 1 as per the schematics).
> 
> In the microSD option the SD0_nRST is not used, so better not to describe it in
> device tree.

Can you tell which version were you looking at?
>From my version SPF-29163_A1, it's populated by default.

Regards
Dong Aisheng

Re: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[Fabio Estevam]

On Thu, Nov 1, 2018 at 12:49 PM A.s. Dong <aisheng.dong@nxp.com> wrote:

> This seems a bit confusing to me.
> That GPIO is used to control the SD card power on/off. So it's naturally a
> GPIO regulator. Looking at exist IMX dts, you will find all similar board doing
> like this. Pwrseq seems more like to be used for WiFi/eMMC card.
> Am I missed something?

As per the board schematics the name of the signal is SD0_nRST, where
RST means "reset".

There is even this note in the schematics: "ROM Code will reset the SD
power during boot up through SD_RST".

eMMC reset is better handled by 'reset-gpios' property from pwrseq.

Re: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[Fabio Estevam]

On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com> wrote:

> Can you tell which version were you looking at?
> From my version SPF-29163_A1, it's populated by default.

Mine is sch-29163-b and it shows both micro SD card and eMMC on the schematics.

On my board I see only the micro SD card populated, not the eMMC.

Also, if you are describing the eMMC then why do you pass the card
detect property and only 4 data lines?

SD0_nRST is only connected to the eMMC card.

eMMC does not have card detect signal and it uses 8 data lines, so
clearly there is something inconsistent in your dts.

What exactly do you want to describe: the SD card or the eMMC?

RE: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Thursday, November 1, 2018 11:57 PM
[...]
> 
> On Thu, Nov 1, 2018 at 12:49 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
> 
> > This seems a bit confusing to me.
> > That GPIO is used to control the SD card power on/off. So it's
> > naturally a GPIO regulator. Looking at exist IMX dts, you will find
> > all similar board doing like this. Pwrseq seems more like to be used for
> WiFi/eMMC card.
> > Am I missed something?
> 
> As per the board schematics the name of the signal is SD0_nRST, where RST
> means "reset".
> 

I guess you may also notice that circuit name above that signal is
" Power Switch for SD3.0".

> There is even this note in the schematics: "ROM Code will reset the SD power
> during boot up through SD_RST".
> 

Yes, but it's more like a RESET.

> eMMC reset is better handled by 'reset-gpios' property from pwrseq.

It's not eMMC.

Let's see more in binding doc:
Required properties:
- compatible : contains "mmc-pwrseq-simple".

Optional properties:
- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted
        at initialization and prior we start the power up procedure of the card.
        They will be de-asserted right after the power has been provided to the
        card.
That looks more like an auxiliary GPIO reset pin which is used along with normal
power up process (see. mmc_power_up ()) which may be commonly used for
WiFi cards. 

But for SD card with a single supply, GPIO regulator seems enough to me.
That's also the using in past years. Are things changed?

Regards
Dong Aisheng

RE: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Friday, November 2, 2018 12:01 AM
[...]
> 
> On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com> wrote:
> 
> > Can you tell which version were you looking at?
> > From my version SPF-29163_A1, it's populated by default.
> 
> Mine is sch-29163-b and it shows both micro SD card and eMMC on the
> schematics.
> 

I will check it later. But Rev B may be supported later if changed.

> On my board I see only the micro SD card populated, not the eMMC.
> 
> Also, if you are describing the eMMC then why do you pass the card detect
> property and only 4 data lines?
> 
> SD0_nRST is only connected to the eMMC card.
> 
> eMMC does not have card detect signal and it uses 8 data lines, so clearly
> there is something inconsistent in your dts.
> 
> What exactly do you want to describe: the SD card or the eMMC?

I guess we're talking about different schematic versions.
The patch is supposed to support Rev A.

Regards
Dong Aisheng

RE: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[A.s. Dong]

[...]

> > -----Original Message-----
> > From: Fabio Estevam [mailto:festevam@gmail.com]
> > Sent: Friday, November 2, 2018 12:01 AM
> [...]
> >
> > On Thu, Nov 1, 2018 at 12:53 PM A.s. Dong <aisheng.dong@nxp.com>
> wrote:
> >
> > > Can you tell which version were you looking at?
> > > From my version SPF-29163_A1, it's populated by default.
> >
> > Mine is sch-29163-b and it shows both micro SD card and eMMC on the
> > schematics.
> >
> 
> I will check it later. But Rev B may be supported later if changed.
> 
> > On my board I see only the micro SD card populated, not the eMMC.
> >
> > Also, if you are describing the eMMC then why do you pass the card
> > detect property and only 4 data lines?
> >
> > SD0_nRST is only connected to the eMMC card.
> >
> > eMMC does not have card detect signal and it uses 8 data lines, so
> > clearly there is something inconsistent in your dts.
> >
> > What exactly do you want to describe: the SD card or the eMMC?
> 
> I guess we're talking about different schematic versions.
> The patch is supposed to support Rev A.
> 

I just checked RevB schematic and SD card circuit seems the same
as Rev A that SD0_nRST is used to control the SD power and there's CD pin.
So the SD binding should work for both.

Regards
Dong Aisheng

Re: [PATCH V3 09/10] dts: fsl: add imx7ulp evk support

[Fabio Estevam]

On Thu, Nov 1, 2018 at 1:21 PM A.s. Dong <aisheng.dong@nxp.com> wrote:

> But for SD card with a single supply, GPIO regulator seems enough to me.
> That's also the using in past years. Are things changed?

Ok, now it clear you are describing the micro SD port and not the eMMC, so:

Reviewed-by: Fabio Estevam <festevam@gmail.com>

Re: [PATCH V3 03/10] dt-bindings: gpio: vf610: add optional clocks property

[Linus Walleij]

On Wed, Oct 31, 2018 at 3:43 PM A.s. Dong <aisheng.dong@nxp.com> wrote:

> On some SoCs(e.g. MX7ULP), GPIO clock is gatable and maybe
> disabled by default. Users have to make sure it's enabled before
> being able to access controller registers, otherwise an external
> abort error may occur. Let's add the optional clocks property to
> handle this case.
>
> For ULP GPIO clock, it includes two separate clocks: one is for
> GPIO controller Input/Output function clock while another is
> GPIO port control clock for interrupt function.
>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stefan Agner <stefan@agner.ch>
> Cc: linux-gpio@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>

Patch applied.

Yours,
Linus Walleij