ARM64: add basic Kconfig symbols for i.MX8
Subsystems (6)
PATCH 1/4 ARM64: add basic Kconfig symbols for i.MX8
--- arch/arm64/Kconfig.platforms | 6 ++++++ drivers/soc/imx/Kconfig | 12 ++++++++++++ 2 files changed, 18 insertions(+)
arch/arm64/Kconfig.platforms +6 -0
@@ -131,6 +131,12 @@ config ARCH_MVEBU - Armada 7K SoC Family - Armada 8K SoC Family +config ARCH_MXC + bool "ARMv8 based NXP i.MX SoC family" + help + This enabled support for the ARMv8 based SoCs in the + NXP i.MX family. + config ARCH_QCOM bool "Qualcomm Platforms" select GPIOLIB
drivers/soc/imx/Kconfig +12 -0
@@ -8,3 +8,15 @@ config IMX7_PM_DOMAINS default y if SOC_IMX7D endmenu + +if ARCH_MXC + +if ARM64 + +config SOC_IMX8MQ + bool "i.MX8MQ support" + help + This enables support for the i.MX8MQ SoC. +endif + +endif
Signature · 1 line
2.11.0
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2c
This is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
--- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ arch/arm64/boot/dts/nxp/imx8mq.dtsi | 418 ++++++++++++++++++++ 3 files changed, 1051 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h create mode 100644 arch/arm64/boot/dts/nxp/imx8mq.dtsi
arch/arm64/boot/dts/Makefile +1 -0
@@ -16,6 +16,7 @@ subdir-y += lg subdir-y += marvell subdir-y += mediatek subdir-y += nvidia +subdir-y += nxp subdir-y += qcom subdir-y += realtek subdir-y += renesas
arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h new file +632 -0
632 lines not on this page · raw message
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +418 -0
418 lines not on this page · raw message
Signature · 1 line
2.11.0
Arnd Bergmann
maintainerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
Quoted 10 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2c
Quoted 8 lines
This is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Signed-off-by Lucas Stach <[email protected]>
I wonder if there is anything preventing us from putting it all into linux-4.16. This is low-risk (nothing would break), and the other three arch/arm64 patches are trivial, so if someone can do a review quickly, I'd be willing to pick the arm-soc portion up.
I suppose we need the clk and pintrl drivers to also get merged at the same time to make it usable, and we also want the bindings for pinctrl and clk to be properly reviewed before adding the nodes to the DT so it depends a, bit on the other maintainers.
To me it looks like the drivers are just "yet another i.MX variant" for them, it should make little difference that this one is 64-bit.
Arnd
Fabio Estevam
reviewerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to Lucas StachQuoted 10 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2c
Quoted 8 lines
This is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Signed-off-by Lucas Stach <[email protected]>
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to Lucas StachQuoted 17 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Quoted 5 lines
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ arch/arm64/boot/dts/nxp/imx8mq.dtsi | 418 ++++++++++++++++++++
So we will have the following two folders for SoCs from the same company.
arch/arm64/boot/dts/nxp/
arch/arm64/boot/dts/freescale/
I'm a bit uncomfortable with that. @Arnd, do you have an opinion how we should handle them?
Shawn
Arnd Bergmann
maintainerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
Quoted 24 lines · Shawn Guo
Quoted 17 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Quoted 5 lines
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ arch/arm64/boot/dts/nxp/imx8mq.dtsi | 418 ++++++++++++++++++++
Quoted 4 lines
So we will have the following two folders for SoCs from the same company.
arch/arm64/boot/dts/nxp/
arch/arm64/boot/dts/freescale/
It might get worse once the sale to Qualcomm goes through and maybe if Broadcom makes another bid for Qualcomm in a few years ;-)
Quoted 2 lines
I'm a bit uncomfortable with that. @Arnd, do you have an opinion how we should handle them?
It's a recurring problem of course. I have a small preference for just adding the i.mx files to arch/arm64/boot/dts/freescale/, but I'd leave it up to you.
Arnd
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Am Montag, den 22.01.2018, 16:11 +0100 schrieb Arnd Bergmann:
Quoted 39 lines
Quoted 27 lines · Shawn Guo
Quoted 18 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable
as there is nothing waking them up anymore. This will be fixed in due course.Quoted 7 lines
Signed-off-by Lucas Stach <[email protected]>---
?arch/arm64/boot/dts/Makefile?????????????|???1 +
?arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632
+++++++++++++++++++++++++++++++
?arch/arm64/boot/dts/nxp/imx8mq.dtsi??????| 418
++++++++++++++++++++Quoted 5 lines
So we will have the following two folders for SoCs from the same company.
?arch/arm64/boot/dts/nxp/
?arch/arm64/boot/dts/freescale/It might get worse once the sale to Qualcomm goes through and maybe if
Broadcom makes another bid for Qualcomm in a few years ;-)
Quoted 8 lines
Quoted 3 lines
I'm a bit uncomfortable with that.??@Arnd, do you have an opinion how we
should handle them?It's a recurring problem of course. I have a small preference for just adding
the i.mx files toarch/arm64/boot/dts/freescale/, but I'd leave it up to you.
The nice thing about the split into Freescale/NXP is that it nicely separates the Layerscape and i.MX stuff, which are two quite different architectures. But that's just a nice coincidence and I'll happily rework the patches to whatever suits the maintainers most. Please make a judgement call.
Regards,
Lucas
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Quoted 3 lines · Lucas Stach
The nice thing about the split into Freescale/NXP is that it nicely separates the Layerscape and i.MX stuff, which are two quite different architectures.
With more and more IPs shared between Layerscape and i.MX, the boundary of these two architectures becomes blurry.
Quoted 3 lines
But that's just a nice coincidence and I'll happily
rework the patches to whatever suits the maintainers most. Please make a judgement call.
Let's put them into 'freescale' folder. Thanks.
Shawn
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to Lucas StachQuoted 25 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ arch/arm64/boot/dts/nxp/imx8mq.dtsi | 418 ++++++++++++++++++++ 3 files changed, 1051 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h create mode 100644 arch/arm64/boot/dts/nxp/imx8mq.dtsi
<snip>
Quoted 155 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +149
-0@@ -0,0 +1,418 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <dt-bindings/clock/imx8mq-clock.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include "imx8mq-pinfunc.h" + +/* first 128 KiB of memory are owned by ATF */ +/memreserve/ 0x40000000 0x00020000; + +/ { + compatible = "nxp,imx8mq"; + /* This should really be the GPC, but we need a driver for this first */ + interrupt-parent = <&gic>; + + #address-cells = <2>; + #size-cells = <2>; + + aliases { + gpio0 = &gpio1; + gpio1 = &gpio2; + gpio2 = &gpio3; + gpio3 = &gpio4; + gpio4 = &gpio5; + i2c0 = &i2c1; + i2c1 = &i2c2; + i2c2 = &i2c3; + i2c3 = &i2c4; + serial0 = &uart1; + serial1 = &uart2; + serial2 = &uart3; + serial3 = &uart4; + }; + + ckil: clk-ckil { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + clock-output-names = "ckil"; + }; + + osc_25m: clk-osc-25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + clock-output-names = "osc_25m"; + }; + + osc_27m: clk-osc-27m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <27000000>; + clock-output-names = "osc_27m"; + }; + + clk_ext1: clk-ext1 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext1"; + }; + + clk_ext2: clk-ext2 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext2"; + }; + + clk_ext3: clk-ext3 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext3"; + }; + + clk_ext4: clk-ext4 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency= <133000000>; + clock-output-names = "clk_ext4"; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + idle-states { + entry-method = "psci"; + + CPU_SLEEP: cpu-sleep { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010033>; + local-timer-stop; + entry-latency-us = <1000>; + exit-latency-us = <700>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + }; + + A53_0: cpu at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x0>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_1: cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_2: cpu at 2 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x2>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_3: cpu at 3 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x3>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_L2: l2-cache0 { + compatible = "cache"; + }; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + + timer { + compatible = "arm,armv8-timer";
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 159
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Secure */ + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Non-Secure */ + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Virtual */ + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>; /* Hypervisor */ + clock-frequency = <8333333>; + interrupt-parent = <&gic>; + arm,no-tick-in-suspend; + }; + + peripherals at 0 {
What's the reason of using 'peripherals' rather than 'soc' which is the case for most device trees?
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 161
Quoted 2 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +2
-0+ compatible = "simple-bus"; +
Drop the newline.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 166
Quoted 5 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +5
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0x0 0x3e000000>; + +
One newline is enough.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 169
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +3
-0+ aips-bus at 30000000 { /* AIPS1 */ + compatible = "nxp,imx8mq-aips-bus", "simple-bus"; +
Drop the newline.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 175
Quoted 6 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +6
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30000000 0x30000000 0x400000>; + + gpio1: gpio at 30200000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio";
It looks a bit odd to have different vendor prefix for the same device. But we can understand the reason. Just curious if this is what vendor kernel does?
Quoted 77 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +77
-0+ reg = <0x30200000 0x10000>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio2: gpio at 30210000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30210000 0x10000>; + interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio3: gpio at 30220000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30220000 0x10000>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio4: gpio at 30230000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30230000 0x10000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio5: gpio at 30240000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30240000 0x10000>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + iomuxc: iomuxc at 30330000 { + compatible = "nxp,imx8mq-iomuxc"; + reg = <0x30330000 0x10000>; + }; + + gpr: iomuxc-gpr at 30340000 { + compatible = "nxp,imx8mq-iomuxc-gpr", "syscon"; + reg = <0x30340000 0x10000>; + }; + + anatop: anatop at 30360000 { + compatible = "nxp,imx8mq-anatop", "syscon"; + reg = <0x30360000 0x10000>; + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + }; + + clk: ccm at 30380000 { + compatible = "nxp,imx8mq-ccm"; + reg = <0x30380000 0x10000>; + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>; + clocks = <&ckil>, <&osc_25m>, <&osc_27m>, + <&clk_ext1>, <&clk_ext2>,
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 262
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+ <&clk_ext3>, <&clk_ext4>; + clock-names = "ckil", "osc_25m", "osc_27m", + "clk_ext1", "clk_ext2", + "clk_ext3", "clk_ext4"; + }; + }; + + aips-bus at 30400000 { /* AIPS2 */ + compatible = "nxp,imx8mq-aips-bus", "simple-bus"; +
Drop the newline.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 270
Quoted 8 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +8
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30400000 0x30400000 0x400000>; + }; + + aips-bus at 30800000 { /* AIPS3 */ + compatible = "nxp,imx8mq-aips-bus", "simple-bus"; +
Ditto
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 277
Quoted 7 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +7
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30800000 0x30800000 0x400000>; + + uart1: serial at 30860000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart";
Falling on "fsl,imx6q-uart" only is good enough?
Quoted 26 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +26
-0+ reg = <0x30860000 0x10000>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART1_ROOT>, + <&clk IMX8MQ_CLK_UART1_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + uart3: serial at 30880000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30880000 0x10000>; + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART3_ROOT>, + <&clk IMX8MQ_CLK_UART3_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + uart2: serial at 30890000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30890000 0x10000>; + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART2_ROOT>, + <&clk IMX8MQ_CLK_UART2_ROOT>;
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 313
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+ clock-names = "ipg", "per"; + status = "disabled"; + }; + + i2c1: i2c at 30a20000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a20000 0x10000>; + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C1_ROOT>; + status = "disabled";
Please put the 'status' at the bottom of property list.
Shawn
Quoted 108 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +105
-0+ #address-cells = <1>; + #size-cells = <0>; + }; + + i2c2: i2c at 30a30000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a30000 0x10000>; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C2_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c3: i2c at 30a40000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a40000 0x10000>; + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C3_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c4: i2c at 30a50000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a50000 0x10000>; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C4_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + uart4: serial at 30a60000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30a60000 0x10000>; + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART4_ROOT>, + <&clk IMX8MQ_CLK_UART4_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + usdhc1: usdhc at 30b40000 { + compatible = "nxp,imx8mq-usdhc", + "fsl,imx7d-usdhc"; + reg = <0x30b40000 0x10000>; + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_DUMMY>, + <&clk IMX8MQ_CLK_NAND_USDHC_BUS_DIV>, + <&clk IMX8MQ_CLK_USDHC1_ROOT>; + clock-names = "ipg", "ahb", "per"; + fsl,tuning-start-tap = <20>; + fsl,tuning-step = <2>; + bus-width = <4>; + status = "disabled"; + }; + + usdhc2: usdhc at 30b50000 { + compatible = "nxp,imx8mq-usdhc", + "fsl,imx7d-usdhc"; + reg = <0x30b50000 0x10000>; + interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_DUMMY>, + <&clk IMX8MQ_CLK_NAND_USDHC_BUS_DIV>, + <&clk IMX8MQ_CLK_USDHC2_ROOT>; + clock-names = "ipg", "ahb", "per"; + fsl,tuning-start-tap = <20>; + fsl,tuning-step = <2>; + bus-width = <4>; + status = "disabled"; + }; + + fec1: ethernet at 30be0000 { + compatible = "nxp,imx8mq-fec", "fsl,imx6sx-fec"; + reg = <0x30be0000 0x10000>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_ENET1_ROOT>, + <&clk IMX8MQ_CLK_ENET1_ROOT>, + <&clk IMX8MQ_CLK_ENET_TIMER_DIV>, + <&clk IMX8MQ_CLK_ENET_REF_DIV>, + <&clk IMX8MQ_CLK_ENET_PHY_REF_DIV>; + clock-names = "ipg", "ahb", "ptp", + "enet_clk_ref", "enet_out"; + fsl,num-tx-queues = <3>; + fsl,num-rx-queues = <3>; + status = "disabled"; + }; + }; + + gic: interrupt-controller at 38800000 { + compatible = "arm,gic-v3"; + reg = <0x38800000 0x10000>, /* GIC Dist */ + <0x38880000 0xc0000>; /* GICR (RD_base + SGI_base) */ + #interrupt-cells = <3>; + interrupt-controller; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + }; + }; +};Signature · 1 line
2.11.0
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Am Dienstag, den 23.01.2018, 18:36 +0800 schrieb Shawn Guo:
Quoted 30 lines · Lucas Stach
Quoted 25 lines
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Quoted 1 line
Quoted 1 line
Signed-off-by Lucas Stach <[email protected]>---
?arch/arm64/boot/dts/Makefile?????????????|???1 + ?arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ ?arch/arm64/boot/dts/nxp/imx8mq.dtsi??????| 418 ++++++++++++++++++++?3 files changed, 1051 insertions(+)
?create mode 100644arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h?create mode 100644arch/arm64/boot/dts/nxp/imx8mq.dtsi<snip>
Quoted 1 line
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ timer {
Quoted 14 lines
Review
Quoted 11 lines
Quoted 9 lines
Quoted 9 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +9
-0+ compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Secure */ + ?????????????<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Non-Secure */ + ?????????????<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Virtual */ + ?????????????<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>; /* Hypervisor */ + clock-frequency = <8333333>; + interrupt-parent = <&gic>; + arm,no-tick-in-suspend; + };(quoted diff) +2
-0+ + peripherals at 0 {What's the reason of using 'peripherals' rather than 'soc' which is the case for most device trees?
Just personal preference. I find it a bit confusing to have a soc node, that doesn't include a lot of stuff (e.g CPUs) that are found on the SoC. I someone feels strongly about this I'll change it.
Quoted 23 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ compatible = "simple-bus"; +Drop the newline.
Review
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0x0 0x3e000000>;(quoted diff) +2
-0+ +One newline is enough.
Quoted 3 lines
Quoted 2 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 168
Quoted 2 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +2
-0+ aips-bus at 30000000 { /* AIPS1 */ + compatible = "nxp,imx8mq-aips-bus", "simple-bus";+
Drop the newline.
Quoted 4 lines
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 172
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30000000 0x30000000 0x400000>;+
Quoted 6 lines
Review
Quoted 2 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ gpio1: gpio at 30200000 {(quoted diff) +1
-0+ compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio";It looks a bit odd to have different vendor prefix for the same device. But we can understand the reason.??Just curious if this is what vendor kernel does?
No, I did it mostly to be consistent with the location of the DT files under "nxp". I'll change this to match the "freescale" location.
Regards,
Lucas
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Hi Lucas,
First of all, good to see this patch series in community.
Pengutronix has always been an active friendly contributor on IMX upstream activities. You Did help us a lot!
On 2018-01-23 21:23, Lucas Stach wrote:
<snip>
Quoted 12 lines
Quoted 11 lines
Review
Quoted 6 lines
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 172
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +3
-0+ #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30000000 0x30000000 0x400000>;+
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ gpio1: gpio at 30200000 {(quoted diff) +1
-0+ compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio";It looks a bit odd to have different vendor prefix for the same device.
But we can understand the reason.??Just curious if this is what vendor kernel does?
Quoted 3 lines
No, I did it mostly to be consistent with the location of the DT files under "nxp". I'll change this to match the "freescale" location.
Vendor tree mostly is still using fsl,imx8mq-xx.
And many binding doc format is:"compatible : Should be "fsl,<soc>-gpio". So we can't use 'nxp' prefix here without changing binding doc.
Then if we decided to use 'fsl' prefix, probably we may want to fix the rest of them in this file as well.
And i see the dtsi file does not include Freescale/NXP copyright, is there a reason?
BTW it's quite strange that my gmail did not receive your MX8MQ patch series except clk part.
Lucas, Could you help have me CCed next time?
I'd like to help review and test the patch series.
For this time, can you help send them all to me as attachment?
(You can also send all IMX related patches to linux-imx at nxp.com maillist i created recently for tracking all IMX related upstream activities. Most Freescale/NXP driver owners are in this list that could help on the review. Shawn, do you think if i can put it in MAINTAINER file?)
Regards
Dong Aisheng
Quoted 7 lines
Regards,
Lucas_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Hi Dong,
Am Donnerstag, den 25.01.2018, 17:48 +0800 schrieb aisheng.dong at codeaurora.org:
Quoted 29 lines
Hi Lucas,
First of all, good to see this patch series in community.
Pengutronix has always been an active friendly contributor on IMX upstream activities.??You Did help us a lot!
On 2018-01-23 21:23, Lucas Stach wrote:
<snip>
Quoted 14 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 172
Quoted 3 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
(quoted diff) +2
-0+ #address-cells = <1>; + #size-cells = <1>;arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ ranges = <0x30000000 0x30000000 0x400000>;+
Quoted 8 lines
Review
Quoted 3 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ gpio1: gpio at 30200000 {(quoted diff) +1
-0+ compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio";It looks a bit odd to have different vendor prefix for the same? device.
But we can understand the reason.??Just curious if this is what vendor kernel does?Quoted 3 lines
No, I did it mostly to be consistent with the location of the DT files under "nxp". I'll change this to match the "freescale" location.
Quoted 7 lines
Vendor tree mostly is still using fsl,imx8mq-xx.
And many binding doc format is:"compatible : Should be "fsl,<soc>-gpio". So we can't use 'nxp' prefix here without changing binding doc.
Then if we decided to use 'fsl' prefix, probably we may want to fix the rest of them in this file as well.
Yes, this is changed consistently to "fsl," for the next revision of the patchset.
Quoted 2 lines
And i see the dtsi file does not include Freescale/NXP copyright, is there a reason?
The dtsi is quite different from the downstream version. But you are right, I looked extensively at the downstream version, so I'll add the NXP copyright.
BTW: Could you check internally to see if Freescale/NXP would be okay with relicensing the DT bits I pulled from downstream as dual GPL-2.0 and MIT, to align with other DTs in the kernel?
Quoted 6 lines
BTW it's quite strange that my gmail did not receive your MX8MQ patch series except clk part.
Lucas, Could you help have me CCed next time?
I'd like to help review and test the patch series.For this time, can you help send them all to me as attachment?
I'm about to send v2 of the series. I'll CC you on the submission.
Quoted 4 lines
(You can also send all IMX related patches to linux-imx at nxp.com maillist i created recently for tracking all IMX related upstream activities. Most Freescale/NXP driver owners are in this list that could help on the review. Shawn, do you think if i can put it in MAINTAINER file?)
That's great news that there is now a common address for this. I think it would be a good idea to have it added to MAINTAINERS as a reviewer.
Regards,
Lucas
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Quoted 1 line · Lucas Stach
Hi Dong,
<snip>
Quoted 7 lines
Quoted 2 lines
And i see the dtsi file does not include Freescale/NXP copyright, is there a reason?
The dtsi is quite different from the downstream version. But you are right, I looked extensively at the downstream version, so I'll add the NXP copyright.
Okay, i see.
Quoted 4 lines
BTW: Could you check internally to see if Freescale/NXP would be okay with relicensing the DT bits I pulled from downstream as dual GPL-2.0 and MIT, to align with other DTs in the kernel?
I thought it should be okay. But i pulled Post Lauren in to give you a confirmed answer.
Lauren,
Can you help with this question?
Quoted 9 lines
Quoted 6 lines
BTW it's quite strange that my gmail did not receive your MX8MQ patch series except clk part.
Lucas, Could you help have me CCed next time?
I'd like to help review and test the patch series.For this time, can you help send them all to me as attachment?
I'm about to send v2 of the series. I'll CC you on the submission.
Great.
Quoted 9 lines
Quoted 5 lines
(You can also send all IMX related patches to linux-imx at nxp.com maillist
i created recently for tracking all IMX related upstream activities. Most Freescale/NXP driver owners are in this list that could help on the review. Shawn, do you think if i can put it in MAINTAINER file?)That's great news that there is now a common address for this. I think it would be a good idea to have it added to
MAINTAINERSas a reviewer.
Thanks for supporting.
Regards
Dong Aisheng
Quoted 7 lines
Regards,
Lucas_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to aisheng.dong at codeaurora.orgQuoted 4 lines · aisheng.dong at codeaurora.org
(You can also send all IMX related patches to linux-imx at nxp.com maillist i created recently for tracking all IMX related upstream activities. Most Freescale/NXP driver owners are in this list that could help on the review. Shawn, do you think if i can put it in MAINTAINER file?)
Yeah, it will be very helpful. Please send me a patch for that.
Shawn
Rob Herring
maintainerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to Lucas StachQuoted 47 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
One known limitation is that the driver for the GPC interrupt controller is still missing, rendering the CPU sleep states unusable as there is nothing waking them up anymore. This will be fixed in due course.
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h | 632 +++++++++++++++++++++++++++++++ arch/arm64/boot/dts/nxp/imx8mq.dtsi | 418 ++++++++++++++++++++ 3 files changed, 1051 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h create mode 100644 arch/arm64/boot/dts/nxp/imx8mq.dtsiarch/arm64/boot/dts/Makefile +1
-0@@ -16,6 +16,7 @@ subdir-y += lg subdir-y += marvell subdir-y += mediatek subdir-y += nvidia +subdir-y += nxp subdir-y += qcom subdir-y += realtek subdir-y += renesasarch/arm64/boot/dts/nxp/imx8mq-pinfunc.h new file +3
-0@@ -0,0 +1,632 @@ +/* +* Copyright (C) 2016 Freescale Semiconductor, Inc. +* Copyright 2017 NXP
arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h line 13
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq-pinfunc.h new file +10
-0+* +* 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. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details.
SPDX tag
[...]
Quoted 8 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +2
-0@@ -0,0 +1,418 @@ +// SPDX-License-Identifier: GPL-2.0 +
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 12
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+#include <dt-bindings/clock/imx8mq-clock.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> +#include "imx8mq-pinfunc.h" + +/* first 128 KiB of memory are owned by ATF */ +/memreserve/ 0x40000000 0x00020000; + +/ { + compatible = "nxp,imx8mq";
No point in this because every board should set it with board specific compatible in addition.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 24
Quoted 12 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +12
-0+ /* This should really be the GPC, but we need a driver for this first */ + interrupt-parent = <&gic>; + + #address-cells = <2>; + #size-cells = <2>; + + aliases { + gpio0 = &gpio1; + gpio1 = &gpio2; + gpio2 = &gpio3; + gpio3 = &gpio4; + gpio4 = &gpio5;
Please drop these.
Quoted 211 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +211
-0+ i2c0 = &i2c1; + i2c1 = &i2c2; + i2c2 = &i2c3; + i2c3 = &i2c4; + serial0 = &uart1; + serial1 = &uart2; + serial2 = &uart3; + serial3 = &uart4; + }; + + ckil: clk-ckil { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + clock-output-names = "ckil"; + }; + + osc_25m: clk-osc-25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + clock-output-names = "osc_25m"; + }; + + osc_27m: clk-osc-27m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <27000000>; + clock-output-names = "osc_27m"; + }; + + clk_ext1: clk-ext1 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext1"; + }; + + clk_ext2: clk-ext2 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext2"; + }; + + clk_ext3: clk-ext3 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <133000000>; + clock-output-names = "clk_ext3"; + }; + + clk_ext4: clk-ext4 { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency= <133000000>; + clock-output-names = "clk_ext4"; + }; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + idle-states { + entry-method = "psci"; + + CPU_SLEEP: cpu-sleep { + compatible = "arm,idle-state"; + arm,psci-suspend-param = <0x0010033>; + local-timer-stop; + entry-latency-us = <1000>; + exit-latency-us = <700>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + }; + + A53_0: cpu at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x0>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_1: cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x1>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_2: cpu at 2 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x2>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_3: cpu at 3 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x3>; + enable-method = "psci"; + next-level-cache = <&A53_L2>; + cpu-idle-states = <&CPU_SLEEP>; + }; + + A53_L2: l2-cache0 { + compatible = "cache"; + }; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Secure */ + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Physical Non-Secure */ + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>, /* Virtual */ + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>; /* Hypervisor */ + clock-frequency = <8333333>; + interrupt-parent = <&gic>; + arm,no-tick-in-suspend; + }; + + peripherals at 0 { + compatible = "simple-bus"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x0 0x0 0x3e000000>; + + + aips-bus at 30000000 { /* AIPS1 */ + compatible = "nxp,imx8mq-aips-bus", "simple-bus"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30000000 0x30000000 0x400000>; + + gpio1: gpio at 30200000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30200000 0x10000>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio2: gpio at 30210000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30210000 0x10000>; + interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio3: gpio at 30220000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30220000 0x10000>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio4: gpio at 30230000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30230000 0x10000>; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + gpio5: gpio at 30240000 { + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + reg = <0x30240000 0x10000>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + iomuxc: iomuxc at 30330000 { + compatible = "nxp,imx8mq-iomuxc"; + reg = <0x30330000 0x10000>; + }; + + gpr: iomuxc-gpr at 30340000 { + compatible = "nxp,imx8mq-iomuxc-gpr", "syscon";
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 245
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+ reg = <0x30340000 0x10000>; + }; + + anatop: anatop at 30360000 { + compatible = "nxp,imx8mq-anatop", "syscon"; + reg = <0x30360000 0x10000>; + interrupts = <GIC_SPI 49 IRQ_TYPE_LEVEL_HIGH>; + }; + + clk: ccm at 30380000 {
clock-controller at ...
Quoted 5 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +5
-0+ compatible = "nxp,imx8mq-ccm"; + reg = <0x30380000 0x10000>; + interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + #clock-cells = <1>;
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 260
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +10
-0+ clocks = <&ckil>, <&osc_25m>, <&osc_27m>, + <&clk_ext1>, <&clk_ext2>, + <&clk_ext3>, <&clk_ext4>; + clock-names = "ckil", "osc_25m", "osc_27m", + "clk_ext1", "clk_ext2", + "clk_ext3", "clk_ext4"; + }; + }; + + aips-bus at 30400000 { /* AIPS2 */
bus at ...
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 268
Quoted 8 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +8
-0+ compatible = "nxp,imx8mq-aips-bus", "simple-bus"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30400000 0x30400000 0x400000>; + }; + + aips-bus at 30800000 { /* AIPS3 */
bus at ...
Quoted 153 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +150
-0+ compatible = "nxp,imx8mq-aips-bus", "simple-bus"; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x30800000 0x30800000 0x400000>; + + uart1: serial at 30860000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30860000 0x10000>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART1_ROOT>, + <&clk IMX8MQ_CLK_UART1_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + uart3: serial at 30880000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30880000 0x10000>; + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART3_ROOT>, + <&clk IMX8MQ_CLK_UART3_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + uart2: serial at 30890000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30890000 0x10000>; + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART2_ROOT>, + <&clk IMX8MQ_CLK_UART2_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + i2c1: i2c at 30a20000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a20000 0x10000>; + interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C1_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c2: i2c at 30a30000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a30000 0x10000>; + interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C2_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c3: i2c at 30a40000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a40000 0x10000>; + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C3_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + i2c4: i2c at 30a50000 { + compatible = "nxp,imx8mq-i2c", "fsl,imx21-i2c"; + reg = <0x30a50000 0x10000>; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_I2C4_ROOT>; + status = "disabled"; + #address-cells = <1>; + #size-cells = <0>; + }; + + uart4: serial at 30a60000 { + compatible = "nxp,imx8mq-uart", + "fsl,imx6q-uart", "fsl,imx21-uart"; + reg = <0x30a60000 0x10000>; + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_UART4_ROOT>, + <&clk IMX8MQ_CLK_UART4_ROOT>; + clock-names = "ipg", "per"; + status = "disabled"; + }; + + usdhc1: usdhc at 30b40000 { + compatible = "nxp,imx8mq-usdhc", + "fsl,imx7d-usdhc"; + reg = <0x30b40000 0x10000>; + interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_DUMMY>, + <&clk IMX8MQ_CLK_NAND_USDHC_BUS_DIV>, + <&clk IMX8MQ_CLK_USDHC1_ROOT>; + clock-names = "ipg", "ahb", "per"; + fsl,tuning-start-tap = <20>; + fsl,tuning-step = <2>; + bus-width = <4>; + status = "disabled"; + }; + + usdhc2: usdhc at 30b50000 { + compatible = "nxp,imx8mq-usdhc", + "fsl,imx7d-usdhc"; + reg = <0x30b50000 0x10000>; + interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_DUMMY>, + <&clk IMX8MQ_CLK_NAND_USDHC_BUS_DIV>, + <&clk IMX8MQ_CLK_USDHC2_ROOT>; + clock-names = "ipg", "ahb", "per"; + fsl,tuning-start-tap = <20>; + fsl,tuning-step = <2>; + bus-width = <4>; + status = "disabled"; + }; + + fec1: ethernet at 30be0000 { + compatible = "nxp,imx8mq-fec", "fsl,imx6sx-fec"; + reg = <0x30be0000 0x10000>; + interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_ENET1_ROOT>, + <&clk IMX8MQ_CLK_ENET1_ROOT>, + <&clk IMX8MQ_CLK_ENET_TIMER_DIV>, + <&clk IMX8MQ_CLK_ENET_REF_DIV>, + <&clk IMX8MQ_CLK_ENET_PHY_REF_DIV>; + clock-names = "ipg", "ahb", "ptp", + "enet_clk_ref", "enet_out"; + fsl,num-tx-queues = <3>; + fsl,num-rx-queues = <3>; + status = "disabled"; + }; + }; + + gic: interrupt-controller at 38800000 { + compatible = "arm,gic-v3"; + reg = <0x38800000 0x10000>, /* GIC Dist */ + <0x38880000 0xc0000>; /* GICR (RD_base + SGI_base) */ + #interrupt-cells = <3>; + interrupt-controller; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&gic>; + }; + }; +};Signature · 1 line
2.11.0
Rob Herring
maintainerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
In reply to Lucas StachQuoted 12 lines · Lucas Stach
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cThis is enough to get a very basic board support up and running.
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 230
Quoted 3 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +3
-0+ compatible = "nxp,imx8mq-aips-bus", "simple-bus"; + compatible = "nxp,imx8mq-gpio", "fsl,imx35-gpio"; + compatible = "nxp,imx8mq-iomuxc";
Also, are all these new compatibles documented?
Rob
PATCH 2/4 arm64: add basic DTS for i.MX8MQ
Am Montag, den 29.01.2018, 11:55 -0600 schrieb Rob Herring:
Quoted 11 lines · Lucas Stach
Quoted 10 lines
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2c
Quoted 8 lines
arch/arm64/boot/dts/nxp/imx8mq.dtsi line 230
Quoted 6 lines
This is enough to get a very basic board support up and running.
(quoted diff) +1
-0+ compatible = "nxp,imx8mq-aips-bus","simple-bus";
(quoted diff) +1
-0+ compatible = "nxp,imx8mq-gpio","fsl,imx35-gpio";
arch/arm64/boot/dts/nxp/imx8mq.dtsi new file +1
-0+ compatible = "nxp,imx8mq-iomuxc";Also, are all these new compatibles documented?
Only those where the driver isn't matching one of the older compatibles.
I'm not sure what the policy is for those "just in case" compatibles, where we have older compatibles that are currently used, but the newer compatibles are in the DT to make it easy to match them when any IP integration issues turn up at a later time.
Regards,
Lucas
Rob Herring
maintainerPATCH 2/4 arm64: add basic DTS for i.MX8MQ
Quoted 21 lines · Lucas Stach
Am Montag, den 29.01.2018, 11:55 -0600 schrieb Rob Herring:
Quoted 11 lines · Lucas Stach
Quoted 10 lines
This adds the basic DTS for the i.MX8MQ.
For now only the following peripherals are supported:
- IOMUXC (pin controller)
- CCM (clock controller)
- GPIO
- UART
- uSDHC (SD/eMMC controller)
- FEC (ethernet controller)
- i2cQuoted 8 lines
Quoted 6 lines
This is enough to get a very basic board support up and running.
+ compatible = "nxp,imx8mq-aips-bus",
"simple-bus";
+ compatible = "nxp,imx8mq-gpio",
"fsl,imx35-gpio";
+ compatible = "nxp,imx8mq-iomuxc";Also, are all these new compatibles documented?
Quoted 7 lines
Only those where the driver isn't matching one of the older compatibles.
I'm not sure what the policy is for those "just in case" compatibles, where we have older compatibles that are currently used, but the newer compatibles are in the DT to make it easy to match them when any IP integration issues turn up at a later time.
They all should be documented, so dts files can be validated (once we have machine parseable binding docs).
Rob
PATCH 3/4 arm64: add support for i.MX8M EVK board
In reply to Lucas StachThis is the evaluation kit board for the i.MX8M. The current level of support yields a working console and is able to boot userspace from SD card or Network.
--- arch/arm64/boot/dts/nxp/Makefile | 3 + arch/arm64/boot/dts/nxp/imx8mq-evk.dts | 287 +++++++++++++++++++++++++++++++++ 2 files changed, 290 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/Makefile create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-evk.dts
arch/arm64/boot/dts/nxp/Makefile new file +3 -0
@@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +dtb-$(CONFIG_SOC_IMX8MQ) += imx8m-evk.dtb
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +287 -0
287 lines not on this page · raw message
Signature · 1 line
2.11.0
Fabio Estevam
reviewerPATCH 3/4 arm64: add support for i.MX8M EVK board
Quoted 5 lines · Lucas Stach
This is the evaluation kit board for the i.MX8M. The current level of support yields a working console and is able to boot userspace from SD card or Network.
Signed-off-by Lucas Stach <[email protected]>
PATCH 3/4 arm64: add support for i.MX8M EVK board
In reply to Lucas Stacharch/arm64/boot/dts/nxp/imx8mq-evk.dts line 274
Quoted 11 lines · Lucas Stach
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +11
-0+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz { + fsl,pins = < + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc5 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc5 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc5 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc5 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1 + >; + };
Bad indentation.
Shawn
Quoted 16 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +13
-0+ + pinctrl_usdhc2_200mhz: usdhc2grp200mhz { + fsl,pins = < + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc7 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc7 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc7 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc7 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1 + >; + }; +};Signature · 1 line
2.11.0
PATCH 3/4 arm64: add support for i.MX8M EVK board
Quoted 18 lines · Shawn Guo
arch/arm64/boot/dts/nxp/imx8mq-evk.dts line 274
Quoted 11 lines · Lucas Stach
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +11
-0+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz { + fsl,pins = < + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc5 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc5 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc5 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc5 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1 + >; + };Bad indentation.
Shawn
Quoted 12 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts line 286
Quoted 12 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +12
-0+ + pinctrl_usdhc2_200mhz: usdhc2grp200mhz { + fsl,pins = < + MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc7 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc7 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc7 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc7 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1 + >; + };
AFAIK we switched to generic pinconfig since MX7ULP as maintainer won't access old binding pinctrl drivers.
So i wonder if you may have some special reasons to insist on old binding which
i may overlooked?
(I did not receive your pinctrl patch by accidently. So i can't reply on it before.)
Regards
Dong Aisheng
Quoted 9 lines
Quoted 4 lines
+};
--
2.11.0_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/4 arm64: add support for i.MX8M EVK board
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb aisheng.dong at codeaurora.org:
Quoted 22 lines · Shawn Guo
Quoted 21 lines · Lucas Stach
Review
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
(quoted diff) +2
-0+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz { + fsl,pins = <Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +7
-0+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc5 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc5 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc5 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc5 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1(quoted diff) +1
-0+ >;(quoted diff) +1
-0+ };Bad indentation.
Shawn
Quoted 3 lines
+
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +2
-0+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz { + fsl,pins = <
Quoted 12 lines
Quoted 9 lines
Review
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +7
-0+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc7 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc7 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc7 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc7 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1(quoted diff) +1
-0+ >;(quoted diff) +1
-0+ };AFAIK we switched to generic pinconfig since MX7ULP as maintainer won't access old binding pinctrl drivers.
I'm not convinced that the generic pinconf is good fit. For pingroups with different configs for some of the pins, like the example above, we would need to split things into multiple DT nodes. This really hurts readability, so I'm not going to switch to the generic stuff without some really convincing arguments.
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
Quoted 38 lines · Lucas Stach
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb aisheng.dong at codeaurora.org:
Quoted 22 lines · Shawn Guo
Quoted 21 lines · Lucas Stach
Review
Quoted 12 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
(quoted diff) +2
-0+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz { + fsl,pins = <Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +7
-0+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x85 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc5 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc5 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc5 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc5 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc5 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1(quoted diff) +1
-0+ >;(quoted diff) +1
-0+ };Bad indentation.
Shawn
Quoted 3 lines
+
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +2
-0+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz { + fsl,pins = <Quoted 13 lines
Quoted 9 lines
Review
Quoted 9 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +7
-0+ MX8MQ_IOMUXC_SD2_CLK_USDHC2_CLK 0x87 + MX8MQ_IOMUXC_SD2_CMD_USDHC2_CMD 0xc7 + MX8MQ_IOMUXC_SD2_DATA0_USDHC2_DATA0 0xc7 + MX8MQ_IOMUXC_SD2_DATA1_USDHC2_DATA1 0xc7 + MX8MQ_IOMUXC_SD2_DATA2_USDHC2_DATA2 0xc7 + MX8MQ_IOMUXC_SD2_DATA3_USDHC2_DATA3 0xc7 + MX8MQ_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xc1(quoted diff) +1
-0+ >;(quoted diff) +1
-0+ };AFAIK we switched to generic pinconfig since MX7ULP as maintainer won't
access old binding pinctrl drivers.
Quoted 6 lines
I'm not convinced that the generic pinconf is good fit. For pingroups with different configs for some of the pins, like the example above, we would need to split things into multiple DT nodes. This really hurts readability, so I'm not going to switch to the generic stuff without some really convincing arguments.
Per my understanding, based on the last discussion with Linus W, we actually
did this in order to increase the readability that 1) user does not need to
see the 'ugly' unreadable raw data and refer to reference manual 2) unified
generic binding format which already exist in kernel and used by many platforms.
Actually MXS platform already used it for many years in a similar way.
So IMHO a little hurt to add another node for different pad setting in the
same group won't be enough reason to stop switching to generic config.
Does it make sense?
Regards
Dong Aisheng
Quoted 2 lines
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
Am Donnerstag, den 25.01.2018, 18:49 +0800 schrieb Dong Aisheng:
Quoted 3 lines · Lucas Stach
Quoted 2 lines
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb? aisheng.dong at codeaurora.org:
[...]
Quoted 17 lines
AFAIK we switched to generic pinconfig since MX7ULP as maintainer?
Quoted 9 lines
Quoted 2 lines
won't
access old binding pinctrl drivers.I'm not convinced that the generic pinconf is good fit. For pingroups with different configs for some of the pins, like the example above, we would need to split things into multiple DT nodes. This really hurts readability, so I'm not going to switch to the generic stuff without some really convincing arguments.
Per my understanding, based on the last discussion with Linus W, we? actually did this in order to increase the readability that 1) user does not need?to see the 'ugly' unreadable raw data and refer to reference manual 2)?unified generic binding format which already exist in kernel and used by many platforms.
Quoted 5 lines
Actually MXS platform already used it for many years in a similar way. So IMHO a little hurt to add another node for different pad setting in? the same group won't be enough reason to stop switching to generic config.
Does it make sense?
I know that Linus W is pushing for this common pinconf thing in the name of readability. It's just that I don't think it's such a clear win.
After all you still need to look into the reference manual or binding to see which values in the common binding correspond to a specific drive/pull strength, etc.
On the other hand it really bloats the DT description of the pin configuration. If you want to look at an (IMHO) bad example, go look at the Tegra DTs. The Tegra pincontrol implements the "separate properties for each pinconf option" that is pushed by Linus W. This bloated the DT description to the point that no-one is able/willing to write those descriptions anymore and the only viable way to get them is to auto- generate them from some spreadsheets. Not really what I would call an readable...
Maybe I'm a little stubborn when it comes to this topic, but at Pengutronix we see a lot of customer designs where we need to come up with the board DT. Bloating each one of those and making the work of the developers harder in the name of a readability win that I just don't see doesn't sound like something I want to support. :)
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
Quoted 31 lines · Lucas Stach
Am Donnerstag, den 25.01.2018, 18:49 +0800 schrieb Dong Aisheng:
Quoted 3 lines · Lucas Stach
Quoted 2 lines
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb? aisheng.dong at codeaurora.org:
[...]
Quoted 18 lines
AFAIK we switched to generic pinconfig since MX7ULP as maintainer?
Quoted 9 lines
Quoted 2 lines
won't
access old binding pinctrl drivers.I'm not convinced that the generic pinconf is good fit. For pingroups with different configs for some of the pins, like the example above, we would need to split things into multiple DT nodes. This really hurts readability, so I'm not going to switch to the generic stuff without some really convincing arguments.
Per my understanding, based on the last discussion with Linus W, we? actually did this in order to increase the readability that 1) user does
not need?to see the 'ugly' unreadable raw data and refer to reference manual 2)?unified generic binding format which already exist in kernel and used by many platforms.Quoted 7 lines
Actually MXS platform already used it for many years in a similar way. So IMHO a little hurt to add another node for different pad setting in?
the same group won't be enough reason to stop switching to generic config.Does it make sense?
Quoted 8 lines
I know that Linus W is pushing for this common pinconf thing in the name of readability. It's just that I don't think it's such a clear win.
After all you still need to look into the reference manual or binding to see which values in the common binding correspond to a specific drive/pull strength, etc.
User don't need to look into reference manual and they don't need to compose the 'ulgy' raw data which is the most tough thing.
With generic binding, it probably can saving ~80% pad setting effort by refer to the defined generic config properties.
And things can be even better when the reference code is already there as user becomes know which property supported.
Quoted 9 lines
On the other hand it really bloats the DT description of the pin configuration. If you want to look at an (IMHO) bad example, go look at the Tegra DTs. The Tegra pincontrol implements the "separate properties for each pinconf option" that is pushed by Linus W. This bloated the DT description to the point that no-one is able/willing to write those descriptions anymore and the only viable way to get them is to auto- generate them from some spreadsheets. Not really what I would call an readable...
I wonder the worst case you're worrying whether exist in reality. Take imx6qdl-sabresd as an example, about half of pingroups having the same
pad setting while others have two different settings at most. That means it may not bloat the device tree too much.
Quoted 6 lines
Maybe I'm a little stubborn when it comes to this topic, but at Pengutronix we see a lot of customer designs where we need to come up with the board DT. Bloating each one of those and making the work of the developers harder in the name of a readability win that I just don't see doesn't sound like something I want to support. :)
Hmm.. In contrast, what i feel currently is that it may ease the using of
pad setting, not make it harder. Not sure if i overlooked something.
Let's listen to Shawn and Linus W if they have some comments.
Regards
Dong Aisheng
Quoted 2 lines
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
Am Donnerstag, den 25.01.2018, 21:03 +0800 schrieb Dong Aisheng:
Quoted 95 lines · Lucas Stach
Quoted 44 lines
Am Donnerstag, den 25.01.2018, 18:49 +0800 schrieb Dong Aisheng:
Quoted 3 lines · Lucas Stach
Quoted 2 lines
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb? aisheng.dong at codeaurora.org:
[...]
Quoted 36 lines
AFAIK we switched to generic pinconfig since MX7ULP as maintainer?
Quoted 13 lines
Quoted 2 lines
won't
access old binding pinctrl drivers.I'm not convinced that the generic pinconf is good fit. For pingroups
with different configs for some of the pins, like the example above, we
would need to split things into multiple DT nodes. This really hurts
readability, so I'm not going to switch to the generic stuff without
some really convincing arguments.Per my understanding, based on the last discussion with Linus W, we?
actually did this in order to increase the readability that 1) user?
does
not need?to see the 'ugly' unreadable raw data and refer to reference
manual 2)?unified generic binding format which already exist in kernel
and used by many platforms.Actually MXS platform already used it for many years in a similar way.
So IMHO a little hurt to add another node for different pad setting?
in?
the same group won't be enough reason to stop switching to generic?
config.Quoted 1 line
Does it make sense?
Quoted 9 lines
I know that Linus W is pushing for this common pinconf thing in the name of readability. It's just that I don't think it's such a clear win.
After all you still need to look into the reference manual or binding
to see which values in the common binding correspond to a specific drive/pull strength, etc.User don't need to look into reference manual and they don't need to compose the 'ulgy' raw data which is the most tough thing.
With generic binding, it probably can saving ~80% pad setting effort by refer to the defined generic config properties.
And things can be even better when the reference code is already there
as user becomes know which property supported.Quoted 5 lines
On the other hand it really bloats the DT description of the pin configuration. If you want to look at an (IMHO) bad example, go look at
the Tegra DTs. The Tegra pincontrol implements the "separate propertiesQuoted 9 lines
for each pinconf option" that is pushed by Linus W. This bloated the DT
description to the point that no-one is able/willing to write those descriptions anymore and the only viable way to get them is to auto-
generate them from some spreadsheets. Not really what I would call an
readable...I wonder the worst case you're worrying whether exist in reality. Take imx6qdl-sabresd as an example, about half of pingroups having the?
same
pad setting while others have two different settings at most. That means it may not bloat the device tree too much.Quoted 8 lines
Maybe I'm a little stubborn when it comes to this topic, but at Pengutronix we see a lot of customer designs where we need to come up
with the board DT. Bloating each one of those and making the work of
the developers harder in the name of a readability win that I just don't see doesn't sound like something I want to support. :)
Quoted 5 lines
Hmm.. In contrast, what i feel currently is that it may ease the using?of pad setting, not make it harder. Not sure if i overlooked something.
Let's listen to Shawn and Linus W if they have some comments.
While I'm still unconvinced that the generic binding actually adds any value, I'll go and see how converting the MX8M pinctrl will look on a real board.
This will delay rev 2 of this series a bit, but I hope to have something to send out tomorrow.
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
Quoted 88 lines
-----Original Message-----
From: Lucas Stach [mailto:l.stach at pengutronix.de]
Sent: Friday, January 26, 2018 2:03 AM
To: Dong Aisheng <[email protected]>; Linus Walleij <[email protected]>
Cc: Shawn Guo <[email protected]>; Mark Rutland <[email protected]>; devicetree at vger.kernel.org; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; patchwork-lst at pengutronix.de; Rob Herring <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; linux- arm-kernel at lists.infradead.org; A.s. Dong <[email protected]>; dl-linux- imx <[email protected]>
Subject: Re: [PATCH 3/4] arm64: add support for i.MX8M EVK boardAm Donnerstag, den 25.01.2018, 21:03 +0800 schrieb Dong Aisheng:
Quoted 73 lines · Lucas Stach
Quoted 31 lines
Am Donnerstag, den 25.01.2018, 18:49 +0800 schrieb Dong Aisheng:
Quoted 3 lines · Lucas Stach
Quoted 2 lines
Am Donnerstag, den 25.01.2018, 18:10 +0800 schrieb aisheng.dong at codeaurora.org:
[...]
Quoted 17 lines
AFAIK we switched to generic pinconfig since MX7ULP as maintainer
Quoted 9 lines
Quoted 2 lines
won't
access old binding pinctrl drivers.I'm not convinced that the generic pinconf is good fit. For pingroups with different configs for some of the pins, like the example above, we would need to split things into multiple DT nodes. This really hurts readability, so I'm not going to switch to the generic stuff without some really convincing arguments.
Per my understanding, based on the last discussion with Linus W, we actually did this in order to increase the readability that 1) user does not need?to see the 'ugly' unreadable raw data and refer to reference manual 2)?unified generic binding format which already exist in kernel and used by many platforms.
Quoted 7 lines
Actually MXS platform already used it for many years in a similar way.
So IMHO a little hurt to add another node for different pad setting in the same group won't be enough reason to stop switching to generic config.Does it make sense?
Quoted 8 lines
I know that Linus W is pushing for this common pinconf thing in the name of readability. It's just that I don't think it's such a clear win.
After all you still need to look into the reference manual or binding to see which values in the common binding correspond to a specific drive/pull strength, etc.
User don't need to look into reference manual and they don't need to compose the 'ulgy' raw data which is the most tough thing.
With generic binding, it probably can saving ~80% pad setting effort by refer to the defined generic config properties.
And things can be even better when the reference code is already there as user becomes know which property supported.Quoted 11 lines
On the other hand it really bloats the DT description of the pin configuration. If you want to look at an (IMHO) bad example, go look at the Tegra DTs. The Tegra pincontrol implements the "separate properties for each pinconf option" that is pushed by Linus W. This bloated the DT description to the point that no-one is able/willing to write those descriptions anymore and the only viable way to get them is to
auto-
generate them from some spreadsheets. Not really what I would call an readable...I wonder the worst case you're worrying whether exist in reality. Take imx6qdl-sabresd as an example, about half of pingroups having the same pad setting while others have two different settings at most. That means it may not bloat the device tree too much.
Quoted 6 lines
Maybe I'm a little stubborn when it comes to this topic, but at Pengutronix we see a lot of customer designs where we need to come up with the board DT. Bloating each one of those and making the work of the developers harder in the name of a readability win that I just don't see doesn't sound like something I want to support. :)
Quoted 9 lines
Quoted 5 lines
Hmm.. In contrast, what i feel currently is that it may ease the using of pad setting, not make it harder. Not sure if i overlooked something.
Let's listen to Shawn and Linus W if they have some comments.
While I'm still unconvinced that the generic binding actually adds any value, I'll go and see how converting the MX8M pinctrl will look on a real board.
You can refer to what we've done for MX7ULP.
Quoted 3 lines
This will delay rev 2 of this series a bit, but I hope to have something to send out tomorrow.
Sorry for making the trouble.
Regards
Dong Aisheng
Quoted 2 lines
Regards,
Lucas
PATCH 3/4 arm64: add support for i.MX8M EVK board
In reply to Lucas StachHi Lucas,
Quoted 18 lines · Lucas Stach
This is the evaluation kit board for the i.MX8M. The current level of support yields a working console and is able to boot userspace from SD card or Network.
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/nxp/Makefile | 3 + arch/arm64/boot/dts/nxp/imx8mq-evk.dts | 287 +++++++++++++++++++++++++++++++++ 2 files changed, 290 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/Makefile create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-evk.dtsarch/arm64/boot/dts/nxp/Makefile new file +0
-0
arch/arm64/boot/dts/nxp/Makefile line 3
Quoted 3 lines
arch/arm64/boot/dts/nxp/Makefile new file +3
-0@@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +dtb-$(CONFIG_SOC_IMX8MQ) += imx8m-evk.dtb
Typo, should be imx8mq-evk.dtb. Without this fix I'm getting:
make[2]: *** No rule to make target 'arch/arm64/boot/dts/nxp/imx8m-evk.dtb', needed by '__build'. Stop.
baruch
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -PATCH 3/4 arm64: add support for i.MX8M EVK board
Hi Lucas,
Quoted 25 lines · Baruch Siach
Quoted 18 lines · Lucas Stach
This is the evaluation kit board for the i.MX8M. The current level of support yields a working console and is able to boot userspace from SD card or Network.
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/nxp/Makefile | 3 + arch/arm64/boot/dts/nxp/imx8mq-evk.dts | 287 +++++++++++++++++++++++++++++++++ 2 files changed, 290 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/Makefile create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-evk.dtsarch/arm64/boot/dts/nxp/Makefile new file +0
-0arch/arm64/boot/dts/nxp/Makefile line 3
Quoted 3 lines
arch/arm64/boot/dts/nxp/Makefile new file +3
-0@@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +dtb-$(CONFIG_SOC_IMX8MQ) += imx8m-evk.dtbTypo, should be imx8mq-evk.dtb. Without this fix I'm getting:
Quoted 1 line
make[2]: *** No rule to make target '
arch/arm64/boot/dts/nxp/imx8m-evk.dtb', needed by '__build'. Stop.
With this fix and CONFIG_CPU_IDLE disabled:
On i.MX8MQ EVK rev B3.
Thanks,
baruch
Signature · 3 lines
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -Rob Herring
maintainerPATCH 3/4 arm64: add support for i.MX8M EVK board
In reply to Lucas StachQuoted 27 lines · Lucas Stach
This is the evaluation kit board for the i.MX8M. The current level of support yields a working console and is able to boot userspace from SD card or Network.
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/boot/dts/nxp/Makefile | 3 + arch/arm64/boot/dts/nxp/imx8mq-evk.dts | 287 +++++++++++++++++++++++++++++++++ 2 files changed, 290 insertions(+) create mode 100644 arch/arm64/boot/dts/nxp/Makefile create mode 100644 arch/arm64/boot/dts/nxp/imx8mq-evk.dtsarch/arm64/boot/dts/nxp/Makefile new file +3
-0@@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +dtb-$(CONFIG_SOC_IMX8MQ) += imx8m-evk.dtbarch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +0
-0
arch/arm64/boot/dts/nxp/imx8mq-evk.dts line 9
Quoted 9 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +9
-0@@ -0,0 +1,287 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) + +/dts-v1/; + +#include "imx8mq.dtsi" + +/ { + model = "NXP i.MX8MQ EVK"; + compatible = "nxp,imx8mq-evk", "nxp,imx8mq";
Documentation?
arch/arm64/boot/dts/nxp/imx8mq-evk.dts line 20
Quoted 11 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +11
-0+ + chosen { + stdout-path = &uart1; + }; + + memory at 40000000 { + device_type = "memory"; + reg = <0x00000000 0x40000000 0 0xc0000000>; + }; + + reg_usdhc2_vmmc: usdhc2_vmmc {
Don't use '_'. Also, ideally this would follow generic node name convention, but we don't have anything defined and regulator binding is a bit odd. "regulator-3V3" perhaps.
Quoted 15 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +15
-0+ pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_reg_usdhc2>; + compatible = "regulator-fixed"; + regulator-name = "VSD_3V3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; +}; + +&fec1 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_fec1>; + phy-mode = "rgmii-id";
arch/arm64/boot/dts/nxp/imx8mq-evk.dts line 45
Quoted 10 lines
arch/arm64/boot/dts/nxp/imx8mq-evk.dts new file +10
-0+ status = "okay"; +}; + +&i2c1 { + clock-frequency = <100000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1>; + status = "okay"; + + pfuze100 at 8 {
pmic at 8
Rob
PATCH 4/4 MAINTAINERS: add i.MX8 DT path to i.MX architecture
In reply to Lucas StachShawn agreed to take patches for the i.MX8 parts through his tree.
--- MAINTAINERS | 1 + 1 file changed, 1 insertion(+)
MAINTAINERS +1 -0
@@ -1390,6 +1390,7 @@ F: arch/arm/mach-imx/ F: arch/arm/mach-mxs/ F: arch/arm/boot/dts/imx* F: arch/arm/configs/imx*_defconfig +F: arch/arm64/boot/dts/nxp/ F: drivers/clk/imx/ F: drivers/soc/imx/ F: include/soc/imx/
Signature · 1 line
2.11.0
Fabio Estevam
reviewerPATCH 4/4 MAINTAINERS: add i.MX8 DT path to i.MX architecture
Quoted 3 lines · Lucas Stach
Shawn agreed to take patches for the i.MX8 parts through his tree.
Signed-off-by Lucas Stach <[email protected]>
Fabio Estevam
reviewerPATCH 1/4 ARM64: add basic Kconfig symbols for i.MX8
In reply to Lucas StachQuoted 11 lines · Lucas Stach
Signed-off-by Lucas Stach <[email protected]>--- arch/arm64/Kconfig.platforms | 6 ++++++ drivers/soc/imx/Kconfig | 12 ++++++++++++ 2 files changed, 18 insertions(+)arch/arm64/Kconfig.platforms +0
-0
arch/arm64/Kconfig.platforms config ARCH_MVEBU · line 137
Quoted 7 lines
arch/arm64/Kconfig.platforms +4
-0@@ -131,6 +131,12 @@ config ARCH_MVEBU - Armada 7K SoC Family - Armada 8K SoC Family +config ARCH_MXC + bool "ARMv8 based NXP i.MX SoC family" + help + This enabled support for the ARMv8 based SoCs in the
s/enabled/enables