* [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-20 20:25 ` Dave Gerlach
0 siblings, 0 replies; 50+ messages in thread
From: Dave Gerlach @ 2021-01-20 20:25 UTC (permalink / raw)
To: Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Dave Gerlach, Tony Lindgren,
Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
providing advanced system integration to enable applications such as
Motor Drives, PLC, Remote IO and IoT Gateways.
Some highlights of this SoC are:
* Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
MCUs, and a single Cortex-M4F.
* Two Gigabit Industrial Communication Subsystems (ICSSG).
* Integrated Ethernet switch supporting up to a total of two external
ports.
* PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
peripherals.
* Centralized System Controller for Security, Power, and Resource
Management (DMSC).
See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
for further details: https://www.ti.com/lit/pdf/spruim2
Introduce basic support for the AM642 SoC to enable ramdisk or MMC
boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
under cbass_main and the i2c, spi, and uart MCU domain periperhals
under cbass_mcu.
Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
4 files changed, 576 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
new file mode 100644
index 000000000000..e3ef4bff04af
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM642 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_main {
+ oc_sram: sram@70000000 {
+ compatible = "mmio-sram";
+ reg = <0x00 0x70000000 0x00 0x200000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x70000000 0x200000>;
+
+ atf-sram@0 {
+ reg = <0x0 0x1a000>;
+ };
+ };
+
+ gic500: interrupt-controller@1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
+ <0x00 0x01840000 0x00 0xC0000>; /* GICR */
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: msi-controller@1820000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x00 0x01820000 0x00 0x10000>;
+ socionext,synquacer-pre-its = <0x1000000 0x400000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ dmss: dmss {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges;
+ ranges;
+
+ secure_proxy_main: mailbox@4d000000 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x00 0x4d000000 0x00 0x80000>,
+ <0x00 0x4a600000 0x00 0x80000>,
+ <0x00 0x4a400000 0x00 0x80000>;
+ interrupt-names = "rx_012";
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ dmsc: dmsc@44043000 {
+ compatible = "ti,k2g-sci";
+ ti,host-id = <12>;
+ mbox-names = "rx", "tx";
+ mboxes= <&secure_proxy_main 12>,
+ <&secure_proxy_main 13>;
+ reg-names = "debug_messages";
+ reg = <0x00 0x44043000 0x00 0xfe0>;
+
+ k3_pds: power-controller {
+ compatible = "ti,sci-pm-domain";
+ #power-domain-cells = <2>;
+ };
+
+ k3_clks: clocks {
+ compatible = "ti,k2g-sci-clk";
+ #clock-cells = <2>;
+ };
+
+ k3_reset: reset-controller {
+ compatible = "ti,sci-reset";
+ #reset-cells = <2>;
+ };
+ };
+
+ main_pmx0: pinctrl@f4000 {
+ compatible = "pinctrl-single";
+ reg = <0x00 0xf4000 0x00 0x2d0>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0xffffffff>;
+ };
+
+ main_conf: syscon@43000000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x00 0x43000000 0x00 0x20000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00 0x00 0x43000000 0x20000>;
+
+ chipid@14 {
+ compatible = "ti,am654-chipid";
+ reg = <0x00000014 0x4>;
+ };
+ };
+
+ main_uart0: serial@2800000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02800000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 146 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart1: serial@2810000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02810000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 152 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart2: serial@2820000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02820000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 153 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart3: serial@2830000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02830000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 154 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart4: serial@2840000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02840000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 155 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart5: serial@2850000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02850000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 156 0>;
+ clock-names = "fclk";
+ };
+
+ main_uart6: serial@2860000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x02860000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 158 0>;
+ clock-names = "fclk";
+ };
+
+ main_i2c0: i2c@20000000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20000000 0x00 0x100>;
+ interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 102 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c1: i2c@20010000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20010000 0x00 0x100>;
+ interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 103 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c2: i2c@20020000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20020000 0x00 0x100>;
+ interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 104 2>;
+ clock-names = "fck";
+ };
+
+ main_i2c3: i2c@20030000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x20030000 0x00 0x100>;
+ interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 105 2>;
+ clock-names = "fck";
+ };
+
+ main_spi0: spi@20100000 {
+ compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
+ reg = <0x00 0x20100000 0x00 0x400>;
+ interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 141 0>;
+ dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
+ dma-names = "tx0", "rx0";
+ };
+
+ main_spi1: spi@20110000 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x00 0x20110000 0x00 0x400>;
+ interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 142 0>;
+ };
+
+ main_spi2: spi@20120000 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x00 0x20120000 0x00 0x400>;
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 143 0>;
+ };
+
+ main_spi3: spi@20130000 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x00 0x20130000 0x00 0x400>;
+ interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 144 0>;
+ };
+
+ main_spi4: spi@20140000 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x00 0x20140000 0x00 0x400>;
+ interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 145 0>;
+ };
+
+ sdhci0: mmc@fa10000 {
+ compatible = "ti,am64-sdhci-8bit";
+ reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
+ clock-names = "clk_ahb", "clk_xin";
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ ti,trm-icp = <0x2>;
+ ti,otap-del-sel-legacy = <0x0>;
+ ti,otap-del-sel-mmc-hs = <0x0>;
+ ti,otap-del-sel-ddr52 = <0x6>;
+ ti,otap-del-sel-hs200 = <0x7>;
+ ti,otap-del-sel-hs400 = <0x4>;
+ };
+
+ sdhci1: mmc@fa00000 {
+ compatible = "ti,am64-sdhci-4bit";
+ reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
+ power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
+ clock-names = "clk_ahb", "clk_xin";
+ ti,trm-icp = <0x2>;
+ ti,otap-del-sel-legacy = <0x0>;
+ ti,otap-del-sel-sd-hs = <0xf>;
+ ti,otap-del-sel-sdr12 = <0xf>;
+ ti,otap-del-sel-sdr25 = <0xf>;
+ ti,otap-del-sel-sdr50 = <0xc>;
+ ti,otap-del-sel-sdr104 = <0x6>;
+ ti,otap-del-sel-ddr50 = <0x9>;
+ ti,clkbuf-sel = <0x7>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
new file mode 100644
index 000000000000..1d2be485a669
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM64 SoC Family MCU Domain peripherals
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+&cbass_mcu {
+ mcu_uart0: serial@4a00000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x04a00000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 149 0>;
+ clock-names = "fclk";
+ };
+
+ mcu_uart1: serial@4a10000 {
+ compatible = "ti,am64-uart", "ti,am654-uart";
+ reg = <0x00 0x04a10000 0x00 0x100>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <48000000>;
+ current-speed = <115200>;
+ power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 160 0>;
+ clock-names = "fclk";
+ };
+
+ mcu_i2c0: i2c@4900000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x04900000 0x00 0x100>;
+ interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 106 2>;
+ clock-names = "fck";
+ };
+
+ mcu_i2c1: i2c@4910000 {
+ compatible = "ti,am64-i2c", "ti,omap4-i2c";
+ reg = <0x00 0x04910000 0x00 0x100>;
+ interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 107 2>;
+ clock-names = "fck";
+ };
+
+ mcu_spi0: spi@4b00000 {
+ compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
+ reg = <0x00 0x04b00000 0x00 0x400>;
+ interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 147 0>;
+ };
+
+ mcu_spi1: spi@4b10000 {
+ compatible = "ti,am654-mcspi","ti,omap4-mcspi";
+ reg = <0x00 0x04b10000 0x00 0x400>;
+ interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
+ clocks = <&k3_clks 148 0>;
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
new file mode 100644
index 000000000000..0ae8c844c482
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
@@ -0,0 +1,103 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM642 SoC Family
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/pinctrl/k3.h>
+#include <dt-bindings/soc/ti,sci_pm_domain.h>
+
+/ {
+ model = "Texas Instruments K3 AM642 SoC";
+ compatible = "ti,am642";
+ interrupt-parent = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &mcu_uart0;
+ serial1 = &mcu_uart1;
+ serial2 = &main_uart0;
+ serial3 = &main_uart1;
+ serial4 = &main_uart2;
+ serial5 = &main_uart3;
+ serial6 = &main_uart4;
+ serial7 = &main_uart5;
+ serial8 = &main_uart6;
+ };
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ cbass_main: bus@f4000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
+ <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
+ <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
+ <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
+ <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
+ <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
+ <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
+ <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
+ <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
+ <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
+ <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
+ <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
+ <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
+ <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
+ <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
+ <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
+ <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
+ <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
+ <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
+ <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
+ <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
+ <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
+ <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
+ <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
+
+ /* MCU Domain Range */
+ <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
+
+ cbass_mcu: bus@4000000 {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
+ };
+ };
+};
+
+/* Now include the peripherals for each bus segments */
+#include "k3-am64-main.dtsi"
+#include "k3-am64-mcu.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
new file mode 100644
index 000000000000..e2b397c88401
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM642 SoC family in Dual core configuration
+ *
+ * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am64.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a53";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a53";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+ };
+
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x40000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ };
+};
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-20 20:25 ` Dave Gerlach
@ 2021-01-20 22:04 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-20 22:04 UTC (permalink / raw)
To: Dave Gerlach, Sudeep Holla
Cc: linux-arm-kernel, devicetree, Rob Herring, Tony Lindgren,
Vignesh Raghavendra, Suman Anna, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 14:25-20210120, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
Hi Sudeep,
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
If this looks right to you, would be nice to have your reviewed-by :)
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-20 22:04 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-20 22:04 UTC (permalink / raw)
To: Dave Gerlach, Sudeep Holla
Cc: devicetree, Vignesh Raghavendra, Tony Lindgren, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 14:25-20210120, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
Hi Sudeep,
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
If this looks right to you, would be nice to have your reviewed-by :)
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-20 20:25 ` Dave Gerlach
@ 2021-01-21 17:25 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 17:25 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: linux-arm-kernel, devicetree, Rob Herring, Tony Lindgren,
Vignesh Raghavendra, Sekhar Nori, Kishon Vijay Abraham,
Lokesh Vutla, Aswath Govindraju
On 1/20/21 2:25 PM, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
>
> Some highlights of this SoC are:
> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> MCUs, and a single Cortex-M4F.
> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> * Integrated Ethernet switch supporting up to a total of two external
> ports.
> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> peripherals.
> * Centralized System Controller for Security, Power, and Resource
> Management (DMSC).
>
> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> for further details: https://www.ti.com/lit/pdf/spruim2
>
> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> under cbass_mcu.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Hmm, there are a few pieces contributed by me, so please do add
Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
> 4 files changed, 576 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> new file mode 100644
> index 000000000000..e3ef4bff04af
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_main {
> + oc_sram: sram@70000000 {
> + compatible = "mmio-sram";
> + reg = <0x00 0x70000000 0x00 0x200000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x70000000 0x200000>;
> +
> + atf-sram@0 {
> + reg = <0x0 0x1a000>;
> + };
> + };
> +
> + gic500: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: msi-controller@1820000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x00 0x01820000 0x00 0x10000>;
> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + dmss: dmss {
> + compatible = "simple-mfd";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-ranges;
> + ranges;
> +
> + secure_proxy_main: mailbox@4d000000 {
> + compatible = "ti,am654-secure-proxy";
> + #mbox-cells = <1>;
> + reg-names = "target_data", "rt", "scfg";
> + reg = <0x00 0x4d000000 0x00 0x80000>,
> + <0x00 0x4a600000 0x00 0x80000>,
> + <0x00 0x4a400000 0x00 0x80000>;
> + interrupt-names = "rx_012";
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> + dmsc: dmsc@44043000 {
> + compatible = "ti,k2g-sci";
> + ti,host-id = <12>;
> + mbox-names = "rx", "tx";
> + mboxes= <&secure_proxy_main 12>,
> + <&secure_proxy_main 13>;
> + reg-names = "debug_messages";
> + reg = <0x00 0x44043000 0x00 0xfe0>;
> +
> + k3_pds: power-controller {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <2>;
> + };
> +
> + k3_clks: clocks {
> + compatible = "ti,k2g-sci-clk";
> + #clock-cells = <2>;
> + };
> +
> + k3_reset: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> + };
> +
> + main_pmx0: pinctrl@f4000 {
> + compatible = "pinctrl-single";
> + reg = <0x00 0xf4000 0x00 0x2d0>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xffffffff>;
> + };
> +
> + main_conf: syscon@43000000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x00 0x43000000 0x00 0x20000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00 0x00 0x43000000 0x20000>;
> +
> + chipid@14 {
> + compatible = "ti,am654-chipid";
> + reg = <0x00000014 0x4>;
> + };
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02800000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 146 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02810000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 152 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02820000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 153 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart3: serial@2830000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02830000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 154 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart4: serial@2840000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02840000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 155 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart5: serial@2850000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02850000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 156 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart6: serial@2860000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02860000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 158 0>;
> + clock-names = "fclk";
> + };
> +
> + main_i2c0: i2c@20000000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20000000 0x00 0x100>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 102 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c1: i2c@20010000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20010000 0x00 0x100>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 103 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c2: i2c@20020000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20020000 0x00 0x100>;
> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 104 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c3: i2c@20030000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20030000 0x00 0x100>;
> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 105 2>;
> + clock-names = "fck";
> + };
> +
> + main_spi0: spi@20100000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x20100000 0x00 0x400>;
> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 141 0>;
> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
> + dma-names = "tx0", "rx0";
> + };
> +
> + main_spi1: spi@20110000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20110000 0x00 0x400>;
> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 142 0>;
> + };
> +
> + main_spi2: spi@20120000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20120000 0x00 0x400>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 143 0>;
> + };
> +
> + main_spi3: spi@20130000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20130000 0x00 0x400>;
> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 144 0>;
> + };
> +
> + main_spi4: spi@20140000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20140000 0x00 0x400>;
> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 145 0>;
> + };
> +
> + sdhci0: mmc@fa10000 {
> + compatible = "ti,am64-sdhci-8bit";
Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
ti-k3-dts-next. So, boot of these patches using this baseline fails when using
MMC rootfs, but is ok when using initramfs. This particular compatible and the
corresponding driver change are only in linux-next coming through couple of
patches from the MMC subsystem.
I am not sure why we would be including stuff that's dependent on some other
patches being merged from a different sub-system? Strangely, this ought to be
caught by dtbs_check, but it is not throwing any errors.
IMHO, these should only be added if you have no other external dependencies
especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
would not go through arm-soc either.
regards
Suman
> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-ddr52 = <0x6>;
> + ti,otap-del-sel-hs200 = <0x7>;
> + ti,otap-del-sel-hs400 = <0x4>;
> + };
> +
> + sdhci1: mmc@fa00000 {
> + compatible = "ti,am64-sdhci-4bit";
> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
> + clock-names = "clk_ahb", "clk_xin";
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-sd-hs = <0xf>;
> + ti,otap-del-sel-sdr12 = <0xf>;
> + ti,otap-del-sel-sdr25 = <0xf>;
> + ti,otap-del-sel-sdr50 = <0xc>;
> + ti,otap-del-sel-sdr104 = <0x6>;
> + ti,otap-del-sel-ddr50 = <0x9>;
> + ti,clkbuf-sel = <0x7>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> new file mode 100644
> index 000000000000..1d2be485a669
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_mcu {
> + mcu_uart0: serial@4a00000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a00000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 149 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_uart1: serial@4a10000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a10000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 160 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_i2c0: i2c@4900000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04900000 0x00 0x100>;
> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 106 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_i2c1: i2c@4910000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04910000 0x00 0x100>;
> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 107 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_spi0: spi@4b00000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x04b00000 0x00 0x400>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 147 0>;
> + };
> +
> + mcu_spi1: spi@4b10000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x04b10000 0x00 0x400>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 148 0>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> new file mode 100644
> index 000000000000..0ae8c844c482
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM642 SoC";
> + compatible = "ti,am642";
> + interrupt-parent = <&gic500>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &mcu_uart0;
> + serial1 = &mcu_uart1;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + serial5 = &main_uart3;
> + serial6 = &main_uart4;
> + serial7 = &main_uart5;
> + serial8 = &main_uart6;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + cbass_main: bus@f4000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> +
> + /* MCU Domain Range */
> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
> +
> + cbass_mcu: bus@4000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
> + };
> + };
> +};
> +
> +/* Now include the peripherals for each bus segments */
> +#include "k3-am64-main.dtsi"
> +#include "k3-am64-mcu.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> new file mode 100644
> index 000000000000..e2b397c88401
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC family in Dual core configuration
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am64.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> + };
> +
> + L2_0: l2-cache0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x40000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + };
> +};
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 17:25 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 17:25 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Tony Lindgren, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 1/20/21 2:25 PM, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
>
> Some highlights of this SoC are:
> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> MCUs, and a single Cortex-M4F.
> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> * Integrated Ethernet switch supporting up to a total of two external
> ports.
> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> peripherals.
> * Centralized System Controller for Security, Power, and Resource
> Management (DMSC).
>
> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> for further details: https://www.ti.com/lit/pdf/spruim2
>
> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> under cbass_mcu.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Hmm, there are a few pieces contributed by me, so please do add
Signed-off-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
> 4 files changed, 576 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> new file mode 100644
> index 000000000000..e3ef4bff04af
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_main {
> + oc_sram: sram@70000000 {
> + compatible = "mmio-sram";
> + reg = <0x00 0x70000000 0x00 0x200000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x70000000 0x200000>;
> +
> + atf-sram@0 {
> + reg = <0x0 0x1a000>;
> + };
> + };
> +
> + gic500: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: msi-controller@1820000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x00 0x01820000 0x00 0x10000>;
> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + dmss: dmss {
> + compatible = "simple-mfd";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-ranges;
> + ranges;
> +
> + secure_proxy_main: mailbox@4d000000 {
> + compatible = "ti,am654-secure-proxy";
> + #mbox-cells = <1>;
> + reg-names = "target_data", "rt", "scfg";
> + reg = <0x00 0x4d000000 0x00 0x80000>,
> + <0x00 0x4a600000 0x00 0x80000>,
> + <0x00 0x4a400000 0x00 0x80000>;
> + interrupt-names = "rx_012";
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> + dmsc: dmsc@44043000 {
> + compatible = "ti,k2g-sci";
> + ti,host-id = <12>;
> + mbox-names = "rx", "tx";
> + mboxes= <&secure_proxy_main 12>,
> + <&secure_proxy_main 13>;
> + reg-names = "debug_messages";
> + reg = <0x00 0x44043000 0x00 0xfe0>;
> +
> + k3_pds: power-controller {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <2>;
> + };
> +
> + k3_clks: clocks {
> + compatible = "ti,k2g-sci-clk";
> + #clock-cells = <2>;
> + };
> +
> + k3_reset: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> + };
> +
> + main_pmx0: pinctrl@f4000 {
> + compatible = "pinctrl-single";
> + reg = <0x00 0xf4000 0x00 0x2d0>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xffffffff>;
> + };
> +
> + main_conf: syscon@43000000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x00 0x43000000 0x00 0x20000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00 0x00 0x43000000 0x20000>;
> +
> + chipid@14 {
> + compatible = "ti,am654-chipid";
> + reg = <0x00000014 0x4>;
> + };
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02800000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 146 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02810000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 152 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02820000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 153 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart3: serial@2830000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02830000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 154 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart4: serial@2840000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02840000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 155 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart5: serial@2850000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02850000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 156 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart6: serial@2860000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02860000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 158 0>;
> + clock-names = "fclk";
> + };
> +
> + main_i2c0: i2c@20000000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20000000 0x00 0x100>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 102 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c1: i2c@20010000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20010000 0x00 0x100>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 103 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c2: i2c@20020000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20020000 0x00 0x100>;
> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 104 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c3: i2c@20030000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20030000 0x00 0x100>;
> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 105 2>;
> + clock-names = "fck";
> + };
> +
> + main_spi0: spi@20100000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x20100000 0x00 0x400>;
> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 141 0>;
> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
> + dma-names = "tx0", "rx0";
> + };
> +
> + main_spi1: spi@20110000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20110000 0x00 0x400>;
> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 142 0>;
> + };
> +
> + main_spi2: spi@20120000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20120000 0x00 0x400>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 143 0>;
> + };
> +
> + main_spi3: spi@20130000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20130000 0x00 0x400>;
> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 144 0>;
> + };
> +
> + main_spi4: spi@20140000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20140000 0x00 0x400>;
> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 145 0>;
> + };
> +
> + sdhci0: mmc@fa10000 {
> + compatible = "ti,am64-sdhci-8bit";
Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
ti-k3-dts-next. So, boot of these patches using this baseline fails when using
MMC rootfs, but is ok when using initramfs. This particular compatible and the
corresponding driver change are only in linux-next coming through couple of
patches from the MMC subsystem.
I am not sure why we would be including stuff that's dependent on some other
patches being merged from a different sub-system? Strangely, this ought to be
caught by dtbs_check, but it is not throwing any errors.
IMHO, these should only be added if you have no other external dependencies
especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
would not go through arm-soc either.
regards
Suman
> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-ddr52 = <0x6>;
> + ti,otap-del-sel-hs200 = <0x7>;
> + ti,otap-del-sel-hs400 = <0x4>;
> + };
> +
> + sdhci1: mmc@fa00000 {
> + compatible = "ti,am64-sdhci-4bit";
> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
> + clock-names = "clk_ahb", "clk_xin";
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-sd-hs = <0xf>;
> + ti,otap-del-sel-sdr12 = <0xf>;
> + ti,otap-del-sel-sdr25 = <0xf>;
> + ti,otap-del-sel-sdr50 = <0xc>;
> + ti,otap-del-sel-sdr104 = <0x6>;
> + ti,otap-del-sel-ddr50 = <0x9>;
> + ti,clkbuf-sel = <0x7>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> new file mode 100644
> index 000000000000..1d2be485a669
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_mcu {
> + mcu_uart0: serial@4a00000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a00000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 149 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_uart1: serial@4a10000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a10000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 160 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_i2c0: i2c@4900000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04900000 0x00 0x100>;
> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 106 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_i2c1: i2c@4910000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04910000 0x00 0x100>;
> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 107 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_spi0: spi@4b00000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x04b00000 0x00 0x400>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 147 0>;
> + };
> +
> + mcu_spi1: spi@4b10000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x04b10000 0x00 0x400>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 148 0>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> new file mode 100644
> index 000000000000..0ae8c844c482
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM642 SoC";
> + compatible = "ti,am642";
> + interrupt-parent = <&gic500>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &mcu_uart0;
> + serial1 = &mcu_uart1;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + serial5 = &main_uart3;
> + serial6 = &main_uart4;
> + serial7 = &main_uart5;
> + serial8 = &main_uart6;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + cbass_main: bus@f4000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> +
> + /* MCU Domain Range */
> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
> +
> + cbass_mcu: bus@4000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
> + };
> + };
> +};
> +
> +/* Now include the peripherals for each bus segments */
> +#include "k3-am64-main.dtsi"
> +#include "k3-am64-mcu.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> new file mode 100644
> index 000000000000..e2b397c88401
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC family in Dual core configuration
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am64.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> + };
> +
> + L2_0: l2-cache0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x40000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + };
> +};
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 17:25 ` Suman Anna
@ 2021-01-21 17:46 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 17:46 UTC (permalink / raw)
To: Suman Anna
Cc: Dave Gerlach, linux-arm-kernel, devicetree, Rob Herring,
Tony Lindgren, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 11:25-20210121, Suman Anna wrote:
> On 1/20/21 2:25 PM, Dave Gerlach wrote:
> > The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> > providing advanced system integration to enable applications such as
> > Motor Drives, PLC, Remote IO and IoT Gateways.
> >
> > Some highlights of this SoC are:
> > * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> > MCUs, and a single Cortex-M4F.
> > * Two Gigabit Industrial Communication Subsystems (ICSSG).
> > * Integrated Ethernet switch supporting up to a total of two external
> > ports.
> > * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> > controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> > peripherals.
> > * Centralized System Controller for Security, Power, and Resource
> > Management (DMSC).
> >
> > See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> > for further details: https://www.ti.com/lit/pdf/spruim2
> >
> > Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> > boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> > under cbass_main and the i2c, spi, and uart MCU domain periperhals
> > under cbass_mcu.
> >
> > Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>
> Hmm, there are a few pieces contributed by me, so please do add
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Sure, thanks..
[...]
> > +
> > + sdhci0: mmc@fa10000 {
> > + compatible = "ti,am64-sdhci-8bit";
>
> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
> MMC rootfs, but is ok when using initramfs. This particular compatible and the
> corresponding driver change are only in linux-next coming through couple of
> patches from the MMC subsystem.
>
> I am not sure why we would be including stuff that's dependent on some other
> patches being merged from a different sub-system? Strangely, this ought to be
> caught by dtbs_check, but it is not throwing any errors.
>
> IMHO, these should only be added if you have no other external dependencies
> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
> would not go through arm-soc either.
>
Yes, I am aware of this - this is no different from integration we have
done in the past as well.. intent is to get bindings in via subsystem
trees and dts changes via arm-soc. I always insist that basic ramdisk
boot always in the basic introduction tree. mmc, nfs are add-ons that
get added via subsystem tree and I host the dts changes - in this case
every dts node binding is fine with subsystems already queued in
linux-next. And this is no different from what I have noticed on other
ARM SoC maintainer trees as well.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 17:46 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 17:46 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Vignesh Raghavendra, Dave Gerlach, Tony Lindgren,
Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 11:25-20210121, Suman Anna wrote:
> On 1/20/21 2:25 PM, Dave Gerlach wrote:
> > The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> > providing advanced system integration to enable applications such as
> > Motor Drives, PLC, Remote IO and IoT Gateways.
> >
> > Some highlights of this SoC are:
> > * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> > MCUs, and a single Cortex-M4F.
> > * Two Gigabit Industrial Communication Subsystems (ICSSG).
> > * Integrated Ethernet switch supporting up to a total of two external
> > ports.
> > * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> > controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> > peripherals.
> > * Centralized System Controller for Security, Power, and Resource
> > Management (DMSC).
> >
> > See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> > for further details: https://www.ti.com/lit/pdf/spruim2
> >
> > Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> > boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> > under cbass_main and the i2c, spi, and uart MCU domain periperhals
> > under cbass_mcu.
> >
> > Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> > Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>
> Hmm, there are a few pieces contributed by me, so please do add
>
> Signed-off-by: Suman Anna <s-anna@ti.com>
Sure, thanks..
[...]
> > +
> > + sdhci0: mmc@fa10000 {
> > + compatible = "ti,am64-sdhci-8bit";
>
> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
> MMC rootfs, but is ok when using initramfs. This particular compatible and the
> corresponding driver change are only in linux-next coming through couple of
> patches from the MMC subsystem.
>
> I am not sure why we would be including stuff that's dependent on some other
> patches being merged from a different sub-system? Strangely, this ought to be
> caught by dtbs_check, but it is not throwing any errors.
>
> IMHO, these should only be added if you have no other external dependencies
> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
> would not go through arm-soc either.
>
Yes, I am aware of this - this is no different from integration we have
done in the past as well.. intent is to get bindings in via subsystem
trees and dts changes via arm-soc. I always insist that basic ramdisk
boot always in the basic introduction tree. mmc, nfs are add-ons that
get added via subsystem tree and I host the dts changes - in this case
every dts node binding is fine with subsystems already queued in
linux-next. And this is no different from what I have noticed on other
ARM SoC maintainer trees as well.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 17:46 ` Nishanth Menon
@ 2021-01-21 18:13 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 18:13 UTC (permalink / raw)
To: Nishanth Menon
Cc: Dave Gerlach, linux-arm-kernel, devicetree, Rob Herring,
Tony Lindgren, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 1/21/21 11:46 AM, Nishanth Menon wrote:
> On 11:25-20210121, Suman Anna wrote:
>> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>> providing advanced system integration to enable applications such as
>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>
>>> Some highlights of this SoC are:
>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>> MCUs, and a single Cortex-M4F.
>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>> * Integrated Ethernet switch supporting up to a total of two external
>>> ports.
>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>> peripherals.
>>> * Centralized System Controller for Security, Power, and Resource
>>> Management (DMSC).
>>>
>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>
>>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>>> under cbass_mcu.
>>>
>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>>
>> Hmm, there are a few pieces contributed by me, so please do add
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>
> Sure, thanks..
>
> [...]
>
>>> +
>>> + sdhci0: mmc@fa10000 {
>>> + compatible = "ti,am64-sdhci-8bit";
>>
>> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
>> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
>> MMC rootfs, but is ok when using initramfs. This particular compatible and the
>> corresponding driver change are only in linux-next coming through couple of
>> patches from the MMC subsystem.
>>
>> I am not sure why we would be including stuff that's dependent on some other
>> patches being merged from a different sub-system? Strangely, this ought to be
>> caught by dtbs_check, but it is not throwing any errors.
>>
>> IMHO, these should only be added if you have no other external dependencies
>> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
>> would not go through arm-soc either.
>>
>
> Yes, I am aware of this - this is no different from integration we have
> done in the past as well.. intent is to get bindings in via subsystem
> trees and dts changes via arm-soc. I always insist that basic ramdisk
> boot always in the basic introduction tree. mmc, nfs are add-ons that
> get added via subsystem tree and I host the dts changes - in this case
> every dts node binding is fine with subsystems already queued in
> linux-next. And this is no different from what I have noticed on other
> ARM SoC maintainer trees as well.
>
Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
required driver functionality to have been in (or atleast the binding as per
documentation), and not having to need to pick additional patches.
If the intent is to verify/test everything against linux-next and not the
baseline tree, then I guess this works. But in general, this kinda goes against
the rules set in submitting patches. For example, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
And sure enough, this is what I get when I run checkpatch against your tree.
WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
check ./Documentation/devicetree/bindings/
#347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
+ compatible = "ti,am64-sdhci-8bit";
WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
check ./Documentation/devicetree/bindings/
#365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
+ compatible = "ti,am64-sdhci-4bit";
regards
Suman
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 18:13 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 18:13 UTC (permalink / raw)
To: Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Dave Gerlach, Tony Lindgren,
Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 1/21/21 11:46 AM, Nishanth Menon wrote:
> On 11:25-20210121, Suman Anna wrote:
>> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>> providing advanced system integration to enable applications such as
>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>
>>> Some highlights of this SoC are:
>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>> MCUs, and a single Cortex-M4F.
>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>> * Integrated Ethernet switch supporting up to a total of two external
>>> ports.
>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>> peripherals.
>>> * Centralized System Controller for Security, Power, and Resource
>>> Management (DMSC).
>>>
>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>
>>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>>> under cbass_mcu.
>>>
>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>>
>> Hmm, there are a few pieces contributed by me, so please do add
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>
> Sure, thanks..
>
> [...]
>
>>> +
>>> + sdhci0: mmc@fa10000 {
>>> + compatible = "ti,am64-sdhci-8bit";
>>
>> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
>> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
>> MMC rootfs, but is ok when using initramfs. This particular compatible and the
>> corresponding driver change are only in linux-next coming through couple of
>> patches from the MMC subsystem.
>>
>> I am not sure why we would be including stuff that's dependent on some other
>> patches being merged from a different sub-system? Strangely, this ought to be
>> caught by dtbs_check, but it is not throwing any errors.
>>
>> IMHO, these should only be added if you have no other external dependencies
>> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
>> would not go through arm-soc either.
>>
>
> Yes, I am aware of this - this is no different from integration we have
> done in the past as well.. intent is to get bindings in via subsystem
> trees and dts changes via arm-soc. I always insist that basic ramdisk
> boot always in the basic introduction tree. mmc, nfs are add-ons that
> get added via subsystem tree and I host the dts changes - in this case
> every dts node binding is fine with subsystems already queued in
> linux-next. And this is no different from what I have noticed on other
> ARM SoC maintainer trees as well.
>
Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
required driver functionality to have been in (or atleast the binding as per
documentation), and not having to need to pick additional patches.
If the intent is to verify/test everything against linux-next and not the
baseline tree, then I guess this works. But in general, this kinda goes against
the rules set in submitting patches. For example, see
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
And sure enough, this is what I get when I run checkpatch against your tree.
WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
check ./Documentation/devicetree/bindings/
#347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
+ compatible = "ti,am64-sdhci-8bit";
WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
check ./Documentation/devicetree/bindings/
#365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
+ compatible = "ti,am64-sdhci-4bit";
regards
Suman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 18:13 ` Suman Anna
@ 2021-01-21 18:39 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 18:39 UTC (permalink / raw)
To: Suman Anna
Cc: Dave Gerlach, linux-arm-kernel, devicetree, Rob Herring,
Tony Lindgren, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 12:13-20210121, Suman Anna wrote:
> On 1/21/21 11:46 AM, Nishanth Menon wrote:
> > On 11:25-20210121, Suman Anna wrote:
> >> On 1/20/21 2:25 PM, Dave Gerlach wrote:
> >>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> >>> providing advanced system integration to enable applications such as
> >>> Motor Drives, PLC, Remote IO and IoT Gateways.
> >>>
> >>> Some highlights of this SoC are:
> >>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> >>> MCUs, and a single Cortex-M4F.
> >>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> >>> * Integrated Ethernet switch supporting up to a total of two external
> >>> ports.
> >>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> >>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> >>> peripherals.
> >>> * Centralized System Controller for Security, Power, and Resource
> >>> Management (DMSC).
> >>>
> >>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> >>> for further details: https://www.ti.com/lit/pdf/spruim2
> >>>
> >>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> >>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> >>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> >>> under cbass_mcu.
> >>>
> >>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> >>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
> >>
> >> Hmm, there are a few pieces contributed by me, so please do add
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >
> > Sure, thanks..
> >
> > [...]
> >
> >>> +
> >>> + sdhci0: mmc@fa10000 {
> >>> + compatible = "ti,am64-sdhci-8bit";
> >>
> >> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
> >> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
> >> MMC rootfs, but is ok when using initramfs. This particular compatible and the
> >> corresponding driver change are only in linux-next coming through couple of
> >> patches from the MMC subsystem.
> >>
> >> I am not sure why we would be including stuff that's dependent on some other
> >> patches being merged from a different sub-system? Strangely, this ought to be
> >> caught by dtbs_check, but it is not throwing any errors.
> >>
> >> IMHO, these should only be added if you have no other external dependencies
> >> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
> >> would not go through arm-soc either.
> >>
> >
> > Yes, I am aware of this - this is no different from integration we have
> > done in the past as well.. intent is to get bindings in via subsystem
> > trees and dts changes via arm-soc. I always insist that basic ramdisk
> > boot always in the basic introduction tree. mmc, nfs are add-ons that
> > get added via subsystem tree and I host the dts changes - in this case
> > every dts node binding is fine with subsystems already queued in
> > linux-next. And this is no different from what I have noticed on other
> > ARM SoC maintainer trees as well.
> >
>
> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
What is counter intutive about a -next branch be tested against
linux-next tree?
> required driver functionality to have been in (or atleast the binding as per
> documentation), and not having to need to pick additional patches.
>
> If the intent is to verify/test everything against linux-next and not the
> baseline tree, then I guess this works. But in general, this kinda goes against
> the rules set in submitting patches. For example, see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
>
> And sure enough, this is what I get when I run checkpatch against your tree.
Also read https://www.kernel.org/doc/html/v5.11-rc4/process/2.Process.html#next-trees
You should probably realize linux-next is an integral part of the
process for us now.
>
> WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
> check ./Documentation/devicetree/bindings/
> #347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
> + compatible = "ti,am64-sdhci-8bit";
>
> WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
> check ./Documentation/devicetree/bindings/
> #365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
> + compatible = "ti,am64-sdhci-4bit";
you are saying basically - wait a complete kernel cycle after a driver
is introduced before we can even test a driver SoC support introduced
without an user in the same kernel version.. which is a disaster and bit-rot
OR
Let the subsystem maintainers also carry the patches for dts - which is
going to be another disaster and creates all kind of avoidable merge
conflicts.
OR
I stage a rc1 and rc2 merge cycle - which makes no sense - these nodes
dont get activated without a compatible match, which gets enabled only
when the corresponding subsystem is merged - they dont break existing
functionality even when the subsystem is merged, it just increases
the functionality as it should. (not to mention that all my follow on
kernel merge trees will have to be rc2 based - since majority nodes
will be introduced there)
dts already has a pain point that we are trying to manage logically
here, this is not a MISRA-C ASIL-D process - follow and exact verbatim
word to word process, that is just plain ridiculous.
When rc1 comes together, which is what my next branch is for, things
should be cohesive - we dont introduce regressions and broken trees -
which is exactly what the -next process makes sure happens.
Now, if you want to launch a product with my -next branch - go ahead, I
don't intent it for current kernel version - you are on your own.
If there is a real risk of upstream next-breaking - speakup with an
real example - All I care about is keeping upstream functional and
useable.
I recheck the linux-next tree almost daily basis for consistency, and I
do appreciate the concern here (and passion) - point is, I think we
might be a bit of an over-reaction if we just look at the other options
in front of us - not to mention, maybe drop the entire idea of dt coming
in from ARM SoC - let the subsystem member create merge conflict and
duke it out.. I don't think any of us want to see that kind of mayhem.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 18:39 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 18:39 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Vignesh Raghavendra, Dave Gerlach, Tony Lindgren,
Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 12:13-20210121, Suman Anna wrote:
> On 1/21/21 11:46 AM, Nishanth Menon wrote:
> > On 11:25-20210121, Suman Anna wrote:
> >> On 1/20/21 2:25 PM, Dave Gerlach wrote:
> >>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> >>> providing advanced system integration to enable applications such as
> >>> Motor Drives, PLC, Remote IO and IoT Gateways.
> >>>
> >>> Some highlights of this SoC are:
> >>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> >>> MCUs, and a single Cortex-M4F.
> >>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> >>> * Integrated Ethernet switch supporting up to a total of two external
> >>> ports.
> >>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> >>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> >>> peripherals.
> >>> * Centralized System Controller for Security, Power, and Resource
> >>> Management (DMSC).
> >>>
> >>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> >>> for further details: https://www.ti.com/lit/pdf/spruim2
> >>>
> >>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> >>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> >>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> >>> under cbass_mcu.
> >>>
> >>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> >>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
> >>
> >> Hmm, there are a few pieces contributed by me, so please do add
> >>
> >> Signed-off-by: Suman Anna <s-anna@ti.com>
> >
> > Sure, thanks..
> >
> > [...]
> >
> >>> +
> >>> + sdhci0: mmc@fa10000 {
> >>> + compatible = "ti,am64-sdhci-8bit";
> >>
> >> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
> >> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
> >> MMC rootfs, but is ok when using initramfs. This particular compatible and the
> >> corresponding driver change are only in linux-next coming through couple of
> >> patches from the MMC subsystem.
> >>
> >> I am not sure why we would be including stuff that's dependent on some other
> >> patches being merged from a different sub-system? Strangely, this ought to be
> >> caught by dtbs_check, but it is not throwing any errors.
> >>
> >> IMHO, these should only be added if you have no other external dependencies
> >> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
> >> would not go through arm-soc either.
> >>
> >
> > Yes, I am aware of this - this is no different from integration we have
> > done in the past as well.. intent is to get bindings in via subsystem
> > trees and dts changes via arm-soc. I always insist that basic ramdisk
> > boot always in the basic introduction tree. mmc, nfs are add-ons that
> > get added via subsystem tree and I host the dts changes - in this case
> > every dts node binding is fine with subsystems already queued in
> > linux-next. And this is no different from what I have noticed on other
> > ARM SoC maintainer trees as well.
> >
>
> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
What is counter intutive about a -next branch be tested against
linux-next tree?
> required driver functionality to have been in (or atleast the binding as per
> documentation), and not having to need to pick additional patches.
>
> If the intent is to verify/test everything against linux-next and not the
> baseline tree, then I guess this works. But in general, this kinda goes against
> the rules set in submitting patches. For example, see
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
>
> And sure enough, this is what I get when I run checkpatch against your tree.
Also read https://www.kernel.org/doc/html/v5.11-rc4/process/2.Process.html#next-trees
You should probably realize linux-next is an integral part of the
process for us now.
>
> WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
> check ./Documentation/devicetree/bindings/
> #347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
> + compatible = "ti,am64-sdhci-8bit";
>
> WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
> check ./Documentation/devicetree/bindings/
> #365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
> + compatible = "ti,am64-sdhci-4bit";
you are saying basically - wait a complete kernel cycle after a driver
is introduced before we can even test a driver SoC support introduced
without an user in the same kernel version.. which is a disaster and bit-rot
OR
Let the subsystem maintainers also carry the patches for dts - which is
going to be another disaster and creates all kind of avoidable merge
conflicts.
OR
I stage a rc1 and rc2 merge cycle - which makes no sense - these nodes
dont get activated without a compatible match, which gets enabled only
when the corresponding subsystem is merged - they dont break existing
functionality even when the subsystem is merged, it just increases
the functionality as it should. (not to mention that all my follow on
kernel merge trees will have to be rc2 based - since majority nodes
will be introduced there)
dts already has a pain point that we are trying to manage logically
here, this is not a MISRA-C ASIL-D process - follow and exact verbatim
word to word process, that is just plain ridiculous.
When rc1 comes together, which is what my next branch is for, things
should be cohesive - we dont introduce regressions and broken trees -
which is exactly what the -next process makes sure happens.
Now, if you want to launch a product with my -next branch - go ahead, I
don't intent it for current kernel version - you are on your own.
If there is a real risk of upstream next-breaking - speakup with an
real example - All I care about is keeping upstream functional and
useable.
I recheck the linux-next tree almost daily basis for consistency, and I
do appreciate the concern here (and passion) - point is, I think we
might be a bit of an over-reaction if we just look at the other options
in front of us - not to mention, maybe drop the entire idea of dt coming
in from ARM SoC - let the subsystem member create merge conflict and
duke it out.. I don't think any of us want to see that kind of mayhem.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 18:39 ` Nishanth Menon
@ 2021-01-21 19:57 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 19:57 UTC (permalink / raw)
To: Nishanth Menon, Arnd Bergmann, Tony Lindgren
Cc: Dave Gerlach, linux-arm-kernel, devicetree, Rob Herring,
Tony Lindgren, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
+ Arnd and Tony
On 1/21/21 12:39 PM, Nishanth Menon wrote:
> On 12:13-20210121, Suman Anna wrote:
>> On 1/21/21 11:46 AM, Nishanth Menon wrote:
>>> On 11:25-20210121, Suman Anna wrote:
>>>> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>>>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>>>> providing advanced system integration to enable applications such as
>>>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>>>
>>>>> Some highlights of this SoC are:
>>>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>>>> MCUs, and a single Cortex-M4F.
>>>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>>>> * Integrated Ethernet switch supporting up to a total of two external
>>>>> ports.
>>>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>>>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>>>> peripherals.
>>>>> * Centralized System Controller for Security, Power, and Resource
>>>>> Management (DMSC).
>>>>>
>>>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>>>
>>>>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>>>>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>>>>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>>>>> under cbass_mcu.
>>>>>
>>>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>>>>
>>>> Hmm, there are a few pieces contributed by me, so please do add
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>
>>> Sure, thanks..
>>>
>>> [...]
>>>
>>>>> +
>>>>> + sdhci0: mmc@fa10000 {
>>>>> + compatible = "ti,am64-sdhci-8bit";
>>>>
>>>> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
>>>> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
>>>> MMC rootfs, but is ok when using initramfs. This particular compatible and the
>>>> corresponding driver change are only in linux-next coming through couple of
>>>> patches from the MMC subsystem.
>>>>
>>>> I am not sure why we would be including stuff that's dependent on some other
>>>> patches being merged from a different sub-system? Strangely, this ought to be
>>>> caught by dtbs_check, but it is not throwing any errors.
>>>>
>>>> IMHO, these should only be added if you have no other external dependencies
>>>> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
>>>> would not go through arm-soc either.
>>>>
>>>
>>> Yes, I am aware of this - this is no different from integration we have
>>> done in the past as well.. intent is to get bindings in via subsystem
>>> trees and dts changes via arm-soc. I always insist that basic ramdisk
>>> boot always in the basic introduction tree. mmc, nfs are add-ons that
>>> get added via subsystem tree and I host the dts changes - in this case
>>> every dts node binding is fine with subsystems already queued in
>>> linux-next. And this is no different from what I have noticed on other
>>> ARM SoC maintainer trees as well.
>>>
>>
>> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
>
> What is counter intutive about a -next branch be tested against
> linux-next tree?
The -next process is well understood. FWIW, you are not sending your PR against
-next branch, but against primarily a -rc1 or -rc2 baseline.
As a developer, when I am submitting patches, I am making sure that things are
functional against the baseline you use. For example, when I split functionality
into a driver portions and dts portions, I need to make sure both those
individual pieces boot fine and do not cause regressions, even though for the
final functionality, you need both.
>
>> required driver functionality to have been in (or atleast the binding as per
>> documentation), and not having to need to pick additional patches.
>>
>> If the intent is to verify/test everything against linux-next and not the
>> baseline tree, then I guess this works. But in general, this kinda goes against
>> the rules set in submitting patches. For example, see
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
>>
>> And sure enough, this is what I get when I run checkpatch against your tree.
>
> Also read https://www.kernel.org/doc/html/v5.11-rc4/process/2.Process.html#next-trees
>
> You should probably realize linux-next is an integral part of the
> process for us now.
>
>>
>> WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
>> check ./Documentation/devicetree/bindings/
>> #347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
>> + compatible = "ti,am64-sdhci-8bit";
>>
>> WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
>> check ./Documentation/devicetree/bindings/
>> #365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
>> + compatible = "ti,am64-sdhci-4bit";
>
>
> you are saying basically - wait a complete kernel cycle after a driver
> is introduced before we can even test a driver SoC support introduced
> without an user in the same kernel version.. which is a disaster and bit-rot
>
> OR
>
> Let the subsystem maintainers also carry the patches for dts - which is
> going to be another disaster and creates all kind of avoidable merge
> conflicts.
>
> OR
>
> I stage a rc1 and rc2 merge cycle - which makes no sense - these nodes
> dont get activated without a compatible match, which gets enabled only
> when the corresponding subsystem is merged - they dont break existing
> functionality even when the subsystem is merged, it just increases
> the functionality as it should. (not to mention that all my follow on
> kernel merge trees will have to be rc2 based - since majority nodes
> will be introduced there)
>
> dts already has a pain point that we are trying to manage logically
> here, this is not a MISRA-C ASIL-D process - follow and exact verbatim
> word to word process, that is just plain ridiculous.
>
> When rc1 comes together, which is what my next branch is for, things
> should be cohesive - we dont introduce regressions and broken trees -
> which is exactly what the -next process makes sure happens.
>
>
> Now, if you want to launch a product with my -next branch - go ahead, I
> don't intent it for current kernel version - you are on your own.
>
> If there is a real risk of upstream next-breaking - speakup with an
> real example - All I care about is keeping upstream functional and
> useable.
This is all moot when your own tree doesn't boot properly. In this case, you are
adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
nodes that were added or you need additional driver patches (which is not how
maintainer-level trees are verified).
Arnd,
Can you please guide us here as to what is expected in general, given that the
pull-request from Nishanth goes through you, and if there is some pre-existing
norms around this?
Tony,
Appreciate your input as well since you probably have dealt with these kinda of
dependencies on OMAP.
regards
Suman
>
> I recheck the linux-next tree almost daily basis for consistency, and I
> do appreciate the concern here (and passion) - point is, I think we
> might be a bit of an over-reaction if we just look at the other options
> in front of us - not to mention, maybe drop the entire idea of dt coming
> in from ARM SoC - let the subsystem member create merge conflict and
> duke it out.. I don't think any of us want to see that kind of mayhem.
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 19:57 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 19:57 UTC (permalink / raw)
To: Nishanth Menon, Arnd Bergmann, Tony Lindgren
Cc: devicetree, Vignesh Raghavendra, Dave Gerlach, Tony Lindgren,
Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
+ Arnd and Tony
On 1/21/21 12:39 PM, Nishanth Menon wrote:
> On 12:13-20210121, Suman Anna wrote:
>> On 1/21/21 11:46 AM, Nishanth Menon wrote:
>>> On 11:25-20210121, Suman Anna wrote:
>>>> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>>>>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>>>>> providing advanced system integration to enable applications such as
>>>>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>>>>
>>>>> Some highlights of this SoC are:
>>>>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>>>>> MCUs, and a single Cortex-M4F.
>>>>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>>>>> * Integrated Ethernet switch supporting up to a total of two external
>>>>> ports.
>>>>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>>>>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>>>>> peripherals.
>>>>> * Centralized System Controller for Security, Power, and Resource
>>>>> Management (DMSC).
>>>>>
>>>>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>>>>> for further details: https://www.ti.com/lit/pdf/spruim2
>>>>>
>>>>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>>>>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>>>>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>>>>> under cbass_mcu.
>>>>>
>>>>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>>>>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>>>>
>>>> Hmm, there are a few pieces contributed by me, so please do add
>>>>
>>>> Signed-off-by: Suman Anna <s-anna@ti.com>
>>>
>>> Sure, thanks..
>>>
>>> [...]
>>>
>>>>> +
>>>>> + sdhci0: mmc@fa10000 {
>>>>> + compatible = "ti,am64-sdhci-8bit";
>>>>
>>>> Hmm, I tried booting this series on top of 5.11-rc1 + Nishanth's current
>>>> ti-k3-dts-next. So, boot of these patches using this baseline fails when using
>>>> MMC rootfs, but is ok when using initramfs. This particular compatible and the
>>>> corresponding driver change are only in linux-next coming through couple of
>>>> patches from the MMC subsystem.
>>>>
>>>> I am not sure why we would be including stuff that's dependent on some other
>>>> patches being merged from a different sub-system? Strangely, this ought to be
>>>> caught by dtbs_check, but it is not throwing any errors.
>>>>
>>>> IMHO, these should only be added if you have no other external dependencies
>>>> especially when you are applying on a 5.11-rc baseline. The MMC pull-requests
>>>> would not go through arm-soc either.
>>>>
>>>
>>> Yes, I am aware of this - this is no different from integration we have
>>> done in the past as well.. intent is to get bindings in via subsystem
>>> trees and dts changes via arm-soc. I always insist that basic ramdisk
>>> boot always in the basic introduction tree. mmc, nfs are add-ons that
>>> get added via subsystem tree and I host the dts changes - in this case
>>> every dts node binding is fine with subsystems already queued in
>>> linux-next. And this is no different from what I have noticed on other
>>> ARM SoC maintainer trees as well.
>>>
>>
>> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
>
> What is counter intutive about a -next branch be tested against
> linux-next tree?
The -next process is well understood. FWIW, you are not sending your PR against
-next branch, but against primarily a -rc1 or -rc2 baseline.
As a developer, when I am submitting patches, I am making sure that things are
functional against the baseline you use. For example, when I split functionality
into a driver portions and dts portions, I need to make sure both those
individual pieces boot fine and do not cause regressions, even though for the
final functionality, you need both.
>
>> required driver functionality to have been in (or atleast the binding as per
>> documentation), and not having to need to pick additional patches.
>>
>> If the intent is to verify/test everything against linux-next and not the
>> baseline tree, then I guess this works. But in general, this kinda goes against
>> the rules set in submitting patches. For example, see
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.rst#n44
>>
>> And sure enough, this is what I get when I run checkpatch against your tree.
>
> Also read https://www.kernel.org/doc/html/v5.11-rc4/process/2.Process.html#next-trees
>
> You should probably realize linux-next is an integral part of the
> process for us now.
>
>>
>> WARNING: DT compatible string "ti,am64-sdhci-8bit" appears un-documented --
>> check ./Documentation/devicetree/bindings/
>> #347: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:298:
>> + compatible = "ti,am64-sdhci-8bit";
>>
>> WARNING: DT compatible string "ti,am64-sdhci-4bit" appears un-documented --
>> check ./Documentation/devicetree/bindings/
>> #365: FILE: arch/arm64/boot/dts/ti/k3-am64-main.dtsi:316:
>> + compatible = "ti,am64-sdhci-4bit";
>
>
> you are saying basically - wait a complete kernel cycle after a driver
> is introduced before we can even test a driver SoC support introduced
> without an user in the same kernel version.. which is a disaster and bit-rot
>
> OR
>
> Let the subsystem maintainers also carry the patches for dts - which is
> going to be another disaster and creates all kind of avoidable merge
> conflicts.
>
> OR
>
> I stage a rc1 and rc2 merge cycle - which makes no sense - these nodes
> dont get activated without a compatible match, which gets enabled only
> when the corresponding subsystem is merged - they dont break existing
> functionality even when the subsystem is merged, it just increases
> the functionality as it should. (not to mention that all my follow on
> kernel merge trees will have to be rc2 based - since majority nodes
> will be introduced there)
>
> dts already has a pain point that we are trying to manage logically
> here, this is not a MISRA-C ASIL-D process - follow and exact verbatim
> word to word process, that is just plain ridiculous.
>
> When rc1 comes together, which is what my next branch is for, things
> should be cohesive - we dont introduce regressions and broken trees -
> which is exactly what the -next process makes sure happens.
>
>
> Now, if you want to launch a product with my -next branch - go ahead, I
> don't intent it for current kernel version - you are on your own.
>
> If there is a real risk of upstream next-breaking - speakup with an
> real example - All I care about is keeping upstream functional and
> useable.
This is all moot when your own tree doesn't boot properly. In this case, you are
adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
nodes that were added or you need additional driver patches (which is not how
maintainer-level trees are verified).
Arnd,
Can you please guide us here as to what is expected in general, given that the
pull-request from Nishanth goes through you, and if there is some pre-existing
norms around this?
Tony,
Appreciate your input as well since you probably have dealt with these kinda of
dependencies on OMAP.
regards
Suman
>
> I recheck the linux-next tree almost daily basis for consistency, and I
> do appreciate the concern here (and passion) - point is, I think we
> might be a bit of an over-reaction if we just look at the other options
> in front of us - not to mention, maybe drop the entire idea of dt coming
> in from ARM SoC - let the subsystem member create merge conflict and
> duke it out.. I don't think any of us want to see that kind of mayhem.
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 19:57 ` Suman Anna
@ 2021-01-21 20:13 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 20:13 UTC (permalink / raw)
To: Suman Anna
Cc: Arnd Bergmann, Tony Lindgren, Dave Gerlach, linux-arm-kernel,
devicetree, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 13:57-20210121, Suman Anna wrote:
> This is all moot when your own tree doesn't boot properly. In this case, you are
> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> nodes that were added or you need additional driver patches (which is not how
> maintainer-level trees are verified).
Get your facts straight please.
What do you mean does'nt boot? It does boot with initramfs which is
the minimum qual i had set for any new platform (along with. - your
need is for a device node to work - which is both a combination of
defconfig + driver updates.
>
> Arnd,
> Can you please guide us here as to what is expected in general, given that the
> pull-request from Nishanth goes through you, and if there is some pre-existing
> norms around this?
>
> Tony,
> Appreciate your input as well since you probably have dealt with these kinda of
> dependencies on OMAP.
I am more than happy to drop this entire SoC off my queue (I am yet to
pick it up), which is probably what I will do.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 20:13 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 20:13 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Vignesh Raghavendra, Arnd Bergmann, Dave Gerlach,
Tony Lindgren, Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla,
Rob Herring, Aswath Govindraju, linux-arm-kernel
On 13:57-20210121, Suman Anna wrote:
> This is all moot when your own tree doesn't boot properly. In this case, you are
> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> nodes that were added or you need additional driver patches (which is not how
> maintainer-level trees are verified).
Get your facts straight please.
What do you mean does'nt boot? It does boot with initramfs which is
the minimum qual i had set for any new platform (along with. - your
need is for a device node to work - which is both a combination of
defconfig + driver updates.
>
> Arnd,
> Can you please guide us here as to what is expected in general, given that the
> pull-request from Nishanth goes through you, and if there is some pre-existing
> norms around this?
>
> Tony,
> Appreciate your input as well since you probably have dealt with these kinda of
> dependencies on OMAP.
I am more than happy to drop this entire SoC off my queue (I am yet to
pick it up), which is probably what I will do.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 20:13 ` Nishanth Menon
@ 2021-01-21 20:42 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 20:42 UTC (permalink / raw)
To: Nishanth Menon
Cc: Arnd Bergmann, Tony Lindgren, Dave Gerlach, linux-arm-kernel,
devicetree, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 1/21/21 2:13 PM, Nishanth Menon wrote:
> On 13:57-20210121, Suman Anna wrote:
>> This is all moot when your own tree doesn't boot properly. In this case, you are
>> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
>> nodes that were added or you need additional driver patches (which is not how
>> maintainer-level trees are verified).
>
> Get your facts straight please.
>
> What do you mean does'nt boot? It does boot with initramfs which is
> the minimum qual i had set for any new platform (along with. - your
> need is for a device node to work - which is both a combination of
> defconfig + driver updates.
And please re-read my first email, and what I started out with. I am not sure "I
will pick MMC nodes, but the entry criteria is only initramfs, and you need
additional patches to get MMC boot to work" is right. Normal thing to do is to
take in the next merge cycle.
>
>>
>> Arnd,
>> Can you please guide us here as to what is expected in general, given that the
>> pull-request from Nishanth goes through you, and if there is some pre-existing
>> norms around this?
>>
>> Tony,
>> Appreciate your input as well since you probably have dealt with these kinda of
>> dependencies on OMAP.
>
> I am more than happy to drop this entire SoC off my queue (I am yet to
> pick it up), which is probably what I will do.
>
You are the maintainer, do what feels right to you. You can as well wait for the
MMC driver changes to be in, and then pick up the series next merge window. Or
you can accept the versions without taking in pieces that have external
dependencies.
regards
Suman
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 20:42 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 20:42 UTC (permalink / raw)
To: Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Arnd Bergmann, Dave Gerlach,
Tony Lindgren, Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla,
Rob Herring, Aswath Govindraju, linux-arm-kernel
On 1/21/21 2:13 PM, Nishanth Menon wrote:
> On 13:57-20210121, Suman Anna wrote:
>> This is all moot when your own tree doesn't boot properly. In this case, you are
>> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
>> nodes that were added or you need additional driver patches (which is not how
>> maintainer-level trees are verified).
>
> Get your facts straight please.
>
> What do you mean does'nt boot? It does boot with initramfs which is
> the minimum qual i had set for any new platform (along with. - your
> need is for a device node to work - which is both a combination of
> defconfig + driver updates.
And please re-read my first email, and what I started out with. I am not sure "I
will pick MMC nodes, but the entry criteria is only initramfs, and you need
additional patches to get MMC boot to work" is right. Normal thing to do is to
take in the next merge cycle.
>
>>
>> Arnd,
>> Can you please guide us here as to what is expected in general, given that the
>> pull-request from Nishanth goes through you, and if there is some pre-existing
>> norms around this?
>>
>> Tony,
>> Appreciate your input as well since you probably have dealt with these kinda of
>> dependencies on OMAP.
>
> I am more than happy to drop this entire SoC off my queue (I am yet to
> pick it up), which is probably what I will do.
>
You are the maintainer, do what feels right to you. You can as well wait for the
MMC driver changes to be in, and then pick up the series next merge window. Or
you can accept the versions without taking in pieces that have external
dependencies.
regards
Suman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 20:42 ` Suman Anna
@ 2021-01-21 21:18 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 21:18 UTC (permalink / raw)
To: Suman Anna
Cc: Arnd Bergmann, Tony Lindgren, Dave Gerlach, linux-arm-kernel,
devicetree, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 14:42-20210121, Suman Anna wrote:
> On 1/21/21 2:13 PM, Nishanth Menon wrote:
> > On 13:57-20210121, Suman Anna wrote:
> >> This is all moot when your own tree doesn't boot properly. In this case, you are
> >> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> >> nodes that were added or you need additional driver patches (which is not how
> >> maintainer-level trees are verified).
> >
> > Get your facts straight please.
> >
> > What do you mean does'nt boot? It does boot with initramfs which is
> > the minimum qual i had set for any new platform (along with. - your
> > need is for a device node to work - which is both a combination of
> > defconfig + driver updates.
>
> And please re-read my first email, and what I started out with. I am not sure "I
> will pick MMC nodes, but the entry criteria is only initramfs, and you need
> additional patches to get MMC boot to work" is right. Normal thing to do is to
> take in the next merge cycle.
Sigh.
As I stated, the reason I prefer not to do that is because the drivers
will bit-rot for a kernel window without users. Why is it just MMC?
Start off with uart:
compatible = "ti,am64-uart", "ti,am654-uart";
That is not in v5.11-rc1 - it only works because driver is falling back
on the backward compatible nature of the device. The binding and driver
fixes are already on next.
MMC by itself wont boot unless the defconfig changes were merged in
upstream - and that was a painful choice to make to prevent the common Image
file from bloating too much..
I mean, is there a real concern that
https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/
or
https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/
or ....
will be dropped, in which case, we should'nt introduce in the next
kernel version, so that also means that those drivers will remain as is
without users for a complete kernel cycle.
I am not saying there are'nt instances where things have happened..
these changes have been in next for sufficiently long cycles for that
NOT to happen. Without users, they can unfortunately break and no one
will be the wiser till we enable the nodes again.. That would be a waste
of everyone's time.
> >>
> >> Arnd,
> >> Can you please guide us here as to what is expected in general, given that the
> >> pull-request from Nishanth goes through you, and if there is some pre-existing
> >> norms around this?
> >>
> >> Tony,
> >> Appreciate your input as well since you probably have dealt with these kinda of
> >> dependencies on OMAP.
> >
> > I am more than happy to drop this entire SoC off my queue (I am yet to
> > pick it up), which is probably what I will do.
> >
>
> You are the maintainer, do what feels right to you. You can as well wait for the
> MMC driver changes to be in, and then pick up the series next merge window. Or
> you can accept the versions without taking in pieces that have external
> dependencies.
Sure, I explained the rationale, you are adamant on not being convinced,
without a counter reason - what is the breakage here that you can see
when merged through to rc1 target OR to linux-next?
And maybe doing some thing like this will help on (say on arm-soc PR in
5.11?)
for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done
At all points in time, nodes are just inactive if the driver is
disabled for some reason (either the driver is not enabled or the
binding changes are not in) - they are never broken, Boot is not
broken (a function is broken when that function support exists in
Image file AND dts node for some reason results in that function
not working) - yes, someone can claim NFS boot is broken or WIFI is
brokken when NFS boot or WIFI is not even introduced. etc.
If I go by the strictest rules, then I cannot even introduce a bugfix
which involves dts via arm-soc dts pull request since the dependencies
of erratum and property enabling the erratum all should come from the
subsystem trees.
Drivers being broken is not in anyone's interest. They tend to get
broken if there are no active users.. let us release often and test
often.. and I believe there is plenty of precedence in doing this
already - if there is a risky property, OK fine, lets discuss about it.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 21:18 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-21 21:18 UTC (permalink / raw)
To: Suman Anna
Cc: devicetree, Vignesh Raghavendra, Arnd Bergmann, Dave Gerlach,
Tony Lindgren, Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla,
Rob Herring, Aswath Govindraju, linux-arm-kernel
On 14:42-20210121, Suman Anna wrote:
> On 1/21/21 2:13 PM, Nishanth Menon wrote:
> > On 13:57-20210121, Suman Anna wrote:
> >> This is all moot when your own tree doesn't boot properly. In this case, you are
> >> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> >> nodes that were added or you need additional driver patches (which is not how
> >> maintainer-level trees are verified).
> >
> > Get your facts straight please.
> >
> > What do you mean does'nt boot? It does boot with initramfs which is
> > the minimum qual i had set for any new platform (along with. - your
> > need is for a device node to work - which is both a combination of
> > defconfig + driver updates.
>
> And please re-read my first email, and what I started out with. I am not sure "I
> will pick MMC nodes, but the entry criteria is only initramfs, and you need
> additional patches to get MMC boot to work" is right. Normal thing to do is to
> take in the next merge cycle.
Sigh.
As I stated, the reason I prefer not to do that is because the drivers
will bit-rot for a kernel window without users. Why is it just MMC?
Start off with uart:
compatible = "ti,am64-uart", "ti,am654-uart";
That is not in v5.11-rc1 - it only works because driver is falling back
on the backward compatible nature of the device. The binding and driver
fixes are already on next.
MMC by itself wont boot unless the defconfig changes were merged in
upstream - and that was a painful choice to make to prevent the common Image
file from bloating too much..
I mean, is there a real concern that
https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/
or
https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/
or ....
will be dropped, in which case, we should'nt introduce in the next
kernel version, so that also means that those drivers will remain as is
without users for a complete kernel cycle.
I am not saying there are'nt instances where things have happened..
these changes have been in next for sufficiently long cycles for that
NOT to happen. Without users, they can unfortunately break and no one
will be the wiser till we enable the nodes again.. That would be a waste
of everyone's time.
> >>
> >> Arnd,
> >> Can you please guide us here as to what is expected in general, given that the
> >> pull-request from Nishanth goes through you, and if there is some pre-existing
> >> norms around this?
> >>
> >> Tony,
> >> Appreciate your input as well since you probably have dealt with these kinda of
> >> dependencies on OMAP.
> >
> > I am more than happy to drop this entire SoC off my queue (I am yet to
> > pick it up), which is probably what I will do.
> >
>
> You are the maintainer, do what feels right to you. You can as well wait for the
> MMC driver changes to be in, and then pick up the series next merge window. Or
> you can accept the versions without taking in pieces that have external
> dependencies.
Sure, I explained the rationale, you are adamant on not being convinced,
without a counter reason - what is the breakage here that you can see
when merged through to rc1 target OR to linux-next?
And maybe doing some thing like this will help on (say on arm-soc PR in
5.11?)
for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done
At all points in time, nodes are just inactive if the driver is
disabled for some reason (either the driver is not enabled or the
binding changes are not in) - they are never broken, Boot is not
broken (a function is broken when that function support exists in
Image file AND dts node for some reason results in that function
not working) - yes, someone can claim NFS boot is broken or WIFI is
brokken when NFS boot or WIFI is not even introduced. etc.
If I go by the strictest rules, then I cannot even introduce a bugfix
which involves dts via arm-soc dts pull request since the dependencies
of erratum and property enabling the erratum all should come from the
subsystem trees.
Drivers being broken is not in anyone's interest. They tend to get
broken if there are no active users.. let us release often and test
often.. and I believe there is plenty of precedence in doing this
already - if there is a risky property, OK fine, lets discuss about it.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 21:18 ` Nishanth Menon
@ 2021-01-21 22:57 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 22:57 UTC (permalink / raw)
To: Nishanth Menon
Cc: Arnd Bergmann, Tony Lindgren, Dave Gerlach, linux-arm-kernel,
devicetree, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On 1/21/21 3:18 PM, Nishanth Menon wrote:
> On 14:42-20210121, Suman Anna wrote:
>> On 1/21/21 2:13 PM, Nishanth Menon wrote:
>>> On 13:57-20210121, Suman Anna wrote:
>>>> This is all moot when your own tree doesn't boot properly. In this case, you are
>>>> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
>>>> nodes that were added or you need additional driver patches (which is not how
>>>> maintainer-level trees are verified).
>>>
>>> Get your facts straight please.
>>>
>>> What do you mean does'nt boot? It does boot with initramfs which is
>>> the minimum qual i had set for any new platform (along with. - your
>>> need is for a device node to work - which is both a combination of
>>> defconfig + driver updates.
>>
>> And please re-read my first email, and what I started out with. I am not sure "I
>> will pick MMC nodes, but the entry criteria is only initramfs, and you need
>> additional patches to get MMC boot to work" is right. Normal thing to do is to
>> take in the next merge cycle.
>
> Sigh.
>
> As I stated, the reason I prefer not to do that is because the drivers
> will bit-rot for a kernel window without users.
This is a classic chicken and egg problem, right? We need the bindings and
drivers to be in, and for validating those while submitting, you would need
additional dts nodes. But for adding the dts nodes, we need the bindings unless
the node you are adding has a fallback option, and lately does satisfy the
dtbs_check.
I understand what you are trying to say, but I am not sure of what to make of
this statement from Documentation/devicetree/bindings/submitting-patches.rst,
and how this is being followed in reality.
6) Any compatible strings used in a chip or board DTS file must be
previously documented in the corresponding DT binding text file
in Documentation/devicetree/bindings. This rule applies even if
the Linux device driver does not yet match on the compatible
string. [ checkpatch will emit warnings if this step is not
followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864
("checkpatch: add DT compatible string documentation checks"). ]
So, this looks to be an open interpretation from the respective dts tree
maintainers then, isn't it, probably depends on how their automation tools work?
Why is it just MMC?
>
> Start off with uart:
>
> compatible = "ti,am64-uart", "ti,am654-uart";
>
> That is not in v5.11-rc1 - it only works because driver is falling back
> on the backward compatible nature of the device. The binding and driver
> fixes are already on next.
He he, bad example :). This is in v5.11-rc1, see commit 441494ec2a30 ("
dt-bindings: serial: 8250_omap: Add compatible for UART controller on AM64 SoC")
>
> MMC by itself wont boot unless the defconfig changes were merged in
> upstream - and that was a painful choice to make to prevent the common Image
> file from bloating too much..
The K3 MMC is enabled by default since v5.9, see commit
3506ddd676a3 ("arm64: defconfig: Enable AM654x SDHCI controller")
>
> I mean, is there a real concern that
> https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/
> or
> https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/
> or ....
>
> will be dropped, in which case, we should'nt introduce in the next
> kernel version, so that also means that those drivers will remain as is
> without users for a complete kernel cycle.
>
> I am not saying there are'nt instances where things have happened..
> these changes have been in next for sufficiently long cycles for that
> NOT to happen. Without users, they can unfortunately break and no one
> will be the wiser till we enable the nodes again.. That would be a waste
> of everyone's time.
>
>
>>>>
>>>> Arnd,
>>>> Can you please guide us here as to what is expected in general, given that the
>>>> pull-request from Nishanth goes through you, and if there is some pre-existing
>>>> norms around this?
>>>>
>>>> Tony,
>>>> Appreciate your input as well since you probably have dealt with these kinda of
>>>> dependencies on OMAP.
>>>
>>> I am more than happy to drop this entire SoC off my queue (I am yet to
>>> pick it up), which is probably what I will do.
>>>
>>
>> You are the maintainer, do what feels right to you. You can as well wait for the
>> MMC driver changes to be in, and then pick up the series next merge window. Or
>> you can accept the versions without taking in pieces that have external
>> dependencies.
>
>
> Sure, I explained the rationale, you are adamant on not being convinced,
> without a counter reason - what is the breakage here that you can see
> when merged through to rc1 target OR to linux-next?
There shouldn't be any issues when everything including the corresponding driver
changes gets merged to -rc1 (they are already in linux-next). I reported my
observations based on seeing MMC nodes and trying MMC boot on your tree, the one
that you would use to send your PR and the checkpatch warnings on it (dtbs_check
strangely didn't fail when I would have expected it to).
>
> And maybe doing some thing like this will help on (say on arm-soc PR in
> 5.11?)
>
> for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done
>
>
> At all points in time, nodes are just inactive if the driver is
> disabled for some reason (either the driver is not enabled or the
> binding changes are not in) - they are never broken, Boot is not
> broken (a function is broken when that function support exists in
> Image file AND dts node for some reason results in that function
> not working) - yes, someone can claim NFS boot is broken or WIFI is
> brokken when NFS boot or WIFI is not even introduced. etc.
>
> If I go by the strictest rules, then I cannot even introduce a bugfix
> which involves dts via arm-soc dts pull request since the dependencies
> of erratum and property enabling the erratum all should come from the
> subsystem trees.
>
> Drivers being broken is not in anyone's interest. They tend to get
> broken if there are no active users.. let us release often and test
> often.. and I believe there is plenty of precedence in doing this
> already - if there is a risky property, OK fine, lets discuss about it.
>
Yes, I understand all of this, and no comments here.
All I am asking is clarification on the process semantics, we have them for a
reason right? If there is a practical usage agreement/argument around it, I am
welcome to get acquainted to it..
regards
Suman
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-21 22:57 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-21 22:57 UTC (permalink / raw)
To: Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Arnd Bergmann, Dave Gerlach,
Tony Lindgren, Sekhar Nori, Kishon Vijay Abraham, Lokesh Vutla,
Rob Herring, Aswath Govindraju, linux-arm-kernel
On 1/21/21 3:18 PM, Nishanth Menon wrote:
> On 14:42-20210121, Suman Anna wrote:
>> On 1/21/21 2:13 PM, Nishanth Menon wrote:
>>> On 13:57-20210121, Suman Anna wrote:
>>>> This is all moot when your own tree doesn't boot properly. In this case, you are
>>>> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
>>>> nodes that were added or you need additional driver patches (which is not how
>>>> maintainer-level trees are verified).
>>>
>>> Get your facts straight please.
>>>
>>> What do you mean does'nt boot? It does boot with initramfs which is
>>> the minimum qual i had set for any new platform (along with. - your
>>> need is for a device node to work - which is both a combination of
>>> defconfig + driver updates.
>>
>> And please re-read my first email, and what I started out with. I am not sure "I
>> will pick MMC nodes, but the entry criteria is only initramfs, and you need
>> additional patches to get MMC boot to work" is right. Normal thing to do is to
>> take in the next merge cycle.
>
> Sigh.
>
> As I stated, the reason I prefer not to do that is because the drivers
> will bit-rot for a kernel window without users.
This is a classic chicken and egg problem, right? We need the bindings and
drivers to be in, and for validating those while submitting, you would need
additional dts nodes. But for adding the dts nodes, we need the bindings unless
the node you are adding has a fallback option, and lately does satisfy the
dtbs_check.
I understand what you are trying to say, but I am not sure of what to make of
this statement from Documentation/devicetree/bindings/submitting-patches.rst,
and how this is being followed in reality.
6) Any compatible strings used in a chip or board DTS file must be
previously documented in the corresponding DT binding text file
in Documentation/devicetree/bindings. This rule applies even if
the Linux device driver does not yet match on the compatible
string. [ checkpatch will emit warnings if this step is not
followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864
("checkpatch: add DT compatible string documentation checks"). ]
So, this looks to be an open interpretation from the respective dts tree
maintainers then, isn't it, probably depends on how their automation tools work?
Why is it just MMC?
>
> Start off with uart:
>
> compatible = "ti,am64-uart", "ti,am654-uart";
>
> That is not in v5.11-rc1 - it only works because driver is falling back
> on the backward compatible nature of the device. The binding and driver
> fixes are already on next.
He he, bad example :). This is in v5.11-rc1, see commit 441494ec2a30 ("
dt-bindings: serial: 8250_omap: Add compatible for UART controller on AM64 SoC")
>
> MMC by itself wont boot unless the defconfig changes were merged in
> upstream - and that was a painful choice to make to prevent the common Image
> file from bloating too much..
The K3 MMC is enabled by default since v5.9, see commit
3506ddd676a3 ("arm64: defconfig: Enable AM654x SDHCI controller")
>
> I mean, is there a real concern that
> https://lore.kernel.org/linux-devicetree/20201029065318.2437-1-vigneshr@ti.com/
> or
> https://lore.kernel.org/linux-devicetree/20210115193218.5809-1-grygorii.strashko@ti.com/
> or ....
>
> will be dropped, in which case, we should'nt introduce in the next
> kernel version, so that also means that those drivers will remain as is
> without users for a complete kernel cycle.
>
> I am not saying there are'nt instances where things have happened..
> these changes have been in next for sufficiently long cycles for that
> NOT to happen. Without users, they can unfortunately break and no one
> will be the wiser till we enable the nodes again.. That would be a waste
> of everyone's time.
>
>
>>>>
>>>> Arnd,
>>>> Can you please guide us here as to what is expected in general, given that the
>>>> pull-request from Nishanth goes through you, and if there is some pre-existing
>>>> norms around this?
>>>>
>>>> Tony,
>>>> Appreciate your input as well since you probably have dealt with these kinda of
>>>> dependencies on OMAP.
>>>
>>> I am more than happy to drop this entire SoC off my queue (I am yet to
>>> pick it up), which is probably what I will do.
>>>
>>
>> You are the maintainer, do what feels right to you. You can as well wait for the
>> MMC driver changes to be in, and then pick up the series next merge window. Or
>> you can accept the versions without taking in pieces that have external
>> dependencies.
>
>
> Sure, I explained the rationale, you are adamant on not being convinced,
> without a counter reason - what is the breakage here that you can see
> when merged through to rc1 target OR to linux-next?
There shouldn't be any issues when everything including the corresponding driver
changes gets merged to -rc1 (they are already in linux-next). I reported my
observations based on seeing MMC nodes and trying MMC boot on your tree, the one
that you would use to send your PR and the checkpatch warnings on it (dtbs_check
strangely didn't fail when I would have expected it to).
>
> And maybe doing some thing like this will help on (say on arm-soc PR in
> 5.11?)
>
> for f in `git diff v5.10-rc3..|diffstat|cut -d '|' -f1 |tr -d ' '|grep dts$|sed -e "s/^b/./g"`; do ./scripts/checkpatch.pl -f $f |grep compatible; done
>
>
> At all points in time, nodes are just inactive if the driver is
> disabled for some reason (either the driver is not enabled or the
> binding changes are not in) - they are never broken, Boot is not
> broken (a function is broken when that function support exists in
> Image file AND dts node for some reason results in that function
> not working) - yes, someone can claim NFS boot is broken or WIFI is
> brokken when NFS boot or WIFI is not even introduced. etc.
>
> If I go by the strictest rules, then I cannot even introduce a bugfix
> which involves dts via arm-soc dts pull request since the dependencies
> of erratum and property enabling the erratum all should come from the
> subsystem trees.
>
> Drivers being broken is not in anyone's interest. They tend to get
> broken if there are no active users.. let us release often and test
> often.. and I believe there is plenty of precedence in doing this
> already - if there is a risky property, OK fine, lets discuss about it.
>
Yes, I understand all of this, and no comments here.
All I am asking is clarification on the process semantics, we have them for a
reason right? If there is a practical usage agreement/argument around it, I am
welcome to get acquainted to it..
regards
Suman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-21 19:57 ` Suman Anna
@ 2021-01-22 11:23 ` Arnd Bergmann
-1 siblings, 0 replies; 50+ messages in thread
From: Arnd Bergmann @ 2021-01-22 11:23 UTC (permalink / raw)
To: Suman Anna
Cc: Nishanth Menon, Arnd Bergmann, Tony Lindgren, Dave Gerlach,
Linux ARM, DTML, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > On 12:13-20210121, Suman Anna wrote:
> >>
> >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> >
> > What is counter intutive about a -next branch be tested against
> > linux-next tree?
>
> The -next process is well understood. FWIW, you are not sending your PR against
> -next branch, but against primarily a -rc1 or -rc2 baseline.
>
> As a developer, when I am submitting patches, I am making sure that things are
> functional against the baseline you use. For example, when I split functionality
> into a driver portions and dts portions, I need to make sure both those
> individual pieces boot fine and do not cause regressions, even though for the
> final functionality, you need both.
> >
> >
> > Now, if you want to launch a product with my -next branch - go ahead, I
> > don't intent it for current kernel version - you are on your own.
> >
> > If there is a real risk of upstream next-breaking - speakup with an
> > real example - All I care about is keeping upstream functional and
> > useable.
>
> This is all moot when your own tree doesn't boot properly. In this case, you are
> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> nodes that were added or you need additional driver patches (which is not how
> maintainer-level trees are verified).
>
> Arnd,
> Can you please guide us here as to what is expected in general, given that the
> pull-request from Nishanth goes through you, and if there is some pre-existing
> norms around this?
There are two very different cases to consider, and I'm not sure which one
we have here:
- When submitting any changes to a working platform, each patch on
a branch that gets merged needs to work incrementally, e.g. a device
tree change merged through the soc tree must never stop a platform
from booting without a patch that gets merged through another branch
in the same merge window, or vice versa.
As an extension of this, I would actually appreciate if we never do
incompatible binding changes at all. If a driver patch enables a new
binding for already supported hardware, a second patch changes
the dts file to use the new binding, and a third patch removes the
original binding, this could still be done without regressions over
multiple merge windows, but it breaks the assumption that a new
kernel can boot with an old dtb (or vice versa). This second one
is a softer requirement, and we can make exceptions for particularly
good reasons, but please explain those in the patch description and
discuss with upstream maintainers before submitting patches that do
this.
- For a newly added hardware support, having a runtime dependency
on another branch is not a problem, we do that all the time: Adding
a device node for an existing board (or a new board) and the driver
code in another branch is not a regression because each branch
only has incremental changes that improve hardware support, and
it will work as soon as both are merged.
You raised the point about device bindings, which is best addressed
by having one commit that adds the (reviewed) binding document
first, and then have the driver branch and the dts branch based on
the same commit.
I hope that clarifies the case you are interested in, let me know if I
missed something for the specific case at hand.
Arnd
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-22 11:23 ` Arnd Bergmann
0 siblings, 0 replies; 50+ messages in thread
From: Arnd Bergmann @ 2021-01-22 11:23 UTC (permalink / raw)
To: Suman Anna
Cc: Nishanth Menon, DTML, Vignesh Raghavendra, Arnd Bergmann,
Dave Gerlach, Tony Lindgren, Sekhar Nori, Kishon Vijay Abraham,
Lokesh Vutla, Rob Herring, Aswath Govindraju, Linux ARM
On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > On 12:13-20210121, Suman Anna wrote:
> >>
> >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> >
> > What is counter intutive about a -next branch be tested against
> > linux-next tree?
>
> The -next process is well understood. FWIW, you are not sending your PR against
> -next branch, but against primarily a -rc1 or -rc2 baseline.
>
> As a developer, when I am submitting patches, I am making sure that things are
> functional against the baseline you use. For example, when I split functionality
> into a driver portions and dts portions, I need to make sure both those
> individual pieces boot fine and do not cause regressions, even though for the
> final functionality, you need both.
> >
> >
> > Now, if you want to launch a product with my -next branch - go ahead, I
> > don't intent it for current kernel version - you are on your own.
> >
> > If there is a real risk of upstream next-breaking - speakup with an
> > real example - All I care about is keeping upstream functional and
> > useable.
>
> This is all moot when your own tree doesn't boot properly. In this case, you are
> adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> nodes that were added or you need additional driver patches (which is not how
> maintainer-level trees are verified).
>
> Arnd,
> Can you please guide us here as to what is expected in general, given that the
> pull-request from Nishanth goes through you, and if there is some pre-existing
> norms around this?
There are two very different cases to consider, and I'm not sure which one
we have here:
- When submitting any changes to a working platform, each patch on
a branch that gets merged needs to work incrementally, e.g. a device
tree change merged through the soc tree must never stop a platform
from booting without a patch that gets merged through another branch
in the same merge window, or vice versa.
As an extension of this, I would actually appreciate if we never do
incompatible binding changes at all. If a driver patch enables a new
binding for already supported hardware, a second patch changes
the dts file to use the new binding, and a third patch removes the
original binding, this could still be done without regressions over
multiple merge windows, but it breaks the assumption that a new
kernel can boot with an old dtb (or vice versa). This second one
is a softer requirement, and we can make exceptions for particularly
good reasons, but please explain those in the patch description and
discuss with upstream maintainers before submitting patches that do
this.
- For a newly added hardware support, having a runtime dependency
on another branch is not a problem, we do that all the time: Adding
a device node for an existing board (or a new board) and the driver
code in another branch is not a regression because each branch
only has incremental changes that improve hardware support, and
it will work as soon as both are merged.
You raised the point about device bindings, which is best addressed
by having one commit that adds the (reviewed) binding document
first, and then have the driver branch and the dts branch based on
the same commit.
I hope that clarifies the case you are interested in, let me know if I
missed something for the specific case at hand.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-22 11:23 ` Arnd Bergmann
@ 2021-01-22 13:00 ` Tony Lindgren
-1 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2021-01-22 13:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Suman Anna, Nishanth Menon, Arnd Bergmann, Dave Gerlach,
Linux ARM, DTML, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
* Arnd Bergmann <arnd@kernel.org> [210122 11:24]:
> On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> > On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > > On 12:13-20210121, Suman Anna wrote:
> > >>
> > >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> > >
> > > What is counter intutive about a -next branch be tested against
> > > linux-next tree?
> >
> > The -next process is well understood. FWIW, you are not sending your PR against
> > -next branch, but against primarily a -rc1 or -rc2 baseline.
> >
> > As a developer, when I am submitting patches, I am making sure that things are
> > functional against the baseline you use. For example, when I split functionality
> > into a driver portions and dts portions, I need to make sure both those
> > individual pieces boot fine and do not cause regressions, even though for the
> > final functionality, you need both.
> > >
> > >
> > > Now, if you want to launch a product with my -next branch - go ahead, I
> > > don't intent it for current kernel version - you are on your own.
> > >
> > > If there is a real risk of upstream next-breaking - speakup with an
> > > real example - All I care about is keeping upstream functional and
> > > useable.
> >
> > This is all moot when your own tree doesn't boot properly. In this case, you are
> > adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> > nodes that were added or you need additional driver patches (which is not how
> > maintainer-level trees are verified).
> >
> > Arnd,
> > Can you please guide us here as to what is expected in general, given that the
> > pull-request from Nishanth goes through you, and if there is some pre-existing
> > norms around this?
>
> There are two very different cases to consider, and I'm not sure which one
> we have here:
>
> - When submitting any changes to a working platform, each patch on
> a branch that gets merged needs to work incrementally, e.g. a device
> tree change merged through the soc tree must never stop a platform
> from booting without a patch that gets merged through another branch
> in the same merge window, or vice versa.
> As an extension of this, I would actually appreciate if we never do
> incompatible binding changes at all. If a driver patch enables a new
> binding for already supported hardware, a second patch changes
> the dts file to use the new binding, and a third patch removes the
> original binding, this could still be done without regressions over
> multiple merge windows, but it breaks the assumption that a new
> kernel can boot with an old dtb (or vice versa). This second one
> is a softer requirement, and we can make exceptions for particularly
> good reasons, but please explain those in the patch description and
> discuss with upstream maintainers before submitting patches that do
> this.
>
> - For a newly added hardware support, having a runtime dependency
> on another branch is not a problem, we do that all the time: Adding
> a device node for an existing board (or a new board) and the driver
> code in another branch is not a regression because each branch
> only has incremental changes that improve hardware support, and
> it will work as soon as both are merged.
> You raised the point about device bindings, which is best addressed
> by having one commit that adds the (reviewed) binding document
> first, and then have the driver branch and the dts branch based on
> the same commit.
>
> I hope that clarifies the case you are interested in, let me know if I
> missed something for the specific case at hand.
Hmm and additionally few more mostly obvious things that have helped
quite a bit:
- Each commit in each topic branch should compile and boot so git
bisect works
- Each topic branch should be ideally based on -rc1 to leave out
dependencies to other branches
- Aiming for a working and usable -rc1 is worth the effort in case
git bisect is needed for any top branches based on it :) Otherwise
you'll be wasting the -rc cycle chasing regressions..
Regards,
Tony
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-22 13:00 ` Tony Lindgren
0 siblings, 0 replies; 50+ messages in thread
From: Tony Lindgren @ 2021-01-22 13:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Nishanth Menon, DTML, Vignesh Raghavendra, Arnd Bergmann,
Dave Gerlach, Lokesh Vutla, Sekhar Nori, Kishon Vijay Abraham,
Rob Herring, Aswath Govindraju, Linux ARM
* Arnd Bergmann <arnd@kernel.org> [210122 11:24]:
> On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> > On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > > On 12:13-20210121, Suman Anna wrote:
> > >>
> > >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> > >
> > > What is counter intutive about a -next branch be tested against
> > > linux-next tree?
> >
> > The -next process is well understood. FWIW, you are not sending your PR against
> > -next branch, but against primarily a -rc1 or -rc2 baseline.
> >
> > As a developer, when I am submitting patches, I am making sure that things are
> > functional against the baseline you use. For example, when I split functionality
> > into a driver portions and dts portions, I need to make sure both those
> > individual pieces boot fine and do not cause regressions, even though for the
> > final functionality, you need both.
> > >
> > >
> > > Now, if you want to launch a product with my -next branch - go ahead, I
> > > don't intent it for current kernel version - you are on your own.
> > >
> > > If there is a real risk of upstream next-breaking - speakup with an
> > > real example - All I care about is keeping upstream functional and
> > > useable.
> >
> > This is all moot when your own tree doesn't boot properly. In this case, you are
> > adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> > nodes that were added or you need additional driver patches (which is not how
> > maintainer-level trees are verified).
> >
> > Arnd,
> > Can you please guide us here as to what is expected in general, given that the
> > pull-request from Nishanth goes through you, and if there is some pre-existing
> > norms around this?
>
> There are two very different cases to consider, and I'm not sure which one
> we have here:
>
> - When submitting any changes to a working platform, each patch on
> a branch that gets merged needs to work incrementally, e.g. a device
> tree change merged through the soc tree must never stop a platform
> from booting without a patch that gets merged through another branch
> in the same merge window, or vice versa.
> As an extension of this, I would actually appreciate if we never do
> incompatible binding changes at all. If a driver patch enables a new
> binding for already supported hardware, a second patch changes
> the dts file to use the new binding, and a third patch removes the
> original binding, this could still be done without regressions over
> multiple merge windows, but it breaks the assumption that a new
> kernel can boot with an old dtb (or vice versa). This second one
> is a softer requirement, and we can make exceptions for particularly
> good reasons, but please explain those in the patch description and
> discuss with upstream maintainers before submitting patches that do
> this.
>
> - For a newly added hardware support, having a runtime dependency
> on another branch is not a problem, we do that all the time: Adding
> a device node for an existing board (or a new board) and the driver
> code in another branch is not a regression because each branch
> only has incremental changes that improve hardware support, and
> it will work as soon as both are merged.
> You raised the point about device bindings, which is best addressed
> by having one commit that adds the (reviewed) binding document
> first, and then have the driver branch and the dts branch based on
> the same commit.
>
> I hope that clarifies the case you are interested in, let me know if I
> missed something for the specific case at hand.
Hmm and additionally few more mostly obvious things that have helped
quite a bit:
- Each commit in each topic branch should compile and boot so git
bisect works
- Each topic branch should be ideally based on -rc1 to leave out
dependencies to other branches
- Aiming for a working and usable -rc1 is worth the effort in case
git bisect is needed for any top branches based on it :) Otherwise
you'll be wasting the -rc cycle chasing regressions..
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-22 13:00 ` Tony Lindgren
@ 2021-01-25 14:16 ` Nishanth Menon
-1 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-25 14:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: Arnd Bergmann, Suman Anna, Arnd Bergmann, Dave Gerlach,
Linux ARM, DTML, Rob Herring, Vignesh Raghavendra, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Aswath Govindraju
Arnd, Tony,
On 15:00-20210122, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@kernel.org> [210122 11:24]:
> > On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> > > On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > > > On 12:13-20210121, Suman Anna wrote:
> > > >>
> > > >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> > > >
> > > > What is counter intutive about a -next branch be tested against
> > > > linux-next tree?
> > >
> > > The -next process is well understood. FWIW, you are not sending your PR against
> > > -next branch, but against primarily a -rc1 or -rc2 baseline.
> > >
> > > As a developer, when I am submitting patches, I am making sure that things are
> > > functional against the baseline you use. For example, when I split functionality
> > > into a driver portions and dts portions, I need to make sure both those
> > > individual pieces boot fine and do not cause regressions, even though for the
> > > final functionality, you need both.
> > > >
> > > >
> > > > Now, if you want to launch a product with my -next branch - go ahead, I
> > > > don't intent it for current kernel version - you are on your own.
> > > >
> > > > If there is a real risk of upstream next-breaking - speakup with an
> > > > real example - All I care about is keeping upstream functional and
> > > > useable.
> > >
> > > This is all moot when your own tree doesn't boot properly. In this case, you are
> > > adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> > > nodes that were added or you need additional driver patches (which is not how
> > > maintainer-level trees are verified).
> > >
> > > Arnd,
> > > Can you please guide us here as to what is expected in general, given that the
> > > pull-request from Nishanth goes through you, and if there is some pre-existing
> > > norms around this?
> >
> > There are two very different cases to consider, and I'm not sure which one
> > we have here:
> >
> > - When submitting any changes to a working platform, each patch on
> > a branch that gets merged needs to work incrementally, e.g. a device
> > tree change merged through the soc tree must never stop a platform
> > from booting without a patch that gets merged through another branch
> > in the same merge window, or vice versa.
> > As an extension of this, I would actually appreciate if we never do
> > incompatible binding changes at all. If a driver patch enables a new
> > binding for already supported hardware, a second patch changes
> > the dts file to use the new binding, and a third patch removes the
> > original binding, this could still be done without regressions over
> > multiple merge windows, but it breaks the assumption that a new
> > kernel can boot with an old dtb (or vice versa). This second one
> > is a softer requirement, and we can make exceptions for particularly
> > good reasons, but please explain those in the patch description and
> > discuss with upstream maintainers before submitting patches that do
> > this.
> >
> > - For a newly added hardware support, having a runtime dependency
> > on another branch is not a problem, we do that all the time: Adding
> > a device node for an existing board (or a new board) and the driver
> > code in another branch is not a regression because each branch
> > only has incremental changes that improve hardware support, and
> > it will work as soon as both are merged.
> > You raised the point about device bindings, which is best addressed
> > by having one commit that adds the (reviewed) binding document
> > first, and then have the driver branch and the dts branch based on
> > the same commit.
> >
> > I hope that clarifies the case you are interested in, let me know if I
> > missed something for the specific case at hand.
>
> Hmm and additionally few more mostly obvious things that have helped
> quite a bit:
>
> - Each commit in each topic branch should compile and boot so git
> bisect works
>
> - Each topic branch should be ideally based on -rc1 to leave out
> dependencies to other branches
>
> - Aiming for a working and usable -rc1 is worth the effort in case
> git bisect is needed for any top branches based on it :) Otherwise
> you'll be wasting the -rc cycle chasing regressions..
Thank you both for your valuable insight and direction. much
appreciated.
*) for every patch that is integrated - I already insist on
bisectability, no warnings with W=2 , dtbs_check .... Including
putting additional tooling[1] in place for folks to use - which goes
and tests sparse, coccinelle etc.. The team has been pretty deligent
in making sure things are clean.
*) We also insist on testing with linux-next to maintain rc1
functionality
*) I also maintain the minimal boot requirements equivalent to kernelci
(example:[2]) for my -next branch as well.
Yes, this series introduces 0 regression, new nodes are being added
and the thing I missed for this window, which is insisting on getting
immutable tags from subsystem maintainers for dt-bindings patches they
have picked up, will be rectified in the future. For this window,
for the last time, I am going to depend a bit on the later merge of
arm-soc.
Thanks for the clarifications, once again.
[1] https://github.com/nmenon/kernel_patch_verify
[2] https://storage.kernelci.org/stable/linux-4.14.y/v4.14.217/arm/omap2plus_defconfig/gcc-8/lab-cip/baseline-beaglebone-black.txt
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-25 14:16 ` Nishanth Menon
0 siblings, 0 replies; 50+ messages in thread
From: Nishanth Menon @ 2021-01-25 14:16 UTC (permalink / raw)
To: Tony Lindgren
Cc: Arnd Bergmann, Vignesh Raghavendra, Arnd Bergmann, DTML,
Lokesh Vutla, Dave Gerlach, Sekhar Nori, Kishon Vijay Abraham,
Rob Herring, Aswath Govindraju, Linux ARM
Arnd, Tony,
On 15:00-20210122, Tony Lindgren wrote:
> * Arnd Bergmann <arnd@kernel.org> [210122 11:24]:
> > On Thu, Jan 21, 2021 at 8:57 PM Suman Anna <s-anna@ti.com> wrote:
> > > On 1/21/21 12:39 PM, Nishanth Menon wrote:
> > > > On 12:13-20210121, Suman Anna wrote:
> > > >>
> > > >> Hmm, this is kinda counter-intuitive. When I see a dts node, I am expecting the
> > > >
> > > > What is counter intutive about a -next branch be tested against
> > > > linux-next tree?
> > >
> > > The -next process is well understood. FWIW, you are not sending your PR against
> > > -next branch, but against primarily a -rc1 or -rc2 baseline.
> > >
> > > As a developer, when I am submitting patches, I am making sure that things are
> > > functional against the baseline you use. For example, when I split functionality
> > > into a driver portions and dts portions, I need to make sure both those
> > > individual pieces boot fine and do not cause regressions, even though for the
> > > final functionality, you need both.
> > > >
> > > >
> > > > Now, if you want to launch a product with my -next branch - go ahead, I
> > > > don't intent it for current kernel version - you are on your own.
> > > >
> > > > If there is a real risk of upstream next-breaking - speakup with an
> > > > real example - All I care about is keeping upstream functional and
> > > > useable.
> > >
> > > This is all moot when your own tree doesn't boot properly. In this case, you are
> > > adding MMC nodes, but yet for a boot test, you are saying use linux-next for the
> > > nodes that were added or you need additional driver patches (which is not how
> > > maintainer-level trees are verified).
> > >
> > > Arnd,
> > > Can you please guide us here as to what is expected in general, given that the
> > > pull-request from Nishanth goes through you, and if there is some pre-existing
> > > norms around this?
> >
> > There are two very different cases to consider, and I'm not sure which one
> > we have here:
> >
> > - When submitting any changes to a working platform, each patch on
> > a branch that gets merged needs to work incrementally, e.g. a device
> > tree change merged through the soc tree must never stop a platform
> > from booting without a patch that gets merged through another branch
> > in the same merge window, or vice versa.
> > As an extension of this, I would actually appreciate if we never do
> > incompatible binding changes at all. If a driver patch enables a new
> > binding for already supported hardware, a second patch changes
> > the dts file to use the new binding, and a third patch removes the
> > original binding, this could still be done without regressions over
> > multiple merge windows, but it breaks the assumption that a new
> > kernel can boot with an old dtb (or vice versa). This second one
> > is a softer requirement, and we can make exceptions for particularly
> > good reasons, but please explain those in the patch description and
> > discuss with upstream maintainers before submitting patches that do
> > this.
> >
> > - For a newly added hardware support, having a runtime dependency
> > on another branch is not a problem, we do that all the time: Adding
> > a device node for an existing board (or a new board) and the driver
> > code in another branch is not a regression because each branch
> > only has incremental changes that improve hardware support, and
> > it will work as soon as both are merged.
> > You raised the point about device bindings, which is best addressed
> > by having one commit that adds the (reviewed) binding document
> > first, and then have the driver branch and the dts branch based on
> > the same commit.
> >
> > I hope that clarifies the case you are interested in, let me know if I
> > missed something for the specific case at hand.
>
> Hmm and additionally few more mostly obvious things that have helped
> quite a bit:
>
> - Each commit in each topic branch should compile and boot so git
> bisect works
>
> - Each topic branch should be ideally based on -rc1 to leave out
> dependencies to other branches
>
> - Aiming for a working and usable -rc1 is worth the effort in case
> git bisect is needed for any top branches based on it :) Otherwise
> you'll be wasting the -rc cycle chasing regressions..
Thank you both for your valuable insight and direction. much
appreciated.
*) for every patch that is integrated - I already insist on
bisectability, no warnings with W=2 , dtbs_check .... Including
putting additional tooling[1] in place for folks to use - which goes
and tests sparse, coccinelle etc.. The team has been pretty deligent
in making sure things are clean.
*) We also insist on testing with linux-next to maintain rc1
functionality
*) I also maintain the minimal boot requirements equivalent to kernelci
(example:[2]) for my -next branch as well.
Yes, this series introduces 0 regression, new nodes are being added
and the thing I missed for this window, which is insisting on getting
immutable tags from subsystem maintainers for dt-bindings patches they
have picked up, will be rectified in the future. For this window,
for the last time, I am going to depend a bit on the later merge of
arm-soc.
Thanks for the clarifications, once again.
[1] https://github.com/nmenon/kernel_patch_verify
[2] https://storage.kernelci.org/stable/linux-4.14.y/v4.14.217/arm/omap2plus_defconfig/gcc-8/lab-cip/baseline-beaglebone-black.txt
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread
* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-20 20:25 ` Dave Gerlach
@ 2021-01-25 22:48 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-25 22:48 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: linux-arm-kernel, devicetree, Rob Herring, Tony Lindgren,
Vignesh Raghavendra, Sekhar Nori, Kishon Vijay Abraham,
Lokesh Vutla, Aswath Govindraju
Hi Dave,
On 1/20/21 2:25 PM, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
>
> Some highlights of this SoC are:
> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> MCUs, and a single Cortex-M4F.
> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> * Integrated Ethernet switch supporting up to a total of two external
> ports.
> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> peripherals.
> * Centralized System Controller for Security, Power, and Resource
> Management (DMSC).
>
> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> for further details: https://www.ti.com/lit/pdf/spruim2
>
> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> under cbass_mcu.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
> 4 files changed, 576 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> new file mode 100644
> index 000000000000..e3ef4bff04af
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_main {
> + oc_sram: sram@70000000 {
> + compatible = "mmio-sram";
> + reg = <0x00 0x70000000 0x00 0x200000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x70000000 0x200000>;
> +
> + atf-sram@0 {
> + reg = <0x0 0x1a000>;
> + };
> + };
> +
> + gic500: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: msi-controller@1820000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x00 0x01820000 0x00 0x10000>;
> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + dmss: dmss {
> + compatible = "simple-mfd";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-ranges;
> + ranges;
> +
> + secure_proxy_main: mailbox@4d000000 {
> + compatible = "ti,am654-secure-proxy";
> + #mbox-cells = <1>;
> + reg-names = "target_data", "rt", "scfg";
> + reg = <0x00 0x4d000000 0x00 0x80000>,
> + <0x00 0x4a600000 0x00 0x80000>,
> + <0x00 0x4a400000 0x00 0x80000>;
> + interrupt-names = "rx_012";
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> + dmsc: dmsc@44043000 {
> + compatible = "ti,k2g-sci";
> + ti,host-id = <12>;
> + mbox-names = "rx", "tx";
> + mboxes= <&secure_proxy_main 12>,
> + <&secure_proxy_main 13>;
> + reg-names = "debug_messages";
> + reg = <0x00 0x44043000 0x00 0xfe0>;
> +
> + k3_pds: power-controller {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <2>;
> + };
> +
> + k3_clks: clocks {
> + compatible = "ti,k2g-sci-clk";
> + #clock-cells = <2>;
> + };
> +
> + k3_reset: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> + };
> +
> + main_pmx0: pinctrl@f4000 {
> + compatible = "pinctrl-single";
> + reg = <0x00 0xf4000 0x00 0x2d0>;
Hmm, should the size be 0x2d8? I see the TRM defines a PADMMD_PADCONFIG181
register at 0xf42d4.
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xffffffff>;
> + };
> +
> + main_conf: syscon@43000000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x00 0x43000000 0x00 0x20000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00 0x00 0x43000000 0x20000>;
> +
> + chipid@14 {
> + compatible = "ti,am654-chipid";
> + reg = <0x00000014 0x4>;
> + };
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02800000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 146 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02810000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 152 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02820000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 153 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart3: serial@2830000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02830000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 154 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart4: serial@2840000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02840000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 155 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart5: serial@2850000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02850000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 156 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart6: serial@2860000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02860000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 158 0>;
> + clock-names = "fclk";
> + };
> +
> + main_i2c0: i2c@20000000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20000000 0x00 0x100>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 102 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c1: i2c@20010000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20010000 0x00 0x100>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 103 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c2: i2c@20020000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20020000 0x00 0x100>;
> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 104 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c3: i2c@20030000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20030000 0x00 0x100>;
> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 105 2>;
> + clock-names = "fck";
> + };
> +
> + main_spi0: spi@20100000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x20100000 0x00 0x400>;
> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 141 0>;
> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
> + dma-names = "tx0", "rx0";
> + };
> +
> + main_spi1: spi@20110000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20110000 0x00 0x400>;
> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 142 0>;
> + };
> +
> + main_spi2: spi@20120000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20120000 0x00 0x400>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 143 0>;
> + };
> +
> + main_spi3: spi@20130000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20130000 0x00 0x400>;
> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 144 0>;
> + };
> +
> + main_spi4: spi@20140000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20140000 0x00 0x400>;
> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 145 0>;
> + };
> +
> + sdhci0: mmc@fa10000 {
> + compatible = "ti,am64-sdhci-8bit";
> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-ddr52 = <0x6>;
> + ti,otap-del-sel-hs200 = <0x7>;
> + ti,otap-del-sel-hs400 = <0x4>;
> + };
> +
> + sdhci1: mmc@fa00000 {
> + compatible = "ti,am64-sdhci-4bit";
> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
> + clock-names = "clk_ahb", "clk_xin";
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-sd-hs = <0xf>;
> + ti,otap-del-sel-sdr12 = <0xf>;
> + ti,otap-del-sel-sdr25 = <0xf>;
> + ti,otap-del-sel-sdr50 = <0xc>;
> + ti,otap-del-sel-sdr104 = <0x6>;
> + ti,otap-del-sel-ddr50 = <0x9>;
> + ti,clkbuf-sel = <0x7>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> new file mode 100644
> index 000000000000..1d2be485a669
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_mcu {
> + mcu_uart0: serial@4a00000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a00000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 149 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_uart1: serial@4a10000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a10000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 160 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_i2c0: i2c@4900000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04900000 0x00 0x100>;
> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 106 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_i2c1: i2c@4910000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04910000 0x00 0x100>;
> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 107 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_spi0: spi@4b00000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x04b00000 0x00 0x400>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 147 0>;
> + };
> +
> + mcu_spi1: spi@4b10000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x04b10000 0x00 0x400>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 148 0>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> new file mode 100644
> index 000000000000..0ae8c844c482
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM642 SoC";
> + compatible = "ti,am642";
> + interrupt-parent = <&gic500>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &mcu_uart0;
> + serial1 = &mcu_uart1;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + serial5 = &main_uart3;
> + serial6 = &main_uart4;
> + serial7 = &main_uart5;
> + serial8 = &main_uart6;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + cbass_main: bus@f4000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
Follows the above..
regards
Suman
> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> +
> + /* MCU Domain Range */
> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
> +
> + cbass_mcu: bus@4000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
> + };
> + };
> +};
> +
> +/* Now include the peripherals for each bus segments */
> +#include "k3-am64-main.dtsi"
> +#include "k3-am64-mcu.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> new file mode 100644
> index 000000000000..e2b397c88401
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC family in Dual core configuration
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am64.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> + };
> +
> + L2_0: l2-cache0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x40000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + };
> +};
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-25 22:48 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-25 22:48 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Tony Lindgren, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
Hi Dave,
On 1/20/21 2:25 PM, Dave Gerlach wrote:
> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
> providing advanced system integration to enable applications such as
> Motor Drives, PLC, Remote IO and IoT Gateways.
>
> Some highlights of this SoC are:
> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
> MCUs, and a single Cortex-M4F.
> * Two Gigabit Industrial Communication Subsystems (ICSSG).
> * Integrated Ethernet switch supporting up to a total of two external
> ports.
> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
> peripherals.
> * Centralized System Controller for Security, Power, and Resource
> Management (DMSC).
>
> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
> for further details: https://www.ti.com/lit/pdf/spruim2
>
> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
> under cbass_main and the i2c, spi, and uart MCU domain periperhals
> under cbass_mcu.
>
> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
> 4 files changed, 576 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> new file mode 100644
> index 000000000000..e3ef4bff04af
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
> @@ -0,0 +1,332 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_main {
> + oc_sram: sram@70000000 {
> + compatible = "mmio-sram";
> + reg = <0x00 0x70000000 0x00 0x200000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x00 0x70000000 0x200000>;
> +
> + atf-sram@0 {
> + reg = <0x0 0x1a000>;
> + };
> + };
> +
> + gic500: interrupt-controller@1800000 {
> + compatible = "arm,gic-v3";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
> + /*
> + * vcpumntirq:
> + * virtual CPU interface maintenance interrupt
> + */
> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
> +
> + gic_its: msi-controller@1820000 {
> + compatible = "arm,gic-v3-its";
> + reg = <0x00 0x01820000 0x00 0x10000>;
> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
> + msi-controller;
> + #msi-cells = <1>;
> + };
> + };
> +
> + dmss: dmss {
> + compatible = "simple-mfd";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + dma-ranges;
> + ranges;
> +
> + secure_proxy_main: mailbox@4d000000 {
> + compatible = "ti,am654-secure-proxy";
> + #mbox-cells = <1>;
> + reg-names = "target_data", "rt", "scfg";
> + reg = <0x00 0x4d000000 0x00 0x80000>,
> + <0x00 0x4a600000 0x00 0x80000>,
> + <0x00 0x4a400000 0x00 0x80000>;
> + interrupt-names = "rx_012";
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + };
> + };
> +
> + dmsc: dmsc@44043000 {
> + compatible = "ti,k2g-sci";
> + ti,host-id = <12>;
> + mbox-names = "rx", "tx";
> + mboxes= <&secure_proxy_main 12>,
> + <&secure_proxy_main 13>;
> + reg-names = "debug_messages";
> + reg = <0x00 0x44043000 0x00 0xfe0>;
> +
> + k3_pds: power-controller {
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <2>;
> + };
> +
> + k3_clks: clocks {
> + compatible = "ti,k2g-sci-clk";
> + #clock-cells = <2>;
> + };
> +
> + k3_reset: reset-controller {
> + compatible = "ti,sci-reset";
> + #reset-cells = <2>;
> + };
> + };
> +
> + main_pmx0: pinctrl@f4000 {
> + compatible = "pinctrl-single";
> + reg = <0x00 0xf4000 0x00 0x2d0>;
Hmm, should the size be 0x2d8? I see the TRM defines a PADMMD_PADCONFIG181
register at 0xf42d4.
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0xffffffff>;
> + };
> +
> + main_conf: syscon@43000000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x00 0x43000000 0x00 0x20000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x00 0x00 0x43000000 0x20000>;
> +
> + chipid@14 {
> + compatible = "ti,am654-chipid";
> + reg = <0x00000014 0x4>;
> + };
> + };
> +
> + main_uart0: serial@2800000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02800000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 146 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart1: serial@2810000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02810000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 152 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart2: serial@2820000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02820000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 153 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart3: serial@2830000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02830000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 154 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart4: serial@2840000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02840000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 155 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart5: serial@2850000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02850000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 156 0>;
> + clock-names = "fclk";
> + };
> +
> + main_uart6: serial@2860000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x02860000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 158 0>;
> + clock-names = "fclk";
> + };
> +
> + main_i2c0: i2c@20000000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20000000 0x00 0x100>;
> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 102 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c1: i2c@20010000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20010000 0x00 0x100>;
> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 103 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c2: i2c@20020000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20020000 0x00 0x100>;
> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 104 2>;
> + clock-names = "fck";
> + };
> +
> + main_i2c3: i2c@20030000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x20030000 0x00 0x100>;
> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 105 2>;
> + clock-names = "fck";
> + };
> +
> + main_spi0: spi@20100000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x20100000 0x00 0x400>;
> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 141 0>;
> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
> + dma-names = "tx0", "rx0";
> + };
> +
> + main_spi1: spi@20110000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20110000 0x00 0x400>;
> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 142 0>;
> + };
> +
> + main_spi2: spi@20120000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20120000 0x00 0x400>;
> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 143 0>;
> + };
> +
> + main_spi3: spi@20130000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20130000 0x00 0x400>;
> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 144 0>;
> + };
> +
> + main_spi4: spi@20140000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x20140000 0x00 0x400>;
> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 145 0>;
> + };
> +
> + sdhci0: mmc@fa10000 {
> + compatible = "ti,am64-sdhci-8bit";
> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-mmc-hs = <0x0>;
> + ti,otap-del-sel-ddr52 = <0x6>;
> + ti,otap-del-sel-hs200 = <0x7>;
> + ti,otap-del-sel-hs400 = <0x4>;
> + };
> +
> + sdhci1: mmc@fa00000 {
> + compatible = "ti,am64-sdhci-4bit";
> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
> + clock-names = "clk_ahb", "clk_xin";
> + ti,trm-icp = <0x2>;
> + ti,otap-del-sel-legacy = <0x0>;
> + ti,otap-del-sel-sd-hs = <0xf>;
> + ti,otap-del-sel-sdr12 = <0xf>;
> + ti,otap-del-sel-sdr25 = <0xf>;
> + ti,otap-del-sel-sdr50 = <0xc>;
> + ti,otap-del-sel-sdr104 = <0x6>;
> + ti,otap-del-sel-ddr50 = <0x9>;
> + ti,clkbuf-sel = <0x7>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> new file mode 100644
> index 000000000000..1d2be485a669
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
> @@ -0,0 +1,76 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +&cbass_mcu {
> + mcu_uart0: serial@4a00000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a00000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 149 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_uart1: serial@4a10000 {
> + compatible = "ti,am64-uart", "ti,am654-uart";
> + reg = <0x00 0x04a10000 0x00 0x100>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
> + clock-frequency = <48000000>;
> + current-speed = <115200>;
> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 160 0>;
> + clock-names = "fclk";
> + };
> +
> + mcu_i2c0: i2c@4900000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04900000 0x00 0x100>;
> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 106 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_i2c1: i2c@4910000 {
> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
> + reg = <0x00 0x04910000 0x00 0x100>;
> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 107 2>;
> + clock-names = "fck";
> + };
> +
> + mcu_spi0: spi@4b00000 {
> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
> + reg = <0x00 0x04b00000 0x00 0x400>;
> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 147 0>;
> + };
> +
> + mcu_spi1: spi@4b10000 {
> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
> + reg = <0x00 0x04b10000 0x00 0x400>;
> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
> + clocks = <&k3_clks 148 0>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> new file mode 100644
> index 000000000000..0ae8c844c482
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
> @@ -0,0 +1,103 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC Family
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/pinctrl/k3.h>
> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
> +
> +/ {
> + model = "Texas Instruments K3 AM642 SoC";
> + compatible = "ti,am642";
> + interrupt-parent = <&gic500>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &mcu_uart0;
> + serial1 = &mcu_uart1;
> + serial2 = &main_uart0;
> + serial3 = &main_uart1;
> + serial4 = &main_uart2;
> + serial5 = &main_uart3;
> + serial6 = &main_uart4;
> + serial7 = &main_uart5;
> + serial8 = &main_uart6;
> + };
> +
> + chosen { };
> +
> + firmware {
> + optee {
> + compatible = "linaro,optee-tz";
> + method = "smc";
> + };
> +
> + psci: psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> + };
> +
> + a53_timer0: timer-cl0-cpu0 {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
> + };
> +
> + pmu: pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
> + };
> +
> + cbass_main: bus@f4000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
Follows the above..
regards
Suman
> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
> +
> + /* MCU Domain Range */
> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
> +
> + cbass_mcu: bus@4000000 {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
> + };
> + };
> +};
> +
> +/* Now include the peripherals for each bus segments */
> +#include "k3-am64-main.dtsi"
> +#include "k3-am64-mcu.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> new file mode 100644
> index 000000000000..e2b397c88401
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree Source for AM642 SoC family in Dual core configuration
> + *
> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +/dts-v1/;
> +
> +#include "k3-am64.dtsi"
> +
> +/ {
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu-map {
> + cluster0: cluster0 {
> + core0 {
> + cpu = <&cpu0>;
> + };
> +
> + core1 {
> + cpu = <&cpu1>;
> + };
> + };
> + };
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + device_type = "cpu";
> + enable-method = "psci";
> + i-cache-size = <0x8000>;
> + i-cache-line-size = <64>;
> + i-cache-sets = <256>;
> + d-cache-size = <0x8000>;
> + d-cache-line-size = <64>;
> + d-cache-sets = <128>;
> + next-level-cache = <&L2_0>;
> + };
> + };
> +
> + L2_0: l2-cache0 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x40000>;
> + cache-line-size = <64>;
> + cache-sets = <512>;
> + };
> +};
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
2021-01-25 22:48 ` Suman Anna
@ 2021-01-25 23:02 ` Suman Anna
-1 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-25 23:02 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: linux-arm-kernel, devicetree, Rob Herring, Tony Lindgren,
Vignesh Raghavendra, Sekhar Nori, Kishon Vijay Abraham,
Lokesh Vutla, Aswath Govindraju
On 1/25/21 4:48 PM, Suman Anna wrote:
> Hi Dave,
>
> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>> providing advanced system integration to enable applications such as
>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>
>> Some highlights of this SoC are:
>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>> MCUs, and a single Cortex-M4F.
>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>> * Integrated Ethernet switch supporting up to a total of two external
>> ports.
>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>> peripherals.
>> * Centralized System Controller for Security, Power, and Resource
>> Management (DMSC).
>>
>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>> for further details: https://www.ti.com/lit/pdf/spruim2
>>
>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>> under cbass_mcu.
>>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
>> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
>> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
>> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
>> 4 files changed, 576 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> new file mode 100644
>> index 000000000000..e3ef4bff04af
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> @@ -0,0 +1,332 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +&cbass_main {
>> + oc_sram: sram@70000000 {
>> + compatible = "mmio-sram";
>> + reg = <0x00 0x70000000 0x00 0x200000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x00 0x70000000 0x200000>;
>> +
>> + atf-sram@0 {
>> + reg = <0x0 0x1a000>;
>> + };
>> + };
>> +
>> + gic500: interrupt-controller@1800000 {
>> + compatible = "arm,gic-v3";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + #interrupt-cells = <3>;
>> + interrupt-controller;
>> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
>> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
>> + /*
>> + * vcpumntirq:
>> + * virtual CPU interface maintenance interrupt
>> + */
>> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + gic_its: msi-controller@1820000 {
>> + compatible = "arm,gic-v3-its";
>> + reg = <0x00 0x01820000 0x00 0x10000>;
>> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
>> + msi-controller;
>> + #msi-cells = <1>;
>> + };
>> + };
>> +
>> + dmss: dmss {
>> + compatible = "simple-mfd";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + dma-ranges;
>> + ranges;
>> +
>> + secure_proxy_main: mailbox@4d000000 {
>> + compatible = "ti,am654-secure-proxy";
>> + #mbox-cells = <1>;
>> + reg-names = "target_data", "rt", "scfg";
>> + reg = <0x00 0x4d000000 0x00 0x80000>,
>> + <0x00 0x4a600000 0x00 0x80000>,
>> + <0x00 0x4a400000 0x00 0x80000>;
>> + interrupt-names = "rx_012";
>> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> + };
>> +
>> + dmsc: dmsc@44043000 {
>> + compatible = "ti,k2g-sci";
>> + ti,host-id = <12>;
>> + mbox-names = "rx", "tx";
>> + mboxes= <&secure_proxy_main 12>,
>> + <&secure_proxy_main 13>;
>> + reg-names = "debug_messages";
>> + reg = <0x00 0x44043000 0x00 0xfe0>;
>> +
>> + k3_pds: power-controller {
>> + compatible = "ti,sci-pm-domain";
>> + #power-domain-cells = <2>;
>> + };
>> +
>> + k3_clks: clocks {
>> + compatible = "ti,k2g-sci-clk";
>> + #clock-cells = <2>;
>> + };
>> +
>> + k3_reset: reset-controller {
>> + compatible = "ti,sci-reset";
>> + #reset-cells = <2>;
>> + };
>> + };
>> +
>> + main_pmx0: pinctrl@f4000 {
>> + compatible = "pinctrl-single";
>> + reg = <0x00 0xf4000 0x00 0x2d0>;
>
> Hmm, should the size be 0x2d8? I see the TRM defines a PADMMD_PADCONFIG181
> register at 0xf42d4.
Please ignore, learnt that this is a bug in the current version of TRM.
regards
Suman
>
>> + #pinctrl-cells = <1>;
>> + pinctrl-single,register-width = <32>;
>> + pinctrl-single,function-mask = <0xffffffff>;
>> + };
>> +
>> + main_conf: syscon@43000000 {
>> + compatible = "syscon", "simple-mfd";
>> + reg = <0x00 0x43000000 0x00 0x20000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x00 0x00 0x43000000 0x20000>;
>> +
>> + chipid@14 {
>> + compatible = "ti,am654-chipid";
>> + reg = <0x00000014 0x4>;
>> + };
>> + };
>> +
>> + main_uart0: serial@2800000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02800000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 146 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart1: serial@2810000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02810000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 152 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart2: serial@2820000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02820000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 153 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart3: serial@2830000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02830000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 154 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart4: serial@2840000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02840000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 155 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart5: serial@2850000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02850000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 156 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart6: serial@2860000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02860000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 158 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_i2c0: i2c@20000000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20000000 0x00 0x100>;
>> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 102 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c1: i2c@20010000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20010000 0x00 0x100>;
>> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 103 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c2: i2c@20020000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20020000 0x00 0x100>;
>> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 104 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c3: i2c@20030000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20030000 0x00 0x100>;
>> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 105 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_spi0: spi@20100000 {
>> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
>> + reg = <0x00 0x20100000 0x00 0x400>;
>> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 141 0>;
>> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
>> + dma-names = "tx0", "rx0";
>> + };
>> +
>> + main_spi1: spi@20110000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20110000 0x00 0x400>;
>> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 142 0>;
>> + };
>> +
>> + main_spi2: spi@20120000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20120000 0x00 0x400>;
>> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 143 0>;
>> + };
>> +
>> + main_spi3: spi@20130000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20130000 0x00 0x400>;
>> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 144 0>;
>> + };
>> +
>> + main_spi4: spi@20140000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20140000 0x00 0x400>;
>> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 145 0>;
>> + };
>> +
>> + sdhci0: mmc@fa10000 {
>> + compatible = "ti,am64-sdhci-8bit";
>> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
>> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
>> + clock-names = "clk_ahb", "clk_xin";
>> + mmc-ddr-1_8v;
>> + mmc-hs200-1_8v;
>> + mmc-hs400-1_8v;
>> + ti,trm-icp = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-mmc-hs = <0x0>;
>> + ti,otap-del-sel-ddr52 = <0x6>;
>> + ti,otap-del-sel-hs200 = <0x7>;
>> + ti,otap-del-sel-hs400 = <0x4>;
>> + };
>> +
>> + sdhci1: mmc@fa00000 {
>> + compatible = "ti,am64-sdhci-4bit";
>> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
>> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
>> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
>> + clock-names = "clk_ahb", "clk_xin";
>> + ti,trm-icp = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-sd-hs = <0xf>;
>> + ti,otap-del-sel-sdr12 = <0xf>;
>> + ti,otap-del-sel-sdr25 = <0xf>;
>> + ti,otap-del-sel-sdr50 = <0xc>;
>> + ti,otap-del-sel-sdr104 = <0x6>;
>> + ti,otap-del-sel-ddr50 = <0x9>;
>> + ti,clkbuf-sel = <0x7>;
>> + };
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> new file mode 100644
>> index 000000000000..1d2be485a669
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> @@ -0,0 +1,76 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +&cbass_mcu {
>> + mcu_uart0: serial@4a00000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x04a00000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 149 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + mcu_uart1: serial@4a10000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x04a10000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 160 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + mcu_i2c0: i2c@4900000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x04900000 0x00 0x100>;
>> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 106 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + mcu_i2c1: i2c@4910000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x04910000 0x00 0x100>;
>> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 107 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + mcu_spi0: spi@4b00000 {
>> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
>> + reg = <0x00 0x04b00000 0x00 0x400>;
>> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 147 0>;
>> + };
>> +
>> + mcu_spi1: spi@4b10000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x04b10000 0x00 0x400>;
>> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 148 0>;
>> + };
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>> new file mode 100644
>> index 000000000000..0ae8c844c482
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>> @@ -0,0 +1,103 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC Family
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/k3.h>
>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>> +
>> +/ {
>> + model = "Texas Instruments K3 AM642 SoC";
>> + compatible = "ti,am642";
>> + interrupt-parent = <&gic500>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + aliases {
>> + serial0 = &mcu_uart0;
>> + serial1 = &mcu_uart1;
>> + serial2 = &main_uart0;
>> + serial3 = &main_uart1;
>> + serial4 = &main_uart2;
>> + serial5 = &main_uart3;
>> + serial6 = &main_uart4;
>> + serial7 = &main_uart5;
>> + serial8 = &main_uart6;
>> + };
>> +
>> + chosen { };
>> +
>> + firmware {
>> + optee {
>> + compatible = "linaro,optee-tz";
>> + method = "smc";
>> + };
>> +
>> + psci: psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> + };
>> + };
>> +
>> + a53_timer0: timer-cl0-cpu0 {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
>> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
>> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
>> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
>> + };
>> +
>> + pmu: pmu {
>> + compatible = "arm,cortex-a53-pmu";
>> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + cbass_main: bus@f4000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
>
> Follows the above..
>
> regards
> Suman
>
>> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
>> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
>> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
>> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
>> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
>> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
>> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
>> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
>> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
>> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
>> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
>> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
>> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
>> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
>> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
>> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
>> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
>> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
>> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>> +
>> + /* MCU Domain Range */
>> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
>> +
>> + cbass_mcu: bus@4000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
>> + };
>> + };
>> +};
>> +
>> +/* Now include the peripherals for each bus segments */
>> +#include "k3-am64-main.dtsi"
>> +#include "k3-am64-mcu.dtsi"
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>> new file mode 100644
>> index 000000000000..e2b397c88401
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>> @@ -0,0 +1,65 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC family in Dual core configuration
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k3-am64.dtsi"
>> +
>> +/ {
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu-map {
>> + cluster0: cluster0 {
>> + core0 {
>> + cpu = <&cpu0>;
>> + };
>> +
>> + core1 {
>> + cpu = <&cpu1>;
>> + };
>> + };
>> + };
>> +
>> + cpu0: cpu@0 {
>> + compatible = "arm,cortex-a53";
>> + reg = <0x000>;
>> + device_type = "cpu";
>> + enable-method = "psci";
>> + i-cache-size = <0x8000>;
>> + i-cache-line-size = <64>;
>> + i-cache-sets = <256>;
>> + d-cache-size = <0x8000>;
>> + d-cache-line-size = <64>;
>> + d-cache-sets = <128>;
>> + next-level-cache = <&L2_0>;
>> + };
>> +
>> + cpu1: cpu@1 {
>> + compatible = "arm,cortex-a53";
>> + reg = <0x001>;
>> + device_type = "cpu";
>> + enable-method = "psci";
>> + i-cache-size = <0x8000>;
>> + i-cache-line-size = <64>;
>> + i-cache-sets = <256>;
>> + d-cache-size = <0x8000>;
>> + d-cache-line-size = <64>;
>> + d-cache-sets = <128>;
>> + next-level-cache = <&L2_0>;
>> + };
>> + };
>> +
>> + L2_0: l2-cache0 {
>> + compatible = "cache";
>> + cache-level = <2>;
>> + cache-size = <0x40000>;
>> + cache-line-size = <64>;
>> + cache-sets = <512>;
>> + };
>> +};
>>
>
^ permalink raw reply [flat|nested] 50+ messages in thread* Re: [PATCH v3 3/5] arm64: dts: ti: Add support for AM642 SoC
@ 2021-01-25 23:02 ` Suman Anna
0 siblings, 0 replies; 50+ messages in thread
From: Suman Anna @ 2021-01-25 23:02 UTC (permalink / raw)
To: Dave Gerlach, Nishanth Menon
Cc: devicetree, Vignesh Raghavendra, Tony Lindgren, Sekhar Nori,
Kishon Vijay Abraham, Lokesh Vutla, Rob Herring,
Aswath Govindraju, linux-arm-kernel
On 1/25/21 4:48 PM, Suman Anna wrote:
> Hi Dave,
>
> On 1/20/21 2:25 PM, Dave Gerlach wrote:
>> The AM642 SoC belongs to the K3 Multicore SoC architecture platform,
>> providing advanced system integration to enable applications such as
>> Motor Drives, PLC, Remote IO and IoT Gateways.
>>
>> Some highlights of this SoC are:
>> * Dual Cortex-A53s in a single cluster, two clusters of dual Cortex-R5F
>> MCUs, and a single Cortex-M4F.
>> * Two Gigabit Industrial Communication Subsystems (ICSSG).
>> * Integrated Ethernet switch supporting up to a total of two external
>> ports.
>> * PCIe-GEN2x1L, USB3/USB2, 2xCAN-FD, eMMC and SD, UFS, OSPI memory
>> controller, QSPI, I2C, eCAP/eQEP, ePWM, ADC, among other
>> peripherals.
>> * Centralized System Controller for Security, Power, and Resource
>> Management (DMSC).
>>
>> See AM64X Technical Reference Manual (SPRUIM2, Nov 2020)
>> for further details: https://www.ti.com/lit/pdf/spruim2
>>
>> Introduce basic support for the AM642 SoC to enable ramdisk or MMC
>> boot. Introduce the sdhci, i2c, spi, and uart MAIN domain periperhals
>> under cbass_main and the i2c, spi, and uart MCU domain periperhals
>> under cbass_mcu.
>>
>> Signed-off-by: Faiz Abbas <faiz_abbas@ti.com>
>> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 332 +++++++++++++++++++++++
>> arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 76 ++++++
>> arch/arm64/boot/dts/ti/k3-am64.dtsi | 103 +++++++
>> arch/arm64/boot/dts/ti/k3-am642.dtsi | 65 +++++
>> 4 files changed, 576 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am64.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am642.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> new file mode 100644
>> index 000000000000..e3ef4bff04af
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
>> @@ -0,0 +1,332 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC Family Main Domain peripherals
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +&cbass_main {
>> + oc_sram: sram@70000000 {
>> + compatible = "mmio-sram";
>> + reg = <0x00 0x70000000 0x00 0x200000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x0 0x00 0x70000000 0x200000>;
>> +
>> + atf-sram@0 {
>> + reg = <0x0 0x1a000>;
>> + };
>> + };
>> +
>> + gic500: interrupt-controller@1800000 {
>> + compatible = "arm,gic-v3";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + #interrupt-cells = <3>;
>> + interrupt-controller;
>> + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
>> + <0x00 0x01840000 0x00 0xC0000>; /* GICR */
>> + /*
>> + * vcpumntirq:
>> + * virtual CPU interface maintenance interrupt
>> + */
>> + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + gic_its: msi-controller@1820000 {
>> + compatible = "arm,gic-v3-its";
>> + reg = <0x00 0x01820000 0x00 0x10000>;
>> + socionext,synquacer-pre-its = <0x1000000 0x400000>;
>> + msi-controller;
>> + #msi-cells = <1>;
>> + };
>> + };
>> +
>> + dmss: dmss {
>> + compatible = "simple-mfd";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + dma-ranges;
>> + ranges;
>> +
>> + secure_proxy_main: mailbox@4d000000 {
>> + compatible = "ti,am654-secure-proxy";
>> + #mbox-cells = <1>;
>> + reg-names = "target_data", "rt", "scfg";
>> + reg = <0x00 0x4d000000 0x00 0x80000>,
>> + <0x00 0x4a600000 0x00 0x80000>,
>> + <0x00 0x4a400000 0x00 0x80000>;
>> + interrupt-names = "rx_012";
>> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> + };
>> +
>> + dmsc: dmsc@44043000 {
>> + compatible = "ti,k2g-sci";
>> + ti,host-id = <12>;
>> + mbox-names = "rx", "tx";
>> + mboxes= <&secure_proxy_main 12>,
>> + <&secure_proxy_main 13>;
>> + reg-names = "debug_messages";
>> + reg = <0x00 0x44043000 0x00 0xfe0>;
>> +
>> + k3_pds: power-controller {
>> + compatible = "ti,sci-pm-domain";
>> + #power-domain-cells = <2>;
>> + };
>> +
>> + k3_clks: clocks {
>> + compatible = "ti,k2g-sci-clk";
>> + #clock-cells = <2>;
>> + };
>> +
>> + k3_reset: reset-controller {
>> + compatible = "ti,sci-reset";
>> + #reset-cells = <2>;
>> + };
>> + };
>> +
>> + main_pmx0: pinctrl@f4000 {
>> + compatible = "pinctrl-single";
>> + reg = <0x00 0xf4000 0x00 0x2d0>;
>
> Hmm, should the size be 0x2d8? I see the TRM defines a PADMMD_PADCONFIG181
> register at 0xf42d4.
Please ignore, learnt that this is a bug in the current version of TRM.
regards
Suman
>
>> + #pinctrl-cells = <1>;
>> + pinctrl-single,register-width = <32>;
>> + pinctrl-single,function-mask = <0xffffffff>;
>> + };
>> +
>> + main_conf: syscon@43000000 {
>> + compatible = "syscon", "simple-mfd";
>> + reg = <0x00 0x43000000 0x00 0x20000>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0x00 0x00 0x43000000 0x20000>;
>> +
>> + chipid@14 {
>> + compatible = "ti,am654-chipid";
>> + reg = <0x00000014 0x4>;
>> + };
>> + };
>> +
>> + main_uart0: serial@2800000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02800000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 146 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 146 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart1: serial@2810000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02810000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 152 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 152 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart2: serial@2820000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02820000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 153 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 153 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart3: serial@2830000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02830000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 154 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 154 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart4: serial@2840000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02840000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 155 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 155 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart5: serial@2850000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02850000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 156 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 156 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_uart6: serial@2860000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x02860000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 158 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 158 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + main_i2c0: i2c@20000000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20000000 0x00 0x100>;
>> + interrupts = <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 102 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 102 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c1: i2c@20010000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20010000 0x00 0x100>;
>> + interrupts = <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 103 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c2: i2c@20020000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20020000 0x00 0x100>;
>> + interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 104 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_i2c3: i2c@20030000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x20030000 0x00 0x100>;
>> + interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 105 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + main_spi0: spi@20100000 {
>> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
>> + reg = <0x00 0x20100000 0x00 0x400>;
>> + interrupts = <GIC_SPI 172 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 141 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 141 0>;
>> + dmas = <&main_pktdma 0xc300 0>, <&main_pktdma 0x4300 0>;
>> + dma-names = "tx0", "rx0";
>> + };
>> +
>> + main_spi1: spi@20110000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20110000 0x00 0x400>;
>> + interrupts = <GIC_SPI 173 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 142 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 142 0>;
>> + };
>> +
>> + main_spi2: spi@20120000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20120000 0x00 0x400>;
>> + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 143 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 143 0>;
>> + };
>> +
>> + main_spi3: spi@20130000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20130000 0x00 0x400>;
>> + interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 144 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 144 0>;
>> + };
>> +
>> + main_spi4: spi@20140000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x20140000 0x00 0x400>;
>> + interrupts = <GIC_SPI 175 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 145 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 145 0>;
>> + };
>> +
>> + sdhci0: mmc@fa10000 {
>> + compatible = "ti,am64-sdhci-8bit";
>> + reg = <0x00 0xfa10000 0x00 0x260>, <0x00 0xfa18000 0x00 0x134>;
>> + interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
>> + power-domains = <&k3_pds 57 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 57 0>, <&k3_clks 57 1>;
>> + clock-names = "clk_ahb", "clk_xin";
>> + mmc-ddr-1_8v;
>> + mmc-hs200-1_8v;
>> + mmc-hs400-1_8v;
>> + ti,trm-icp = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-mmc-hs = <0x0>;
>> + ti,otap-del-sel-ddr52 = <0x6>;
>> + ti,otap-del-sel-hs200 = <0x7>;
>> + ti,otap-del-sel-hs400 = <0x4>;
>> + };
>> +
>> + sdhci1: mmc@fa00000 {
>> + compatible = "ti,am64-sdhci-4bit";
>> + reg = <0x00 0xfa00000 0x00 0x260>, <0x00 0xfa08000 0x00 0x134>;
>> + interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
>> + power-domains = <&k3_pds 58 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 58 3>, <&k3_clks 58 4>;
>> + clock-names = "clk_ahb", "clk_xin";
>> + ti,trm-icp = <0x2>;
>> + ti,otap-del-sel-legacy = <0x0>;
>> + ti,otap-del-sel-sd-hs = <0xf>;
>> + ti,otap-del-sel-sdr12 = <0xf>;
>> + ti,otap-del-sel-sdr25 = <0xf>;
>> + ti,otap-del-sel-sdr50 = <0xc>;
>> + ti,otap-del-sel-sdr104 = <0x6>;
>> + ti,otap-del-sel-ddr50 = <0x9>;
>> + ti,clkbuf-sel = <0x7>;
>> + };
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> new file mode 100644
>> index 000000000000..1d2be485a669
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
>> @@ -0,0 +1,76 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM64 SoC Family MCU Domain peripherals
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +&cbass_mcu {
>> + mcu_uart0: serial@4a00000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x04a00000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 149 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 149 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + mcu_uart1: serial@4a10000 {
>> + compatible = "ti,am64-uart", "ti,am654-uart";
>> + reg = <0x00 0x04a10000 0x00 0x100>;
>> + reg-shift = <2>;
>> + reg-io-width = <4>;
>> + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>;
>> + clock-frequency = <48000000>;
>> + current-speed = <115200>;
>> + power-domains = <&k3_pds 160 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 160 0>;
>> + clock-names = "fclk";
>> + };
>> +
>> + mcu_i2c0: i2c@4900000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x04900000 0x00 0x100>;
>> + interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 106 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + mcu_i2c1: i2c@4910000 {
>> + compatible = "ti,am64-i2c", "ti,omap4-i2c";
>> + reg = <0x00 0x04910000 0x00 0x100>;
>> + interrupts = <GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 107 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 107 2>;
>> + clock-names = "fck";
>> + };
>> +
>> + mcu_spi0: spi@4b00000 {
>> + compatible = "ti,am654-mcspi", "ti,omap4-mcspi";
>> + reg = <0x00 0x04b00000 0x00 0x400>;
>> + interrupts = <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 147 0>;
>> + };
>> +
>> + mcu_spi1: spi@4b10000 {
>> + compatible = "ti,am654-mcspi","ti,omap4-mcspi";
>> + reg = <0x00 0x04b10000 0x00 0x400>;
>> + interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + power-domains = <&k3_pds 148 TI_SCI_PD_EXCLUSIVE>;
>> + clocks = <&k3_clks 148 0>;
>> + };
>> +};
>> diff --git a/arch/arm64/boot/dts/ti/k3-am64.dtsi b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>> new file mode 100644
>> index 000000000000..0ae8c844c482
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am64.dtsi
>> @@ -0,0 +1,103 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC Family
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
>> +#include <dt-bindings/pinctrl/k3.h>
>> +#include <dt-bindings/soc/ti,sci_pm_domain.h>
>> +
>> +/ {
>> + model = "Texas Instruments K3 AM642 SoC";
>> + compatible = "ti,am642";
>> + interrupt-parent = <&gic500>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + aliases {
>> + serial0 = &mcu_uart0;
>> + serial1 = &mcu_uart1;
>> + serial2 = &main_uart0;
>> + serial3 = &main_uart1;
>> + serial4 = &main_uart2;
>> + serial5 = &main_uart3;
>> + serial6 = &main_uart4;
>> + serial7 = &main_uart5;
>> + serial8 = &main_uart6;
>> + };
>> +
>> + chosen { };
>> +
>> + firmware {
>> + optee {
>> + compatible = "linaro,optee-tz";
>> + method = "smc";
>> + };
>> +
>> + psci: psci {
>> + compatible = "arm,psci-1.0";
>> + method = "smc";
>> + };
>> + };
>> +
>> + a53_timer0: timer-cl0-cpu0 {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
>> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
>> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
>> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
>> + };
>> +
>> + pmu: pmu {
>> + compatible = "arm,cortex-a53-pmu";
>> + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
>> + };
>> +
>> + cbass_main: bus@f4000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x000f4000 0x00 0x000f4000 0x00 0x000002d0>, /* PINCTRL */
>
> Follows the above..
>
> regards
> Suman
>
>> + <0x00 0x00600000 0x00 0x00600000 0x00 0x00001100>, /* GPIO */
>> + <0x00 0x00a40000 0x00 0x00a40000 0x00 0x00000800>, /* Timesync router */
>> + <0x00 0x01000000 0x00 0x01000000 0x00 0x02330400>, /* First peripheral window */
>> + <0x00 0x08000000 0x00 0x08000000 0x00 0x00200000>, /* Main CPSW */
>> + <0x00 0x0d000000 0x00 0x0d000000 0x00 0x00800000>, /* PCIE_CORE */
>> + <0x00 0x0f000000 0x00 0x0f000000 0x00 0x00c44200>, /* Second peripheral window */
>> + <0x00 0x20000000 0x00 0x20000000 0x00 0x0a008000>, /* Third peripheral window */
>> + <0x00 0x30000000 0x00 0x30000000 0x00 0x000bc100>, /* ICSSG0/1 */
>> + <0x00 0x37000000 0x00 0x37000000 0x00 0x00040000>, /* TIMERMGR0 TIMERS */
>> + <0x00 0x39000000 0x00 0x39000000 0x00 0x00000400>, /* CPTS0 */
>> + <0x00 0x3b000000 0x00 0x3b000000 0x00 0x00000400>, /* GPMC0_CFG */
>> + <0x00 0x3cd00000 0x00 0x3cd00000 0x00 0x00000200>, /* TIMERMGR0_CONFIG */
>> + <0x00 0x3f004000 0x00 0x3f004000 0x00 0x00000400>, /* GICSS0_REGS */
>> + <0x00 0x43000000 0x00 0x43000000 0x00 0x00020000>, /* CTRL_MMR0 */
>> + <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */
>> + <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMASS */
>> + <0x00 0x50000000 0x00 0x50000000 0x00 0x08000000>, /* GPMC0 DATA */
>> + <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */
>> + <0x00 0x68000000 0x00 0x68000000 0x00 0x08000000>, /* PCIe DAT0 */
>> + <0x00 0x70000000 0x00 0x70000000 0x00 0x00200000>, /* OC SRAM */
>> + <0x00 0x78000000 0x00 0x78000000 0x00 0x00800000>, /* Main R5FSS */
>> + <0x06 0x00000000 0x06 0x00000000 0x01 0x00000000>, /* PCIe DAT1 */
>> + <0x05 0x00000000 0x05 0x00000000 0x01 0x00000000>, /* FSS0 DAT3 */
>> +
>> + /* MCU Domain Range */
>> + <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>;
>> +
>> + cbass_mcu: bus@4000000 {
>> + compatible = "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x00 0x04000000 0x00 0x04000000 0x00 0x01ff1400>; /* Peripheral window */
>> + };
>> + };
>> +};
>> +
>> +/* Now include the peripherals for each bus segments */
>> +#include "k3-am64-main.dtsi"
>> +#include "k3-am64-mcu.dtsi"
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642.dtsi b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>> new file mode 100644
>> index 000000000000..e2b397c88401
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am642.dtsi
>> @@ -0,0 +1,65 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Device Tree Source for AM642 SoC family in Dual core configuration
>> + *
>> + * Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "k3-am64.dtsi"
>> +
>> +/ {
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu-map {
>> + cluster0: cluster0 {
>> + core0 {
>> + cpu = <&cpu0>;
>> + };
>> +
>> + core1 {
>> + cpu = <&cpu1>;
>> + };
>> + };
>> + };
>> +
>> + cpu0: cpu@0 {
>> + compatible = "arm,cortex-a53";
>> + reg = <0x000>;
>> + device_type = "cpu";
>> + enable-method = "psci";
>> + i-cache-size = <0x8000>;
>> + i-cache-line-size = <64>;
>> + i-cache-sets = <256>;
>> + d-cache-size = <0x8000>;
>> + d-cache-line-size = <64>;
>> + d-cache-sets = <128>;
>> + next-level-cache = <&L2_0>;
>> + };
>> +
>> + cpu1: cpu@1 {
>> + compatible = "arm,cortex-a53";
>> + reg = <0x001>;
>> + device_type = "cpu";
>> + enable-method = "psci";
>> + i-cache-size = <0x8000>;
>> + i-cache-line-size = <64>;
>> + i-cache-sets = <256>;
>> + d-cache-size = <0x8000>;
>> + d-cache-line-size = <64>;
>> + d-cache-sets = <128>;
>> + next-level-cache = <&L2_0>;
>> + };
>> + };
>> +
>> + L2_0: l2-cache0 {
>> + compatible = "cache";
>> + cache-level = <2>;
>> + cache-size = <0x40000>;
>> + cache-line-size = <64>;
>> + cache-sets = <512>;
>> + };
>> +};
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 50+ messages in thread