ARM: imx: add imx7ulp support

Add imx7ulp pm related components bindings

Cc Rob Herring <[email protected]>

Cc Shawn Guo <[email protected]>

Cc devicetree at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

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

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 <[email protected]>

Cc Rob Herring <[email protected]>

Cc Mark Rutland <[email protected]>

Cc Stefan Agner <[email protected]>

Cc linux-gpio at vger.kernel.org

Cc devicetree at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

---
v1->v2:
* new patch

---
 Documentation/devicetree/bindings/gpio/gpio-vf610.txt | 6 ++++++
 1 file changed, 6 insertions(+)

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
Sent: Tuesday, October 23, 2018 8:04 PM

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 288

Quoted 4 lines

drivers/gpio/gpio-vf610.c +4 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");
+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {

	if (clk_gpio == ERR_PTR(-EPROBE_DEFER) ||
	    clk_port == ERR_PTR(-EPROBE_DEFER)) {

--
RMK's Patch system:
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
armlinux.org.uk%2Fdeveloper%2Fpatches%2F&amp;data=02%7C01%7Caishen g.dong%40nxp.com%7C34fcfce2f5d042efd0b808d638dfaaed%7C686ea1d3bc 2b4c6fa92cd99c5c301635%7C0%7C0%7C636758930627945785&amp;sdata= PME05RkmX0mxRmhO%2Bj%2FofV3VN2VMx3FWU9bbqFr3XAg%3D&amp;res erved=0
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up

Hi Russell,

Quoted 3 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
Sent: Tuesday, October 23, 2018 8:04 PM

[...]

Quoted 9 lines · A.s. Dong

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 288

Quoted 4 lines

drivers/gpio/gpio-vf610.c +4 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");
+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {

	if (clk_gpio == ERR_PTR(-EPROBE_DEFER) ||
	    clk_port == ERR_PTR(-EPROBE_DEFER)) {

Thanks for the suggestion. I will update it in next series. Before that, let's wait a moment to see if any more review comments.

BTW, as I see kernel currently is widely using PTR_ERR(ptr) to compare -EPROBE_DEFER, I'm not quite get the point why the new approach you suggested is better, is it less error-prone? Or something else? would you please help clarify a bit more?

-----Original Message-----
From: Uwe Kleine-K?nig [mailto:u.kleine-koenig at pengutronix.de]
Sent: Tuesday, October 23, 2018 8:42 PM
To: A.s. Dong <[email protected]>
Cc: Russell King - ARM Linux <[email protected]>; dongas86 at gmail.com; Linus Walleij <[email protected]>; Stefan Agner <[email protected]>; linux-gpio at vger.kernel.org; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org; linux-arm-kernel at lists.infradead.org
Subject: Re: [PATCH V2 4/8] gpio: vf610: add optional clock support

Quoted 19 lines · A.s. Dong

Hi Russell,

Quoted 3 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at armlinux.org.uk]
Sent: Tuesday, October 23, 2018 8:04 PM

[...]

Quoted 9 lines · A.s. Dong

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 288

Quoted 4 lines

drivers/gpio/gpio-vf610.c +4 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");
+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {

	if (clk_gpio == ERR_PTR(-EPROBE_DEFER) ||
	    clk_port == ERR_PTR(-EPROBE_DEFER)) {

Thanks for the suggestion. I will update it in next series. Before that, let's wait a moment to see if any more review comments.

Quoted 4 lines

BTW, as I see kernel currently is widely using PTR_ERR(ptr) to compare -EPROBE_DEFER, I'm not quite get the point why the new approach you suggested is better, is it less error-prone? Or something else? would you please help clarify a bit more?

See the discussion in
https://lore.kernel.org/patchwork/patch/999602/

Best regards
Uwe

--
Pengutronix e.K. | Uwe Kleine-K?nig
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C06 5f26466899474bf61a08d638e4e308%7C686ea1d3bc2b4c6fa92cd99c5c3016 35%7C0%7C0%7C636758953039817883&amp;sdata=hSgiadfyiFoK4AVTF2BR guOU5H8C77%2BY2bdjViC4Sfw%3D&amp;reserved=0 |

Some SoCs need the gpio clock to be enabled before accessing HW registers. This patch add the optional clock handling.

Cc Linus Walleij <[email protected]>

Cc Stefan Agner <[email protected]>

Cc Shawn Guo <[email protected]>

Cc linux-gpio at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

---
v1->v2:
* new patch

---
 drivers/gpio/gpio-vf610.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/gpio/gpio-vf610.c +2 -0

index d4ad6d0..cbc4f44 100644
@@ -16,6 +16,7 @@
  */
 
 #include <linux/bitops.h>
+#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
 #include <linux/init.h>

@@ -256,6 +257,7 @@ static int vf610_gpio_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct clk *clk_gpio, *clk_port;
 	struct vf610_gpio_port *port;
 	struct resource *iores;
 	struct gpio_chip *gc;

drivers/gpio/gpio-vf610.c +16 -0

+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {
+		return -EPROBE_DEFER;
+	} else if (!IS_ERR_OR_NULL(clk_gpio) &&
+		   !IS_ERR_OR_NULL(clk_port)) {
+		ret = clk_prepare_enable(clk_gpio);
+		if (ret)
+			return ret;
+
+		ret = clk_prepare_enable(clk_port);
+		if (ret) {
+			clk_disable_unprepare(clk_gpio);
+			return ret;
+		}
+	}
+
 	gc = &port->gc;
 	gc->of_node = np;
 	gc->parent = dev;

-----Original Message-----
From: Stefan Agner [mailto:stefan at agner.ch]
Sent: Friday, October 26, 2018 1:59 AM

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device

Quoted 36 lines

Some SoCs need the gpio clock to be enabled before accessing HW registers. This patch add the optional clock handling.

Cc Linus Walleij <[email protected]>

Cc Stefan Agner <[email protected]>

Cc Shawn Guo <[email protected]>

Cc linux-gpio at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

---
v1->v2:
* new patch

---
 drivers/gpio/gpio-vf610.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/gpio/gpio-vf610.c +2 -0

index d4ad6d0..cbc4f44 100644
@@ -16,6 +16,7 @@
  */
 
 #include <linux/bitops.h>
+#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
 #include <linux/init.h>

@@ -256,6 +257,7 @@ static int vf610_gpio_probe(struct platform_device
 *pdev)  {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct clk *clk_gpio, *clk_port;
 	struct vf610_gpio_port *port;
 	struct resource *iores;
 	struct gpio_chip *gc;

@@ -280,6 +282,24 @@ static int vf610_gpio_probe(struct platform_device

*pdev)

Quoted 3 lines

drivers/gpio/gpio-vf610.c +0 -0

 	if (port->irq < 0)
 		return port->irq;
 

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 286

Quoted 2 lines

drivers/gpio/gpio-vf610.c +2 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");

Are you sure that those are two independent clocks? On i.MX 7 usually there was a single clock gate controlling multiple clocks at once (which should be modeled as a single clock gate in the clock tree).

--
Stefan

Quoted 19 lines

drivers/gpio/gpio-vf610.c +16 -0

+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {
+		return -EPROBE_DEFER;
+	} else if (!IS_ERR_OR_NULL(clk_gpio) &&
+		   !IS_ERR_OR_NULL(clk_port)) {
+		ret = clk_prepare_enable(clk_gpio);
+		if (ret)
+			return ret;
+
+		ret = clk_prepare_enable(clk_port);
+		if (ret) {
+			clk_disable_unprepare(clk_gpio);
+			return ret;
+		}
+	}
+
 	gc = &port->gc;
 	gc->of_node = np;
 	gc->parent = dev;

Quoted 3 lines

-----Original Message-----
From: Stefan Agner [mailto:stefan at agner.ch]
Sent: Friday, October 26, 2018 1:59 AM

[...]

Quoted 42 lines · A.s. Dong

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device

Quoted 36 lines

Some SoCs need the gpio clock to be enabled before accessing HW registers. This patch add the optional clock handling.

Cc Linus Walleij <[email protected]>

Cc Stefan Agner <[email protected]>

Cc Shawn Guo <[email protected]>

Cc linux-gpio at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

---
v1->v2:
* new patch

---
 drivers/gpio/gpio-vf610.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/gpio/gpio-vf610.c +2 -0

index d4ad6d0..cbc4f44 100644
@@ -16,6 +16,7 @@
  */
 
 #include <linux/bitops.h>
+#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
 #include <linux/init.h>

@@ -256,6 +257,7 @@ static int vf610_gpio_probe(struct platform_device
 *pdev)  {
 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct clk *clk_gpio, *clk_port;
 	struct vf610_gpio_port *port;
 	struct resource *iores;
 	struct gpio_chip *gc;

@@ -280,6 +282,24 @@ static int vf610_gpio_probe(struct platform_device

*pdev)

Quoted 3 lines

drivers/gpio/gpio-vf610.c +0 -0

 	if (port->irq < 0)
 		return port->irq;
 

Quoted 7 lines

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 286

Quoted 2 lines

drivers/gpio/gpio-vf610.c +2 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");

Are you sure that those are two independent clocks? On i.MX 7 usually there was a single clock gate controlling multiple clocks at once (which should be modeled as a single clock gate in the clock tree).

Yes, they're two separate clocks in HW for gpio and port controller respectively.
One is for GPIO general purpose input/output function which another for port Interrupt.
Just like we have separate register ranges for gpio and port.

Regards
Dong Aisheng

Quoted 22 lines

--
Stefan

Quoted 19 lines

drivers/gpio/gpio-vf610.c +16 -0

+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {
+		return -EPROBE_DEFER;
+	} else if (!IS_ERR_OR_NULL(clk_gpio) &&
+		   !IS_ERR_OR_NULL(clk_port)) {
+		ret = clk_prepare_enable(clk_gpio);
+		if (ret)
+			return ret;
+
+		ret = clk_prepare_enable(clk_port);
+		if (ret) {
+			clk_disable_unprepare(clk_gpio);
+			return ret;
+		}
+	}
+
 	gc = &port->gc;
 	gc->of_node = np;
 	gc->parent = dev;

Quoted 56 lines

Quoted 3 lines

-----Original Message-----
From: Stefan Agner [mailto:stefan at agner.ch]
Sent: Friday, October 26, 2018 1:59 AM

[...]

Quoted 44 lines · A.s. Dong

Quoted 37 lines

Some SoCs need the gpio clock to be enabled before accessing HW registers. This patch add the optional clock handling.

Cc Linus Walleij <[email protected]>

Cc Stefan Agner <[email protected]>

Cc Shawn Guo <[email protected]>

Cc linux-gpio at vger.kernel.org

Signed-off-by Dong Aisheng <[email protected]>

---
v1->v2:
* new patch

---
 drivers/gpio/gpio-vf610.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

drivers/gpio/gpio-vf610.c +1 -0

index d4ad6d0..cbc4f44 100644
@@ -16,6 +16,7 @@
  */
 
 #include <linux/bitops.h>
+#include <linux/clk.h>
 #include <linux/err.h>
 #include <linux/gpio.h>
 #include <linux/init.h>

@@ -256,6 +257,7 @@ static int vf610_gpio_probe(struct

platform_device
*pdev) {

drivers/gpio/gpio-vf610.c +1 -0

 	struct device *dev = &pdev->dev;
 	struct device_node *np = dev->of_node;
+	struct clk *clk_gpio, *clk_port;
 	struct vf610_gpio_port *port;
 	struct resource *iores;
 	struct gpio_chip *gc;

@@ -280,6 +282,24 @@ static int vf610_gpio_probe(struct

Quoted 1 line

platform_device

*pdev)

Quoted 3 lines

drivers/gpio/gpio-vf610.c +0 -0

 	if (port->irq < 0)
 		return port->irq;

Quoted 7 lines

drivers/gpio/gpio-vf610.c static int vf610_gpio_probe(struct platform_device *pdev) · line 286

Quoted 2 lines

drivers/gpio/gpio-vf610.c +2 -0

+	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
+	clk_port = devm_clk_get(&pdev->dev, "port");

Are you sure that those are two independent clocks? On i.MX 7 usually there was a single clock gate controlling multiple clocks at once (which should be modeled as a single clock gate in the clock tree).

Quoted 5 lines

Yes, they're two separate clocks in HW for gpio and port controller respectively.
One is for GPIO general purpose input/output function which another for port Interrupt.
Just like we have separate register ranges for gpio and port.

Oh I see, that is the same with Vybrid actually. However, in Vybrid, for some reason, there is only a clock for port (Port X multiplexing control).

Can we make port clock independently optional?

E.g.

	clk_port = devm_clk_get(&pdev->dev, "port");
	if (clk_gpio == ERR_PTR(-EPROBE_DEFER))
		return -EPROBE_DEFER;

	clk_gpio = devm_clk_get(&pdev->dev, "gpio");
	if (clk_gpio == ERR_PTR(-EPROBE_DEFER))
		return -EPROBE_DEFER;

	if (!IS_ERR_OR_NULL(clk_port)) {
		ret = clk_prepare_enable(clk_port);
		if (ret)
			return ret;
	}

	if (!IS_ERR_OR_NULL(clk_gpio))
		ret = clk_prepare_enable(clk_gpio);
		if (ret) {
			clk_disable_unprepare(clk_port);
			return ret;
		}
	}

Also there is some error handling a bit further down which needs proper disabling the clocks.

--
Stefan

Quoted 26 lines

Regards
Dong Aisheng

Quoted 22 lines

--
Stefan

Quoted 19 lines

drivers/gpio/gpio-vf610.c +16 -0

+	if ((PTR_ERR(clk_gpio) == -EPROBE_DEFER) ||
+	    (PTR_ERR(clk_port) == -EPROBE_DEFER)) {
+		return -EPROBE_DEFER;
+	} else if (!IS_ERR_OR_NULL(clk_gpio) &&
+		   !IS_ERR_OR_NULL(clk_port)) {
+		ret = clk_prepare_enable(clk_gpio);
+		if (ret)
+			return ret;
+
+		ret = clk_prepare_enable(clk_port);
+		if (ret) {
+			clk_disable_unprepare(clk_gpio);
+			return ret;
+		}
+	}
+
 	gc = &port->gc;
 	gc->of_node = np;
 	gc->parent = dev;

The i.MX 7ULP family of processors represents NXP?s latest achievement in ultra-low-power processing for use cases demanding long battery life. Targeted towards the growing market of portable devices, 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 <[email protected]>

Cc Shawn Guo <[email protected]>

Cc devicetree at vger.kernel.org

Cc Sascha Hauer <[email protected]>

Cc Fabio Estevam <[email protected]>

Signed-off-by Dong Aisheng <[email protected]>

---
ChangeLog:
v1->v2:
* update clk part due to binding change
* separate soc.dtsi from board.dts

---
 arch/arm/boot/dts/imx7ulp.dtsi | 323 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 323 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7ulp.dtsi

arch/arm/boot/dts/imx7ulp.dtsi new file +88 -0

new file mode 100644
index 0000000..795edc2
@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ *   Dong Aisheng <[email protected]>
+ */
+
+#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 at 0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	intc: interrupt-controller at 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>;
+	};
+

arch/arm/boot/dts/imx7ulp.dtsi new file +33 -0

+	};
+
+	ahbbridge0: bus at 40000000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x40000000 0x800000>;
+		ranges;
+
+		lpuart4: serial at 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 at 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";
+		};
+

arch/arm/boot/dts/imx7ulp.dtsi new file +6 -0

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

arch/arm/boot/dts/imx7ulp.dtsi new file +6 -0

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

arch/arm/boot/dts/imx7ulp.dtsi new file +4 -0

+			compatible = "fsl,imx7ulp-pcc3";
+			reg = <0x40b30000 0x10000>;
+			#clock-cells = <1>;
+		};

arch/arm/boot/dts/imx7ulp.dtsi new file +26 -0

+			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 at 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 at 40a70000 {
+			compatible = "fsl,imx7ulp-lpuart";
+			reg = <0x40a70000 0x1000>;

arch/arm/boot/dts/imx7ulp.dtsi new file +61 -0

+			compatible = "fsl,imx7ulp-iomuxc1";
+			reg = <0x40ac0000 0x1000>;
+		};
+
+		gpio_ptc: gpio at 40ae0000 {
+			compatible = "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 at 40af0000 {
+			compatible = "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 at 40b00000 {
+			compatible = "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 at 40b10000 {
+			compatible = "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>;
+		};
+	};
+};

Signature · 1 line

2.7.4

-----Original Message-----
From: Rob Herring [mailto:robh at kernel.org]
Sent: Thursday, October 25, 2018 6:02 AM

Quoted 126 lines

The i.MX 7ULP family of processors represents NXP?s latest achievement in ultra-low-power processing for use cases demanding long battery life. Targeted towards the growing market of portable devices, 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 <[email protected]>

Cc Shawn Guo <[email protected]>

Cc devicetree at vger.kernel.org

Cc Sascha Hauer <[email protected]>

Cc Fabio Estevam <[email protected]>

Signed-off-by Dong Aisheng <[email protected]>

---
ChangeLog:
v1->v2:
* update clk part due to binding change
* separate soc.dtsi from board.dts

---
 arch/arm/boot/dts/imx7ulp.dtsi | 323
+++++++++++++++++++++++++++++++++++++++++
 1 file changed, 323 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx7ulp.dtsi

(quoted diff) +0 -0

b/arch/arm/boot/dts/imx7ulp.dtsi new file mode 100644 index 0000000..795edc2

arch/arm/boot/dts/imx7ulp.dtsi new file +88 -0

@@ -0,0 +1,323 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017-2018 NXP
+ *   Dong Aisheng <[email protected]>
+ */
+
+#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 at 0 {
+			compatible = "arm,cortex-a7";
+			device_type = "cpu";
+			reg = <0>;
+		};
+	};
+
+	intc: interrupt-controller at 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>;
+	};
+

arch/arm/boot/dts/imx7ulp.dtsi line 98

Quoted 10 lines

arch/arm/boot/dts/imx7ulp.dtsi new file +10 -0

+	mpll: clock-mpll {
+		compatible = "fixed-clock";
+		clock-frequency = <480000000>;
+		clock-output-names = "mpll";
+		#clock-cells = <0>;
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		arm,cpu-registers-not-fw-configured;

AIUI, this was a work-around for some existing platform. New platforms should not have this property.

arch/arm/boot/dts/imx7ulp.dtsi line 99

Quoted 1 line

arch/arm/boot/dts/imx7ulp.dtsi new file +1 -0

+		interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) |

IRQ_TYPE_LEVEL_LOW)>,

arch/arm/boot/dts/imx7ulp.dtsi line 100

Quoted 1 line

arch/arm/boot/dts/imx7ulp.dtsi new file +1 -0

+			     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) |

IRQ_TYPE_LEVEL_LOW)>;

arch/arm/boot/dts/imx7ulp.dtsi line 101

Quoted 1 line

arch/arm/boot/dts/imx7ulp.dtsi new file +1 -0

+		clock-frequency = <1000000>;

This too should be initialized by firmware and not in DT IIRC.

arch/arm/boot/dts/imx7ulp.dtsi line 102

Quoted 1 line

arch/arm/boot/dts/imx7ulp.dtsi new file +1 -0

+		status = "disabled";

I think enabled should be the norm.

Quoted 7 lines

arch/arm/boot/dts/imx7ulp.dtsi new file +7 -0

+	};
+
+	ahbbridge0: bus at 40000000 {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x40000000 0x800000>;

arch/arm/boot/dts/imx7ulp.dtsi

Quoted 10 lines

arch/arm/boot/dts/imx7ulp.dtsi new file +10 -0

+		ranges;
+
+		lpuart4: serial at 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>;

Quoted 20 lines

arch/arm/boot/dts/imx7ulp.dtsi new file +20 -0

+			assigned-clock-rates = <24000000>;
+			status = "disabled";
+		};
+
+		lpuart5: serial at 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 at 40260000 {
+			compatible = "fsl,imx7ulp-tpm";
+			reg = <0x40260000 0x1000>;
+			interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>;

arch/arm/boot/dts/imx7ulp.dtsi line 145

Quoted 6 lines

arch/arm/boot/dts/imx7ulp.dtsi new file +6 -0

+			clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>,
+				 <&pcc2 IMX7ULP_CLK_LPTPM5>;
+			clock-names = "ipg", "per";
+		};
+
+		usdhc0: usdhc at 40370000 {

mmc at ... is the standard name.

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Friday, October 26, 2018 12:44 AM

Review

Quoted 3 lines

(quoted diff) +2 -0

+               gpio_ptc: gpio at 40ae0000 {
+                       compatible = "fsl,vf610-gpio";

This should be:

compatible = "fsl,imx7ulp-gpio", "fsl,vf610-gpio";

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Tuesday, October 23, 2018 8:29 PM

arch/arm/boot/dts/imx7ulp-evk.dts

Quoted 5 lines

arch/arm/boot/dts/imx7ulp-evk.dts new file +4 -0

+/ {
+       model = "NXP i.MX7ULP EVK";
+       compatible = "fsl,imx7ulp-evk", "fsl,imx7ulp", "Generic DT
+based system";

This "Generic DT based system" should be removed.

arch/arm/boot/dts/imx7ulp-evk.dts line 20

Quoted 5 lines

arch/arm/boot/dts/imx7ulp-evk.dts new file +5 -0

+       chosen {
+               stdout-path = &lpuart4;
+       };
+
+       memory at 60000000 {

       device_type = "memory";

arch/arm/boot/dts/imx7ulp-evk.dts line 57

Quoted 10 lines

arch/arm/boot/dts/imx7ulp-evk.dts new file +9 -0

+               reg = <0x60000000 0x40000000>;
+       };
 
+&iomuxc1 {
+       pinctrl_lpuart4: lpuart4grp {
+               pinmux = <
+                       IMX7ULP_PAD_PTC3__LPUART4_RX
+                       IMX7ULP_PAD_PTC2__LPUART4_TX
+               >;
+               bias-pull-up;

Please change the mx7ulp pinctrl driver to accept the "old" notation and change the dts to use:

IMX7ULP_PAD_PTC3__LPUART4_RX 0x3

This way we use the same method for all i.MX devices.

I'm a bit hesitate to do that as the driver already supports it. There's no extra effort to use it. And we probably could take ULP as a special case to test generic binding rather then simply drop it and drop driver features. Once we get objection from users later, we still can simply fallback as there's still only official boards using it.

Last, it's not correct that there's not only one method for all i.MX devices. MX23/28 are different ones and ULP is more like MX23/28.
And I saw no objections from users for MX23/28.

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Wednesday, October 24, 2018 12:26 AM

Quoted 5 lines

I'm a bit hesitate to do that as the driver already supports it. There's no extra effort to use it. And we probably could take ULP as a special case to test generic binding rather then simply drop it and drop driver features. Once we get objection from users later, we still can

simply fallback as there's still only official boards using it.

We had this same discussion some months ago when we were reviewing i.MX8 support.

I don't see the value in doing pinctrl differently on i.MX7ULP.

Quoted 3 lines

Last, it's not correct that there's not only one method for all i.MX devices. MX23/28 are different ones and ULP is more like MX23/28.
And I saw no objections from users for MX23/28.

Yes, but these are legacy platforms.

For new ones, we should try to keep consistency, just like we discussed during i.MX8 review.

-----Original Message-----
From: A.s. Dong
Sent: Wednesday, October 24, 2018 4:14 PM

Quoted 3 lines

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Wednesday, October 24, 2018 12:26 AM

[...]

Quoted 1 line

On Tue, Oct 23, 2018 at 11:42 AM A.s. Dong <[email protected]>

Quoted 6 lines · wrote:

Quoted 6 lines

I'm a bit hesitate to do that as the driver already supports it. There's no extra effort to use it. And we probably could take ULP as a special case to test generic binding rather then simply drop it and drop driver features. Once we get objection from users later, we still can

Quoted 7 lines

simply fallback as there's still only official boards using it.

We had this same discussion some months ago when we were reviewing i.MX8 support.

I don't see the value in doing pinctrl differently on i.MX7ULP.

I thought the situation is different as ULP actually already supports generic binding before that discussion.

Quoted 9 lines

Quoted 3 lines

Last, it's not correct that there's not only one method for all i.MX devices. MX23/28 are different ones and ULP is more like MX23/28.
And I saw no objections from users for MX23/28.

Yes, but these are legacy platforms.

For new ones, we should try to keep consistency, just like we discussed during
i.MX8 review.

So the question is whether it's necessary to switch generic binding back to the legacy one for ULP. Personally I'm not strongly against this, but I need some confirmation from Shawn and Sascha.

Shawn & Sascha, would you make a judgement call?
If you also strongly request that, I will try to make it patch to test Linus W. Hopefully our agreement could satisfy Linus W.

Regards
Dong Aisheng

Quoted 3 lines

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Wednesday, October 24, 2018 12:26 AM

[...]

Quoted 6 lines · A.s. Dong

Quoted 5 lines

I'm a bit hesitate to do that as the driver already supports it. There's no extra effort to use it. And we probably could take ULP as a special case to test generic binding rather then simply drop it and drop driver features. Once we get objection from users later, we still can

Quoted 7 lines

simply fallback as there's still only official boards using it.

We had this same discussion some months ago when we were reviewing i.MX8 support.

I don't see the value in doing pinctrl differently on i.MX7ULP.

I thought the situation is different as ULP actually already supports generic binding before that discussion.

Quoted 8 lines

Quoted 3 lines

Last, it's not correct that there's not only one method for all i.MX devices. MX23/28 are different ones and ULP is more like MX23/28.
And I saw no objections from users for MX23/28.

Yes, but these are legacy platforms.

For new ones, we should try to keep consistency, just like we discussed during i.MX8 review.

So the question is whether it's necessary to switch generic binding back to the legacy one for ULP. Personally I'm not strongly against this, but I need some confirmation from Shawn and Sascha.

Shawn & Sascha, would you make a judgement call?
If you also strongly request that, I will try to make it patch to test Linus W. Hopefully our agreement could satisfy Linus W.

-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Friday, October 26, 2018 6:57 PM

Quoted 5 lines

Quoted 3 lines

-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Wednesday, October 24, 2018 12:26 AM

[...]

Quoted 1 line

On Tue, Oct 23, 2018 at 11:42 AM A.s. Dong <[email protected]>

Quoted 31 lines · wrote:

Quoted 6 lines

Quoted 6 lines

I'm a bit hesitate to do that as the driver already supports it. There's no extra effort to use it. And we probably could take ULP as a special case to test generic binding rather then simply drop it and drop driver features. Once we get objection from users later, we still can

Quoted 7 lines

simply fallback as there's still only official boards using it.

We had this same discussion some months ago when we were reviewing i.MX8 support.

I don't see the value in doing pinctrl differently on i.MX7ULP.

I thought the situation is different as ULP actually already supports generic binding before that discussion.

Quoted 9 lines

Quoted 3 lines

Last, it's not correct that there's not only one method for all i.MX devices. MX23/28 are different ones and ULP is more like MX23/28.
And I saw no objections from users for MX23/28.

Yes, but these are legacy platforms.

For new ones, we should try to keep consistency, just like we discussed during
i.MX8 review.

So the question is whether it's necessary to switch generic binding back to the legacy one for ULP. Personally I'm not strongly against this, but I need some confirmation from Shawn and Sascha.

Quoted 3 lines

Shawn & Sascha, would you make a judgement call?
If you also strongly request that, I will try to make it patch to test Linus W. Hopefully our agreement could satisfy Linus W.

For consistency reasons I vote for using the legacy binding for i.MX7ulp aswell.

Sascha

--
Pengutronix e.K. |
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&amp;data=02%7C01%7Caisheng.dong%40nxp.com%7C74 a0d2aca1cf432528a608d63b31c614%7C686ea1d3bc2b4c6fa92cd99c5c3016 35%7C0%7C0%7C636761482309424341&amp;sdata=Mi5aWJmBcYI3xZLsEdj O%2BQ7JUKZS1EzXuW%2Bd2WBJtek%3D&amp;reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |