| Message ID | 20210120202532.9011-1-d-gerlach@ti.com |
|---|---|
| Headers | show |
| Series | arm64: Initial support for Texas Instruments AM642 Platform | expand |
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 :)
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>; > + }; > +}; >
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
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
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
+ 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. >
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
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
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
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
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
* 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
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