arm64: imx: add imx8qxp support
Subsystems (3)
v2 cover arm64: imx: add imx8qxp support
Add imx8qxp mek basic support with the function
Lpuart
uSDHC
FEC
GPIO
Note it depends on the clock and pinctrl driver parts.
Dong Aisheng (4):
arm64: imx: add imx8qxp support
arm64: dts: imx: add imx8qxp support
arm64: dts: imx: add imx8qxp mek support
defconfig: arm64: add imx8qxp support
Documentation/devicetree/bindings/arm/fsl.txt | 8 + arch/arm64/Kconfig.platforms | 22 + arch/arm64/boot/dts/freescale/Makefile | 1 + arch/arm64/boot/dts/freescale/imx8-ca35.dtsi | 61 ++ arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 134 ++++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 861 ++++++++++++++++++++++++++ arch/arm64/configs/defconfig | 6 + 7 files changed, 1093 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8-ca35.dtsi create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp.dtsi
Signature · 1 line
2.7.4
PATCH v2 1/4 arm64: imx: add imx8qxp support
Add imx8qxp support.
---v1->v2:
* update CONFIG option name
--- arch/arm64/Kconfig.platforms | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+)
arch/arm64/Kconfig.platforms +22 -0
@@ -139,6 +139,28 @@ config ARCH_MVEBU - Armada 7K SoC Family - Armada 8K SoC Family +config ARCH_MXC + bool "ARMv8 based NXP i.MX SoC family" + select GPIOLIB + select PINCTRL + select PM + select PM_GENERIC_DOMAINS + select SOC_BUS + help + This enables support for the ARMv8 based SoCs in the + NXP i.MX family. + +config SOC_IMX8QXP + bool "i.MX8QXP" + depends on ARCH_MXC + select IMX_MBOX + select IMX_SCU + select IMX_SCU_PD + select MXC_CLK_SCU + select PINCTRL_IMX8QXP + help + This enables support for NXP i.MX8QXP SoC. + config ARCH_QCOM bool "Qualcomm Platforms" select GPIOLIB
Signature · 1 line
2.7.4
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
In reply to A.s. DongAdd imx8qxp support
---v1->v2:
* mu binding usage update
* no define for node address
* do not use '_' for node name
* drop 'fsl-' prefix for imx dtsi
* no defines for unit address
* generic node names
* range map for 32bit register
* separate board dts
--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/imx8-ca35.dtsi | 61 ++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 861 ++++++++++++++++++++++++++ 3 files changed, 926 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8-ca35.dtsi create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp.dtsi
Documentation/devicetree/bindings/arm/fsl.txt +4 -0
@@ -119,6 +119,10 @@ i.MX6q generic board Required root node properties: - compatible = "fsl,imx6q"; +i.MX8QXP generic board +Required root node properties: + - compatible = "fsl,imx8qxp"; + Freescale Vybrid Platform Device Tree Bindings ----------------------------------------------
arch/arm64/boot/dts/freescale/imx8-ca35.dtsi new file +61 -0
61 lines not on this page · raw message
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +861 -0
861 lines not on this page · raw message
Signature · 1 line
2.7.4
Fabio Estevam
reviewerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Hi Dong,
Quoted 2 lines · A.s. Dong
Add imx8qxp support
You could probably expand the commit log by explaining a bit of what im8qxp means.
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 4
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0@@ -0,0 +1,861 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXP
I guess you meant "-" instead of "~".
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 29
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0+ memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x40000000>; + };
This should go to the board dts file instead as the memory size may vary from board to board.
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 12 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +12
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain { + #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;
The number after @ is in hex, so the reg property should be 0x191.
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 9 lines · Fabio Estevam
Hi Dong,
Quoted 3 lines · A.s. Dong
Add imx8qxp support
You could probably expand the commit log by explaining a bit of what im8qxp means.
Also a link to documentation would be really helpful for reviewers.
thanks,
Daniel.
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
In reply to Fabio EstevamQuoted 6 lines · Fabio Estevam
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain {
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;The number after @ is in hex, so the reg property should be
0x191.
These are SC_R_* resource ids from include/linux/firmware/imx/types.h and they are almost everywhere referenced as decimals.
Is this really not acceptable for DT?
--
Regards,
Leonard
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 20 lines
-----Original Message-----
From: Leonard Crestez
Sent: Monday, October 15, 2018 3:30 PMQuoted 6 lines · Fabio Estevam
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain {Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;The number after @ is in hex, so the reg property should be
0x191.
Quoted 5 lines
These are SC_R_* resource ids from
include/linux/firmware/imx/types.hand they are almost everywhere referenced as decimals.Is this really not acceptable for DT?
I think the problem is mismatch as DT binding request the reg property value must be equal to the unit-address.
See:
https://github.com/devicetree-org/devicetree-specification/releases
It seems like a common issue in the kernel as I see many similar users.
Regards
Dong Aisheng
Quoted 3 lines
--
Regards,
Leonard
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
In reply to Fabio EstevamQuoted 14 lines
-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Monday, October 15, 2018 7:14 AM
To: A.s. Dong <[email protected]>
Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <[email protected]>; Dong Aisheng <[email protected]>; Sascha Hauer <[email protected]>; Shawn Guo <[email protected]>; Fabio Estevam <[email protected]>; Rob Herring <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; dl-linux-imx <[email protected]>; Mark Rutland <[email protected]>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <[email protected]>
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp support
Quoted 9 lines
Hi Dong,
Quoted 2 lines · A.s. Dong
Add imx8qxp support
You could probably expand the commit log by explaining a bit of what im8qxp means.
Got it, thanks for the suggestion.
Quoted 14 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 4
Quoted 11 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0@@ -0,0 +1,861 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXPI guess you meant "-" instead of "~".
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 29
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0+ memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x40000000>; + };This should go to the board dts file instead as the memory size may vary from board to board.
That's right. Will change it.
Quoted 6 lines
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain {
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;The number after @ is in hex, so the reg property should be
0x191.
Thanks for the reminder.
The PD ID is defined in DEC. So I will change them all into HEX later manually.
BTW, this seems like error prone and checkpatch can't report it. And I notice many similar users in kernel with the same issue:arch/arm/boot/dts/tps65910.dtsi arch/arm/boot/dts/tegra124-nyan.dtsi arch/arm/boot/dts/rk3288.dtsi
...
Regards
Dong Aisheng
Rob Herring
maintainerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 66 lines · A.s. Dong
Quoted 14 lines
-----Original Message-----
From: Fabio Estevam [mailto:festevam at gmail.com]
Sent: Monday, October 15, 2018 7:14 AM
To: A.s. Dong <[email protected]>
Cc: moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE <[email protected]>; Dong Aisheng <[email protected]>; Sascha Hauer <[email protected]>; Shawn Guo <[email protected]>; Fabio Estevam <[email protected]>; Rob Herring <[email protected]>; Catalin Marinas <[email protected]>; Will Deacon <[email protected]>; dl-linux-imx <[email protected]>; Mark Rutland <[email protected]>; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <[email protected]>
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 9 lines
Hi Dong,
Quoted 2 lines · A.s. Dong
Add imx8qxp support
You could probably expand the commit log by explaining a bit of what im8qxp means.
Got it, thanks for the suggestion.
Quoted 14 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 4
Quoted 11 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0@@ -0,0 +1,861 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXPI guess you meant "-" instead of "~".
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 29
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +4
-0+ memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x40000000>; + };This should go to the board dts file instead as the memory size may vary from board to board.
That's right. Will change it.
Quoted 6 lines
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain {Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;The number after @ is in hex, so the reg property should be
0x191.
Quoted 4 lines
Thanks for the reminder.
The PD ID is defined in DEC. So I will change them all into HEX later manually.BTW, this seems like error prone and checkpatch can't report it.
checkpatch doesn't really check dts files.
But if it did would you have noticed? Because there is at least one checkpatch issue with your author name and S-o-b name not matching.
Quoted 4 lines
And I notice many similar users in kernel with the same issue:
arch/arm/boot/dts/tps65910.dtsiarch/arm/boot/dts/tegra124-nyan.dtsiarch/arm/boot/dts/rk3288.dtsi
At least I2C and SPI are now checked by dtc. 'simple-bus' children were too, but silently broke and only recently got fixed in upstream dtc. I've not pulled that into the kernel yet, but you can build dtbs using an external copy of dtc. And guess what, there are *lots* of warnings.
Rob
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
[...]
Quoted 30 lines
Quoted 15 lines
Quoted 6 lines
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ imx8qx-pm { + compatible = "fsl,scu-pd"; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio: lsio-power-domain {Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 81
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +6
-0+ #power-domain-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + pd_lsio_pwm0: lsio-pwm0 at 191 { + reg = <191>;The number after @ is in hex, so the reg property should be
0x191.Quoted 4 lines
Thanks for the reminder.
The PD ID is defined in DEC. So I will change them all into HEX later manually.BTW, this seems like error prone and checkpatch can't report it.
checkpatch doesn't really check dts files.
But if it did would you have noticed? Because there is at least one checkpatch issue with your author name and S-o-b name not matching.
Quoted 4 lines
And I notice many similar users in kernel with the same issue:
arch/arm/boot/dts/tps65910.dtsiarch/arm/boot/dts/tegra124-nyan.dtsiarch/arm/boot/dts/rk3288.dtsi
Quoted 5 lines
At least I2C and SPI are now checked by dtc. 'simple-bus' children were too, but silently broke and only recently got fixed in upstream dtc.
I've not pulled that into the kernel yet, but you can build dtbs using an external copy of dtc. And guess what, there are *lots* of warnings.
Thanks for the info. Will try it.
Regards
Dong Aisheng
Quoted 1 line
Rob
Sascha Hauer
maintainerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
In reply to A.s. DongQuoted 176 lines · A.s. Dong
Add imx8qxp support
Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Cc devicetree at vger.kernel.orgCc Shawn Guo <[email protected]>Cc Sascha Hauer <[email protected]>Cc Fabio Estevam <[email protected]>Signed-off-by Dong Aisheng <[email protected]>---
v1->v2:
* mu binding usage update
* no define for node address
* do not use '_' for node name
* drop 'fsl-' prefix for imx dtsi
* no defines for unit address
* generic node names
* range map for 32bit register
* separate board dts--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/imx8-ca35.dtsi | 61 ++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 861 ++++++++++++++++++++++++++ 3 files changed, 926 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8-ca35.dtsi create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp.dtsiDocumentation/devicetree/bindings/arm/fsl.txt +4
-0@@ -119,6 +119,10 @@ i.MX6q generic board Required root node properties: - compatible = "fsl,imx6q"; +i.MX8QXP generic board +Required root node properties: + - compatible = "fsl,imx8qxp"; + Freescale Vybrid Platform Device Tree Bindings ----------------------------------------------arch/arm64/boot/dts/freescale/imx8-ca35.dtsi new file +61
-0@@ -0,0 +1,61 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXP + */ + +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/{ + cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 1 clusters with 4 Cortex-A35 cores */ + A35_0: cpu at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_1: cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x1>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_2: cpu at 2 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x2>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_3: cpu at 3 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x3>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_L2: l2-cache0 { + compatible = "cache"; + }; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; +};arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +61
-0@@ -0,0 +1,861 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXP + * Dong Aisheng <[email protected]> + */ + +#include <dt-bindings/clock/imx8qxp-clock.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/pinctrl/pads-imx8qxp.h> + +#include "imx8-ca35.dtsi" + +/ { + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &dma_lpuart0; + mmc0 = &usdhc1; + mmc1 = &usdhc2; + mmc2 = &usdhc3; + }; + + memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x40000000>; + }; + + gic: interrupt-controller at 51a00000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */ + <0x0 0x51b00000 0 0xc0000>; /* GICR (RD_base + SGI_base) */ + #interrupt-cells = <3>; + interrupt-controller; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* Physical Secure */ + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* Physical Non-Secure */ + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* Virtual */ + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* Hypervisor */ + }; + + scu { + compatible = "fsl,imx-scu"; + mbox-names = "tx0", "tx1", "tx2", "tx3", + "rx0", "rx1", "rx2", "rx3"; + mboxes = <&lsio_mu1 0 0 + &lsio_mu1 0 1 + &lsio_mu1 0 2 + &lsio_mu1 0 3 + &lsio_mu1 1 0 + &lsio_mu1 1 1 + &lsio_mu1 1 2 + &lsio_mu1 1 3>; + + clk: clock-controller {
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +10
-0+ compatible = "fsl,imx8qxp-clk"; + #clock-cells = <1>; + }; + + iomuxc: pinctrl { + compatible = "fsl,imx8qxp-iomuxc"; + }; + + imx8qx-pm { + compatible = "fsl,scu-pd";
I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 3 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";
All these lack the most specific imx8qp compatible.
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 698
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ compatible = "fsl,imx6sx-fec"; + compatible = "fsl,imx8qxp-fec";
BTW are there really two different FECs on the i.MX8qp?
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 200 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 2:59 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 19 lines · A.s. Dong
Add imx8qxp support
Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Cc devicetree at vger.kernel.orgCc Shawn Guo <[email protected]>Cc Sascha Hauer <[email protected]>Cc Fabio Estevam <[email protected]>Signed-off-by Dong Aisheng <[email protected]>---
v1->v2:
* mu binding usage update
* no define for node address
* do not use '_' for node name
* drop 'fsl-' prefix for imx dtsi
* no defines for unit address
* generic node names
* range map for 32bit register
* separate board dtsQuoted 4 lines
--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/imx8-ca35.dtsi | 61 ++ arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 861++++++++++++++++++++++++++
Quoted 119 lines
3 files changed, 926 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8-ca35.dtsi create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp.dtsiDocumentation/devicetree/bindings/arm/fsl.txt +0
-0@@ -119,6 +119,10 @@ i.MX6q generic board Required root nodeproperties:
- compatible = "fsl,imx6q";Documentation/devicetree/bindings/arm/fsl.txt +4
-0+i.MX8QXP generic board +Required root node properties: + - compatible = "fsl,imx8qxp"; + Freescale Vybrid Platform Device Tree Bindings ----------------------------------------------arch/arm64/boot/dts/freescale/imx8-ca35.dtsi new file +61
-0@@ -0,0 +1,61 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXP + */ + +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/{ + cpus { + #address-cells = <2>; + #size-cells = <0>; + + /* We have 1 clusters with 4 Cortex-A35 cores */ + A35_0: cpu at 0 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_1: cpu at 1 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x1>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_2: cpu at 2 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x2>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_3: cpu at 3 { + device_type = "cpu"; + compatible = "arm,cortex-a35"; + reg = <0x0 0x3>; + enable-method = "psci"; + next-level-cache = <&A35_L2>; + }; + + A35_L2: l2-cache0 { + compatible = "cache"; + }; + }; + + pmu { + compatible = "arm,armv8-pmuv3"; + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; + + psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; +};arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +24
-0@@ -0,0 +1,861 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * Copyright 2017~2018 NXP + * Dong Aisheng <[email protected]> + */ + +#include <dt-bindings/clock/imx8qxp-clock.h> +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/pinctrl/pads-imx8qxp.h> + +#include "imx8-ca35.dtsi" + +/ { + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &dma_lpuart0; + mmc0 = &usdhc1; + mmc1 = &usdhc2; + mmc2 = &usdhc3; + };arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 34
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +10
-0+ + memory at 80000000 { + device_type = "memory"; + reg = <0x00000000 0x80000000 0 0x40000000>; + }; + + gic: interrupt-controller at 51a00000 { + compatible = "arm,gic-v3"; + reg = <0x0 0x51a00000 0 0x10000>, /* GIC Dist */ + <0x0 0x51b00000 0 0xc0000>; /* GICR (RD_base + SGI_base)*/
arch/arm64/boot/dts/freescale/imx8qxp.dtsi
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +8
-0+ #interrupt-cells = <3>; + interrupt-controller; + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* Physical Secure*/
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 43
Quoted 1 line
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +1
-0+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* PhysicalNon-Secure */
Quoted 23 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +23
-0+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* Virtual */ + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* Hypervisor */ + }; + + scu { + compatible = "fsl,imx-scu"; + mbox-names = "tx0", "tx1", "tx2", "tx3", + "rx0", "rx1", "rx2", "rx3"; + mboxes = <&lsio_mu1 0 0 + &lsio_mu1 0 1 + &lsio_mu1 0 2 + &lsio_mu1 0 3 + &lsio_mu1 1 0 + &lsio_mu1 1 1 + &lsio_mu1 1 2 + &lsio_mu1 1 3>; + + clk: clock-controller { + compatible = "fsl,imx8qxp-clk"; + #clock-cells = <1>; + }; + + iomuxc: pinctrl {
Quoted 9 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +5
-0+ compatible = "fsl,imx8qxp-iomuxc"; + }; + + imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities.
SCU IPC is designed to be generic to all MX8 SCU firmwares. Even it changes, SCU firmware version control may helps.
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 3 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";All these lack the most specific imx8qp compatible.
Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features are really supported by the drivers.
Do you think it's okay?
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 698
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ compatible = "fsl,imx6sx-fec"; + compatible = "fsl,imx8qxp-fec";BTW are there really two different FECs on the i.MX8qp?
Good catch, will alignment them all to fsl,imx6sx-fec.
Regards
Dong Aisheng
Quoted 17 lines
Sascha
--
Pengutronix e.K. |
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7Cf1 897d4035174ffda74808d6326bb448%7C686ea1d3bc2b4c6fa92cd99c5c3016 35%7C0%7C0%7C636751835496320764&sdata=J0MO38TWN91LWL3W 5SZk3y1v3PLyHzhNHl0L8jS1xcE%3D&reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
Sascha Hauer
maintainerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 10 lines · A.s. Dong
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities.
SCU IPC is designed to be generic to all MX8 SCU firmwares.
And i.MX9? i.MX10?
Quoted 1 line
Even it changes, SCU firmware version control may helps.
It's not the first time that the position of the version field changes with a newer version.
Quoted 8 lines
Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";All these lack the most specific imx8qp compatible.
Quoted 4 lines
Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features are really supported by the drivers.
Do you think it's okay?
Newer Kernels should work with older device trees, so once you roll out these compatibles it's too late already.
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 19 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 4:28 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 7 lines · A.s. Dong
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
Quoted 6 lines
Quoted 3 lines
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities.
SCU IPC is designed to be generic to all MX8 SCU firmwares.And i.MX9? i.MX10?
MX8DM MX8DXP
Quoted 5 lines
Quoted 1 line
Even it changes, SCU firmware version control may helps.
It's not the first time that the position of the version field changes with a newer version.
I understand your worry.
Up till now all SCU firmware based SoCs are all using one generic IPC driver internally. And I have not heard a possible changing in the future.
I double checked the SCU firmware implementation that the IPC
Is deigned to be platform independent. So it's less to be changed.
So I wonder if this could be over worried.
Even it is changed, (quite less probility), we still can user version
To distinguish them, just like arm,scpi , arm,scmi. Right?
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 4 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";All these lack the most specific imx8qp compatible.
Quoted 8 lines
Quoted 4 lines
Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features are really supported by the drivers.
Do you think it's okay?Newer Kernels should work with older device trees, so once you roll out these compatibles it's too late already.
The backwards compatible string is used to guarantee a basic function. Even we add qxp specific compatible string later, it still can work with backwards function. So I'm not quite get what the real problem is. And this is the initial support that we don't expect the full features with such an early device tree, right?
Regards
Dong Aisheng
Quoted 15 lines
Sascha
--
Pengutronix e.K. |
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C33 7b52b64a9d4b1f2c5c08d632781dcf%7C686ea1d3bc2b4c6fa92cd99c5c30163 5%7C0%7C0%7C636751888819600237&sdata=rPKmWjR87ig5Q%2FFfTP ZvXtPvLbqt6pZYkINKdhgVwE8%3D&reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
Sascha Hauer
maintainerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 19 lines · A.s. Dong
Quoted 19 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 4:28 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 7 lines · A.s. Dong
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities.
SCU IPC is designed to be generic to all MX8 SCU firmwares.And i.MX9? i.MX10?
MX8DM MX8DXP
I was not talking about existing SoCs, I was talking about future SoCs.
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
Even it changes, SCU firmware version control may helps.
It's not the first time that the position of the version field changes with a newer version.
Quoted 8 lines
I understand your worry.
Up till now all SCU firmware based SoCs are all using one generic IPC driver internally. And I have not heard a possible changing in the future.
I double checked the SCU firmware implementation that the IPC
Is deigned to be platform independent. So it's less to be changed.
So I wonder if this could be over worried.
Even it is changed, (quite less probility), we still can user version
To distinguish them, just like arm,scpi , arm,scmi. Right?
You can still add and use a generic compatible, but does it hurt when you add a SoC specific one that you *can* use should you have to?
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";All these lack the most specific imx8qp compatible.
Quoted 8 lines
Quoted 4 lines
Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features are really supported by the drivers.
Do you think it's okay?Newer Kernels should work with older device trees, so once you roll out these compatibles it's too late already.
Quoted 5 lines
The backwards compatible string is used to guarantee a basic function. Even we add qxp specific compatible string later, it still can work with backwards function. So I'm not quite get what the real problem is. And this is the initial support that we don't expect the full features with such an early device tree, right?
By not adding a SoC compatible you lose the possibility to add a SoC specific fixup without changing the device tree or you have to work with quirks like:
https://elixir.bootlin.com/linux/latest/source/drivers/clocksource/timer-imx-gpt.c#L521
or
https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-imx.c#L1182
So far we have added new compatibles with each new SoC type for good reasons, so why should we change this?
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
PATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 60 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 5:41 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 20 lines · A.s. Dong
Quoted 20 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 4:28 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 7 lines · A.s. Dong
Quoted 6 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 71
Quoted 2 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +2
-0+ imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities. SCU IPC is designed to be generic to all MX8 SCU firmwares.
And i.MX9? i.MX10?
MX8DM MX8DXP
I was not talking about existing SoCs, I was talking about future SoCs.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Even it changes, SCU firmware version control may helps.
It's not the first time that the position of the version field changes with a newer version.
I understand your worry.
Up till now all SCU firmware based SoCs are all using one generic IPC driverinternally.
Quoted 6 lines
And I have not heard a possible changing in the future.
I double checked the SCU firmware implementation that the IPC Is deigned to be platform independent. So it's less to be changed. So I wonder if this could be over worried.
Even it is changed, (quite less probility), we still can user version To distinguish them, just like arm,scpi , arm,scmi. Right?
Quoted 3 lines
You can still add and use a generic compatible, but does it hurt when you add a SoC specific one that you *can* use should you have to?
Do you mean only change "fsl,scu-pd" to "fsl,imx8qxp-scu-pd"? And keep the "fsl,imx-scu" as it is, right?
I guess I may be over-anxious, sorry for that if it's true.
Quoted 43 lines
Quoted 18 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi line 633
Quoted 5 lines
arch/arm64/boot/dts/freescale/imx8qxp.dtsi new file +3
-0+ compatible = "fsl,imx7ulp-lpuart"; + compatible = "fsl,imx7ulp-lpi2c"; + compatible = "fsl,imx7d-usdhc";All these lack the most specific imx8qp compatible.
Quoted 8 lines
Quoted 4 lines
Adding them requires binding doc update as well.
S I suppose they could be added later when the QXP specific features are really supported by the drivers.
Do you think it's okay?Newer Kernels should work with older device trees, so once you roll out these compatibles it's too late already.
Quoted 5 lines
The backwards compatible string is used to guarantee a basic function. Even we add qxp specific compatible string later, it still can work with backwards function. So I'm not quite get what the real problem is. And this is the initial support that we don't expect the full features with such an early device tree, right?
By not adding a SoC compatible you lose the possibility to add a SoC specific fixup without changing the device tree or you have to work with quirks like:
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.
bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fclocksource%2Ftimer-i mx-gpt.c%23L521&data=02%7C01%7Caisheng.dong%40nxp.com%7Ce0a 58f79a6b24fd248c308d6328251f0%7C686ea1d3bc2b4c6fa92cd99c5c301635 %7C0%7C0%7C636751932632219124&sdata=P9ncjvrhubRASh%2BOu7X %2FNbAtch3aSqvqqSVLSdb%2BQ2c%3D&reserved=0or
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.
bootlin.com%2Flinux%2Flatest%2Fsource%2Fdrivers%2Fspi%2Fspi-imx.c%23L1 182&data=02%7C01%7Caisheng.dong%40nxp.com%7Ce0a58f79a6b24fd 248c308d6328251f0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7 C636751932632219124&sdata=blvN1%2FBbm7hZr7ddA7MAkIuqM5wk 0%2Bv3DvifalAWV0w%3D&reserved=0
Quoted 3 lines
So far we have added new compatibles with each new SoC type for good reasons, so why should we change this?
Yes, I fully understand. Just was wondering whether it can be done later. But I think there's no bad to do it right now.
So I agree with it.
Thanks for the suggestion.
Regards
Dong Aisheng
Quoted 15 lines
Sascha
--
Pengutronix e.K. |
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7Ce0 a58f79a6b24fd248c308d6328251f0%7C686ea1d3bc2b4c6fa92cd99c5c30163 5%7C0%7C0%7C636751932632219124&sdata=Qd1KhPokzveWzr%2BBo HX%2F9jZSx3oiEkR47w4ABA1Deqg%3D&reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
Sascha Hauer
maintainerPATCH v2 2/4 arm64: dts: imx: add imx8qxp support
Quoted 60 lines · A.s. Dong
Quoted 60 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 5:41 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 20 lines · A.s. Dong
Quoted 20 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 4:28 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; Mark Rutland <[email protected]>; dongas86 at gmail.com; devicetree at vger.kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; robh+dt at kernel.org; dl-linux-imx <[email protected]>; kernel at pengutronix.de; Fabio Estevam <[email protected]>; shawnguo at kernel.org
Subject: Re: [PATCH V2 2/4] arm64: dts: imx: add imx8qxp supportQuoted 7 lines · A.s. Dong
Quoted 6 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ imx8qx-pm { + compatible = "fsl,scu-pd";I missed this earlier, but there should be a i.MX8qp specific compatible as the SCU API might change for future SoCs.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
We still do not see that requirement up till now. Not sure if it would be possible in the future. I see low possibilities. SCU IPC is designed to be generic to all MX8 SCU firmwares.
And i.MX9? i.MX10?
MX8DM MX8DXP
I was not talking about existing SoCs, I was talking about future SoCs.
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Even it changes, SCU firmware version control may helps.
It's not the first time that the position of the version field changes with a newer version.
I understand your worry.
Up till now all SCU firmware based SoCs are all using one generic IPC driverinternally.
Quoted 6 lines
And I have not heard a possible changing in the future.
I double checked the SCU firmware implementation that the IPC Is deigned to be platform independent. So it's less to be changed. So I wonder if this could be over worried.
Even it is changed, (quite less probility), we still can user version To distinguish them, just like arm,scpi , arm,scmi. Right?
Quoted 6 lines
Quoted 3 lines
You can still add and use a generic compatible, but does it hurt when you add a SoC specific one that you *can* use should you have to?
Do you mean only change "fsl,scu-pd" to "fsl,imx8qxp-scu-pd"? And keep the "fsl,imx-scu" as it is, right?
Yes, that's what I meant.
Sascha
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
PATCH v2 3/4 arm64: dts: imx: add imx8qxp mek support
In reply to A.s. DongAdd imx8qxp mek board support.
--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/Makefile | 1 + arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 134 ++++++++++++++++++++++++++ 3 files changed, 139 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
Documentation/devicetree/bindings/arm/fsl.txt +4 -0
@@ -97,6 +97,10 @@ i.MX7 SabreSD Board Required root node properties: - compatible = "fsl,imx7d-sdb", "fsl,imx7d"; +i.MX8QXP MEK Board +Required root node properties: + - compatible = "fsl,imx8qxp-mek", "fsl,imx8qxp"; + Generic i.MX boards -------------------
arch/arm64/boot/dts/freescale/Makefile +1 -0
@@ -13,3 +13,4 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-rdb.dtb dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2080a-simu.dtb dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-qds.dtb dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls2088a-rdb.dtb +dtb-$(CONFIG_SOC_IMX8QXP) += imx8qxp-mek.dtb
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts new file +134 -0
134 lines not on this page · raw message
Signature · 1 line
2.7.4
Sascha Hauer
maintainerPATCH v2 3/4 arm64: dts: imx: add imx8qxp mek support
Quoted 23 lines · A.s. Dong
Add imx8qxp mek board support.
Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Cc devicetree at vger.kernel.orgCc Shawn Guo <[email protected]>Cc Sascha Hauer <[email protected]>Cc Fabio Estevam <[email protected]>Signed-off-by Dong Aisheng <[email protected]>--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/Makefile | 1 + arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 134 ++++++++++++++++++++++++++ 3 files changed, 139 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts+&iomuxc {
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts new file +6
-0+ pinctrl_fec1: fec1grp { + fsl,pins = < + SC_P_ENET0_MDC_CONN_ENET0_MDC 0x06000020 + SC_P_ENET0_MDIO_CONN_ENET0_MDIO 0x06000020 + SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL 0x06000020 + SC_P_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC 0x06000020
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts line 96
Quoted 10 lines
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts new file +10
-0+ SC_P_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD0 0x06000020 + SC_P_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD1 0x06000020 + SC_P_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD2 0x06000020 + SC_P_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD3 0x06000020 + SC_P_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC 0x06000020 + SC_P_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL 0x06000020 + SC_P_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD0 0x06000020 + SC_P_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD1 0x06000020 + SC_P_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD2 0x06000020 + SC_P_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD3 0x06000020
I doubt these names will be valid for future SoCs. They should have a IMX8QP_ prefix.
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
PATCH v2 3/4 arm64: dts: imx: add imx8qxp mek support
Quoted 56 lines
-----Original Message-----
From: Sascha Hauer [mailto:s.hauer at pengutronix.de]
Sent: Monday, October 15, 2018 3:02 PM
To: A.s. Dong <[email protected]>
Cc: linux-arm-kernel at lists.infradead.org; dongas86 at gmail.com; kernel at pengutronix.de; shawnguo at kernel.org; Fabio Estevam <[email protected]>; robh+dt at kernel.org; catalin.marinas at arm.com; will.deacon at arm.com; dl-linux-imx <[email protected]>; Mark Rutland <[email protected]>; devicetree at vger.kernel.org
Subject: Re: [PATCH V2 3/4] arm64: dts: imx: add imx8qxp mek supportQuoted 18 lines · A.s. Dong
Add imx8qxp mek board support.
Cc Rob Herring <[email protected]>Cc Mark Rutland <[email protected]>Cc devicetree at vger.kernel.orgCc Shawn Guo <[email protected]>Cc Sascha Hauer <[email protected]>Cc Fabio Estevam <[email protected]>Signed-off-by Dong Aisheng <[email protected]>--- Documentation/devicetree/bindings/arm/fsl.txt | 4 + arch/arm64/boot/dts/freescale/Makefile | 1 + arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 134 ++++++++++++++++++++++++++ 3 files changed, 139 insertions(+) create mode 100644 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts+&iomuxc {
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
Quoted 3 lines
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts new file +3
-0+ pinctrl_fec1: fec1grp { + fsl,pins = < + SC_P_ENET0_MDC_CONN_ENET0_MDC0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_MDIO_CONN_ENET0_MDIO0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TX_CTL_CONN_ENET0_RGMII_TX_CTL0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TXC_CONN_ENET0_RGMII_TXC0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TXD0_CONN_ENET0_RGMII_TXD00x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TXD1_CONN_ENET0_RGMII_TXD10x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TXD2_CONN_ENET0_RGMII_TXD20x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_TXD3_CONN_ENET0_RGMII_TXD30x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RXC_CONN_ENET0_RGMII_RXC0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RX_CTL_CONN_ENET0_RGMII_RX_CTL0x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RXD0_CONN_ENET0_RGMII_RXD00x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RXD1_CONN_ENET0_RGMII_RXD10x06000020
Quoted 8 lines
Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RXD2_CONN_ENET0_RGMII_RXD20x06000020Review
Quoted 1 line
(quoted diff) +1
-0+ SC_P_ENET0_RGMII_RXD3_CONN_ENET0_RGMII_RXD30x06000020I doubt these names will be valid for future SoCs. They should have a
IMX8QP_prefix.
I agree, will change them.
Thanks for the suggestion.
Regards
Dong Aisheng
Quoted 13 lines
--
Pengutronix e.K. |
|
Industrial Linux Solutions |
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
pengutronix.de%2F&data=02%7C01%7Caisheng.dong%40nxp.com%7C86 a3443c48ed4c7cd65008d6326c13b0%7C686ea1d3bc2b4c6fa92cd99c5c3016 35%7C0%7C0%7C636751837102721123&sdata=GBMxEXHoTYdhOl3ir9U bwZDsVxDAlefbq74tkuZGalk%3D&reserved=0 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax:
+49-5121-206917-5555 |
PATCH v2 4/4 defconfig: arm64: add imx8qxp support
In reply to A.s. Dong--- arch/arm64/configs/defconfig | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm64/configs/defconfig +6 -0
@@ -45,6 +45,8 @@ CONFIG_ARCH_HISI=y CONFIG_ARCH_MEDIATEK=y CONFIG_ARCH_MESON=y CONFIG_ARCH_MVEBU=y +CONFIG_ARCH_MXC=y +CONFIG_SOC_IMX8QXP=y CONFIG_ARCH_QCOM=y CONFIG_ARCH_ROCKCHIP=y CONFIG_ARCH_SEATTLE=y
@@ -219,6 +221,7 @@ CONFIG_NET_XGENE=y CONFIG_ATL1C=m CONFIG_MACB=y CONFIG_THUNDER_NIC_PF=y +CONFIG_FEC=y CONFIG_HIX5HD2_GMAC=y CONFIG_HNS_DSAF=y CONFIG_HNS_ENET=y
@@ -294,6 +297,8 @@ CONFIG_SERIAL_MSM=y CONFIG_SERIAL_MSM_CONSOLE=y CONFIG_SERIAL_XILINX_PS_UART=y CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y +CONFIG_SERIAL_FSL_LPUART=y +CONFIG_SERIAL_FSL_LPUART_CONSOLE=y CONFIG_SERIAL_MVEBU_UART=y CONFIG_SERIAL_DEV_BUS=y CONFIG_VIRTIO_CONSOLE=y
@@ -514,6 +519,7 @@ CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_OF_ARASAN=y CONFIG_MMC_SDHCI_OF_ESDHC=y CONFIG_MMC_SDHCI_CADENCE=y +CONFIG_MMC_SDHCI_ESDHC_IMX=y CONFIG_MMC_SDHCI_TEGRA=y CONFIG_MMC_SDHCI_F_SDH30=y CONFIG_MMC_MESON_GX=y
Signature · 1 line
2.7.4