* [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC [not found] <=<20180605060125.9518-1-nm@ti.com> @ 2018-06-05 6:05 ` Nishanth Menon 2018-06-05 6:05 ` [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board Nishanth Menon 2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring 0 siblings, 2 replies; 16+ messages in thread From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw) To: Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, Rob Herring Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla, nm The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * Dual lock-step capable R5F uC for safety-critical applications * High data throughput capable distributed DMA architecture under NAVSS * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * Centralized System Controller for Security, Power, and Resource management. * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD * Flash subystem with OSPI and Hyperbus interfaces * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO See AM65x Technical Reference Manual (SPRUID7, April 2018) for further details: http://www.ti.com/lit/pdf/spruid7 We introduce the Kconfig symbol for the SoC along with this patch since it is logically relevant point, however the usage is in subsequent patches. NOTE: AM654 is the first of the device variants, hence we introduce a generic am6.dtsi. Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> --- MAINTAINERS | 1 + arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++ arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++ drivers/soc/ti/Kconfig | 14 ++++ 4 files changed, 276 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi diff --git a/MAINTAINERS b/MAINTAINERS index cfb35b252ac7..5f5c4eddec7a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M: Santosh Shilimkar <ssantosh@kernel.org> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi new file mode 100644 index 000000000000..cdfa12173aac --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,144 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC Family + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + model = "Texas Instruments K3 AM654 SoC"; + compatible = "ti,am654"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + serial4 = &main_uart2; + }; + + chosen { }; + + firmware { + optee { + compatible = "linaro,optee-tz"; + method = "smc"; + }; + + psci: psci { + compatible = "arm,psci-1.0"; + method = "smc"; + }; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + 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,armv8-pmuv3"; + /* Recommendation from GIC500 TRM Table A.3 */ + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; + + gic: interrupt-controller@1800000 { + compatible = "arm,gic-v3"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + /* + * NOTE: we are NOT gicv2 backward compat, so no GICC, + * GICH or GICV + */ + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */ + <0x0 0x01880000 0x0 0x90000>; /* GICR */ + + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt + */ + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + + gic_its: gic-its@1000000 { + compatible = "arm,gic-v3-its"; + reg = <0x0 0x1820000 0x0 0x10000>; + msi-controller; + #msi-cells = <1>; + }; + }; + + wkup_uart0: serial@42300000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x42300000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + mcu_uart0: serial@40a00000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x40a00000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <96000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart0: serial@2800000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02800000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart1: serial@2810000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02810000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart2: serial@2820000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x0 0x02820000 0x0 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + }; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi new file mode 100644 index 000000000000..d9b70081daba --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi @@ -0,0 +1,117 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC family in Quad core configuration + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include "k3-am6.dtsi" + +/ { + cpus: cpus { + #address-cells = <1>; + #size-cells = <0>; + cpu-map { + cluster0: cluster0 { + core0 { + cpu = <&cpu0>; + }; + + core1 { + cpu = <&cpu1>; + }; + }; + + cluster1: cluster1 { + core0 { + cpu = <&cpu2>; + }; + + core1 { + cpu = <&cpu3>; + }; + }; + }; + + cpu0: cpu@0 { + compatible = "arm,cortex-a53","arm,armv8"; + 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","arm,armv8"; + 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>; + }; + + cpu2: cpu@100 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x100>; + 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_1>; + }; + + cpu3: cpu@101 { + compatible = "arm,cortex-a53","arm,armv8"; + reg = <0x101>; + 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_1>; + }; + }; +}; + +&soc0 { + L2_0: l2-cache0 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + L2_1: l2-cache1 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + msmc_l3: l3-cache0 { + compatible = "cache"; + cache-level = <3>; + }; +}; diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig index 92770d84a288..be4570baad96 100644 --- a/drivers/soc/ti/Kconfig +++ b/drivers/soc/ti/Kconfig @@ -1,3 +1,17 @@ +# 64-bit ARM SoCs from TI +if ARM64 + +if ARCH_K3 + +config ARCH_K3_AM6_SOC + bool "K3 AM6 SoC" + help + Enable support for TI's AM6 SoC Family support + +endif + +endif + # # TI SOC drivers # -- 2.15.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board 2018-06-05 6:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Nishanth Menon @ 2018-06-05 6:05 ` Nishanth Menon 2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring 1 sibling, 0 replies; 16+ messages in thread From: Nishanth Menon @ 2018-06-05 6:05 UTC (permalink / raw) To: Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, Rob Herring Cc: linux-serial, linux-kernel, devicetree, linux-arm-kernel, Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla, nm The EValuation Module(EVM) platform for AM654 consists of a common Base board + one or more of daughter cards, which include: a) "Personality Modules", which can be specific to a profile, such as ICSSG enabled or Multi-media (including audio). b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2 c) Camera daughter card d) various display panels Among other options. There are two basic configurations defined which include an "EVM" configuration and "IDK" (Industrial development kit) which differ in the specific combination of daughter cards that are used. To simplify support, we choose to support just the base board as the core device tree file and all daughter cards would be expected to be device tree overlays. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> --- MAINTAINERS | 1 + arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/ti/Makefile | 9 ++++++ arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++++++++++++++++++++++ 4 files changed, 51 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/Makefile create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts diff --git a/MAINTAINERS b/MAINTAINERS index 5f5c4eddec7a..4491a0f0625f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/Makefile F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index 3543bc324553..4690364d584b 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -23,5 +23,6 @@ subdir-y += rockchip subdir-y += socionext subdir-y += sprd subdir-y += synaptics +subdir-y += ti subdir-y += xilinx subdir-y += zte diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile new file mode 100644 index 000000000000..63e619d0b5b8 --- /dev/null +++ b/arch/arm64/boot/dts/ti/Makefile @@ -0,0 +1,9 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Make file to build device tree binaries for boards based on +# Texas Instruments Inc processors +# +# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ +# + +dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts new file mode 100644 index 000000000000..d227d792de60 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts @@ -0,0 +1,40 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +/dts-v1/; + +#include "k3-am654.dtsi" + +/ { + compatible = "ti,am654-evm", "ti,am654"; + model = "Texas Instruments AM654 Base Board"; + + chosen { + stdout-path = "serial2:115200n8"; + bootargs = "earlycon=ns16550a,mmio32,0x02800000"; + }; + + memory@80000000 { + device_type = "memory"; + /* 4G RAM */ + reg = <0x00000000 0x80000000 0x00000000 0x80000000>, + <0x00000008 0x80000000 0x00000000 0x80000000>; + }; + + reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + secure_ddr: secure_ddr@9e800000 { + reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */ + alignment = <0x1000>; + no-map; + }; + }; +}; + +&main_uart0 { + status = "okay"; +}; -- 2.15.1 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-05 6:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Nishanth Menon 2018-06-05 6:05 ` [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board Nishanth Menon @ 2018-06-05 14:05 ` Rob Herring 2018-06-05 14:14 ` Tony Lindgren ` (2 more replies) 1 sibling, 3 replies; 16+ messages in thread From: Rob Herring @ 2018-06-05 14:05 UTC (permalink / raw) To: Nishanth Menon Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote: > The AM654 SoC is a lead device of the K3 Multicore SoC architecture > platform, targeted for broad market and industrial control with aim to > meet the complex processing needs of modern embedded products. > > Some highlights of this SoC are: > * Quad ARMv8 A53 cores split over two clusters > * GICv3 compliant GIC500 > * Configurable L3 Cache and IO-coherent architecture > * Dual lock-step capable R5F uC for safety-critical applications > * High data throughput capable distributed DMA architecture under NAVSS > * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual > PRUs and dual RTUs > * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL > * Centralized System Controller for Security, Power, and Resource > management. > * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD > * Flash subystem with OSPI and Hyperbus interfaces > * Multimedia capability with CAL, DSS7-UL, SGX544, McASP > * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, > GPIO > > See AM65x Technical Reference Manual (SPRUID7, April 2018) > for further details: http://www.ti.com/lit/pdf/spruid7 > > We introduce the Kconfig symbol for the SoC along with this patch since > it is logically relevant point, however the usage is in subsequent > patches. > > NOTE: AM654 is the first of the device variants, hence we introduce a > generic am6.dtsi. > > Signed-off-by: Benjamin Fair <b-fair@ti.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > MAINTAINERS | 1 + > arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++ > arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++ > drivers/soc/ti/Kconfig | 14 ++++ > 4 files changed, 276 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi > create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index cfb35b252ac7..5f5c4eddec7a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> > L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) > S: Supported > F: Documentation/devicetree/bindings/arm/ti/k3.txt > +F: arch/arm64/boot/dts/ti/k3-* > > ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE > M: Santosh Shilimkar <ssantosh@kernel.org> > diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi > new file mode 100644 > index 000000000000..cdfa12173aac > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi > @@ -0,0 +1,144 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Device Tree Source for AM6 SoC Family > + * > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ > + */ > + > +#include <dt-bindings/gpio/gpio.h> > +#include <dt-bindings/interrupt-controller/irq.h> > +#include <dt-bindings/interrupt-controller/arm-gic.h> > + > +/ { > + model = "Texas Instruments K3 AM654 SoC"; > + compatible = "ti,am654"; > + interrupt-parent = <&gic>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + aliases { > + serial0 = &wkup_uart0; > + serial1 = &mcu_uart0; > + serial2 = &main_uart0; > + serial3 = &main_uart1; > + serial4 = &main_uart2; > + }; > + > + chosen { }; > + > + firmware { > + optee { > + compatible = "linaro,optee-tz"; > + method = "smc"; > + }; > + > + psci: psci { > + compatible = "arm,psci-1.0"; > + method = "smc"; > + }; > + }; > + > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; Really need 64-bit addresses and sizes? Use ranges to limit the address space if possible. > + > + 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,armv8-pmuv3"; > + /* Recommendation from GIC500 TRM Table A.3 */ > + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; > + }; These 2 nodes aren't on the bus, so move them up a level. > + > + gic: interrupt-controller@1800000 { > + compatible = "arm,gic-v3"; gic-500? > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + #interrupt-cells = <3>; > + interrupt-controller; > + /* > + * NOTE: we are NOT gicv2 backward compat, so no GICC, > + * GICH or GICV The compatible should imply this. > + */ > + reg = <0x0 0x01800000 0x0 0x10000>, /* GICD */ > + <0x0 0x01880000 0x0 0x90000>; /* GICR */ > + > + /* > + * vcpumntirq: > + * virtual CPU interface maintenance interrupt > + */ > + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; > + > + gic_its: gic-its@1000000 { > + compatible = "arm,gic-v3-its"; > + reg = <0x0 0x1820000 0x0 0x10000>; > + msi-controller; > + #msi-cells = <1>; > + }; > + }; > + > + wkup_uart0: serial@42300000 { > + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; > + reg = <0x0 0x42300000 0x0 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <48000000>; > + current-speed = <115200>; > + status = "disabled"; > + }; > + > + mcu_uart0: serial@40a00000 { > + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; > + reg = <0x0 0x40a00000 0x0 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <96000000>; > + current-speed = <115200>; > + status = "disabled"; > + }; > + > + main_uart0: serial@2800000 { > + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; > + reg = <0x0 0x02800000 0x0 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <48000000>; > + current-speed = <115200>; > + status = "disabled"; > + }; > + > + main_uart1: serial@2810000 { > + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; > + reg = <0x0 0x02810000 0x0 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <48000000>; > + current-speed = <115200>; > + status = "disabled"; > + }; > + > + main_uart2: serial@2820000 { > + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; > + reg = <0x0 0x02820000 0x0 0x100>; > + reg-shift = <2>; > + reg-io-width = <4>; > + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; > + clock-frequency = <48000000>; > + current-speed = <115200>; > + status = "disabled"; > + }; > + }; > +}; > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi > new file mode 100644 > index 000000000000..d9b70081daba > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi > @@ -0,0 +1,117 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Device Tree Source for AM6 SoC family in Quad core configuration > + * > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ > + */ > + > +#include "k3-am6.dtsi" > + > +/ { > + cpus: cpus { Really need a label? > + #address-cells = <1>; > + #size-cells = <0>; > + cpu-map { IIRC, this goes at the top level. > + cluster0: cluster0 { > + core0 { > + cpu = <&cpu0>; > + }; > + > + core1 { > + cpu = <&cpu1>; > + }; > + }; > + > + cluster1: cluster1 { > + core0 { > + cpu = <&cpu2>; > + }; > + > + core1 { > + cpu = <&cpu3>; > + }; > + }; > + }; > + > + cpu0: cpu@0 { > + compatible = "arm,cortex-a53","arm,armv8"; space between compatibles. > + 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>; All this should be discoverable. > + next-level-cache = <&L2_0>; > + }; > + > + cpu1: cpu@1 { > + compatible = "arm,cortex-a53","arm,armv8"; > + 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>; > + }; > + > + cpu2: cpu@100 { > + compatible = "arm,cortex-a53","arm,armv8"; > + reg = <0x100>; > + 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_1>; > + }; > + > + cpu3: cpu@101 { > + compatible = "arm,cortex-a53","arm,armv8"; > + reg = <0x101>; > + 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_1>; > + }; > + }; > +}; > + > +&soc0 { > + L2_0: l2-cache0 { > + compatible = "cache"; Is this documented? > + cache-level = <2>; > + cache-size = <0x80000>; > + cache-line-size = <64>; > + cache-sets = <512>; Discoverable? > + next-level-cache = <&msmc_l3>; > + }; > + > + L2_1: l2-cache1 { > + compatible = "cache"; > + cache-level = <2>; > + cache-size = <0x80000>; > + cache-line-size = <64>; > + cache-sets = <512>; > + next-level-cache = <&msmc_l3>; > + }; > + > + msmc_l3: l3-cache0 { > + compatible = "cache"; Is this something TI specific or follows the (ARM) architecture? > + cache-level = <3>; > + }; > +}; > diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig > index 92770d84a288..be4570baad96 100644 > --- a/drivers/soc/ti/Kconfig > +++ b/drivers/soc/ti/Kconfig > @@ -1,3 +1,17 @@ > +# 64-bit ARM SoCs from TI > +if ARM64 > + > +if ARCH_K3 > + > +config ARCH_K3_AM6_SOC This should be in another patch (or dropped?). > + bool "K3 AM6 SoC" > + help > + Enable support for TI's AM6 SoC Family support > + > +endif > + > +endif > + > # > # TI SOC drivers > # > -- > 2.15.1 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring @ 2018-06-05 14:14 ` Tony Lindgren 2018-06-07 23:38 ` Nishanth Menon 2018-08-08 6:31 ` Kishon Vijay Abraham I 2 siblings, 0 replies; 16+ messages in thread From: Tony Lindgren @ 2018-06-05 14:14 UTC (permalink / raw) To: Rob Herring Cc: Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla * Rob Herring <robh+dt@kernel.org> [180605 14:08]: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. And in addition to using ranges, please set up separate bus instances for the interconnects. This will then allow you to probe WKUP or similar instance first and the other bus instances after. And that pretty much allows you to get rid of the annoying -EPROBE_DEFER ping pong and allows making clocks proper device drivers ;) Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring 2018-06-05 14:14 ` Tony Lindgren @ 2018-06-07 23:38 ` Nishanth Menon 2018-06-14 12:38 ` Tony Lindgren 2018-08-08 6:31 ` Kishon Vijay Abraham I 2 siblings, 1 reply; 16+ messages in thread From: Nishanth Menon @ 2018-06-07 23:38 UTC (permalink / raw) To: Rob Herring Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla On 14:05-20180605, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote: [...] > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. Done -> overall the addresses are really in the 64bit addresses, but used bus segments and ranges to reduce to 32bit maps where possible. OSPI, PCIE, FSS (Flash subsystem) , CPTS are some of the ones that probably will need some level of cleanups when those are introduced later. Unfortunately, there is a lot of interleaved addressing between bus segments themselves, I have tried to keep the ranges as clean as reasonably possible. I also tried to use 1-1 map for children nodes to maintain some level of sanity as we add more device nodes. There might be a few exceptions, but overall the ranges currently map 1-1 physical 32bit address - OSPI, CPTS, FSS will however have to have a different mapping. See [1] > > > + > > + 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,armv8-pmuv3"; > > + /* Recommendation from GIC500 TRM Table A.3 */ > > + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; > > + }; > > These 2 nodes aren't on the bus, so move them up a level. Thanks. oversight on my end. I have fixed it (see [1]) > > > + > > + gic: interrupt-controller@1800000 { > > + compatible = "arm,gic-v3"; > > gic-500? Yes, GIC500. > > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > + #interrupt-cells = <3>; > > + interrupt-controller; > > + /* > > + * NOTE: we are NOT gicv2 backward compat, so no GICC, > > + * GICH or GICV > > The compatible should imply this. GIC500 at SoC design instantiation takes a parameter "are_option" -> this is set to no-compatibility for V2 for AM6. This is indeed discovered by the driver, However, Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt just notes that GICC, GICH, GICV as optional.. With backward compatibility disabled, these are'nt even present. I have dropped the comment, was helpful for me when I was first adding support for GIC500, It is pretty common knowledge now for other ARMV8 developers, so no point in retaining newbie info as comment. [...] > > diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > new file mode 100644 > > index 000000000000..d9b70081daba > > --- /dev/null > > +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi > > @@ -0,0 +1,117 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Device Tree Source for AM6 SoC family in Quad core configuration > > + * > > + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ > > + */ > > + > > +#include "k3-am6.dtsi" > > + > > +/ { > > + cpus: cpus { > > Really need a label? Thanks. Dropped. > > > + #address-cells = <1>; > > + #size-cells = <0>; > > + cpu-map { > > IIRC, this goes at the top level. Documentation/devicetree/bindings/arm/topology.txt States to keep in cpus node. Quote: | The ARM CPU topology is defined within the cpu-map node, which is a direct | child of the cpus node and provides a container where the actual topology | nodes are listed. Retained as is to stay in sync with binding. > > + cpu0: cpu@0 { > > + compatible = "arm,cortex-a53","arm,armv8"; > > space between compatibles. Oops. Fixed. thanks. > > > + 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>; > > All this should be discoverable. Unfortunately no. Previously CCSIDR_EL1 was a good place to lookup this data. But as Sudeep pointed me offline: commit a8d4636f96ad ("arm64: cacheinfo: Remove CCSIDR-based cache information probing") and commit 9a802431c527 ("arm64: cacheinfo: add support to override cache levels via device tree") had already provided options to override cache information from the device tree. This is what I am using. Quote from commit: The architecture explicitly states: | You cannot make any inference about the actual sizes of caches based | on these parameters. [...] > > + > > +&soc0 { > > + L2_0: l2-cache0 { > > + compatible = "cache"; > > Is this documented? Just what Documentation/devicetree/bindings/arm/cpu-capacity.txt states as an example. We dont seem to have anything similar to Documentation/devicetree/bindings/arm/l2c2x0.txt in armv8 as per the comments in the document at least. > > > + cache-level = <2>; > > + cache-size = <0x80000>; > > + cache-line-size = <64>; > > + cache-sets = <512>; > > Discoverable? Same comment as L1 cache details. > > > + next-level-cache = <&msmc_l3>; > > + }; > > + > > + L2_1: l2-cache1 { > > + compatible = "cache"; > > + cache-level = <2>; > > + cache-size = <0x80000>; > > + cache-line-size = <64>; > > + cache-sets = <512>; > > + next-level-cache = <&msmc_l3>; > > + }; > > + > > + msmc_l3: l3-cache0 { > > + compatible = "cache"; > > Is this something TI specific or follows the (ARM) architecture? ARM Architecture permits an L3 Cache. TI implements it differently (we dont use CCI), instead an L3 Cache is always active in our implementation - backing memory is configurable and is designed to be completely transparent to s/w running on ARMv8. Description here is to meet the hardware description of cache topology to be accurate. [...] > > diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig > > index 92770d84a288..be4570baad96 100644 > > --- a/drivers/soc/ti/Kconfig > > +++ b/drivers/soc/ti/Kconfig > > @@ -1,3 +1,17 @@ > > +# 64-bit ARM SoCs from TI > > +if ARM64 > > + > > +if ARCH_K3 > > + > > +config ARCH_K3_AM6_SOC > > This should be in another patch (or dropped?). Agreed and split off into another patch. [1] Here is how the patch looks now (after incorporating changes suggested by Tony as well) - Thoughts please: https://github.com/nmenon/linux-2.6-playground/tree/upstream/next-20180604/k3-5-defconfig/arch/arm64/boot/dts/ti has everything consolidated. 8<-- >From 88857a8241fc67d63021e5c9070092b11398d11f Mon Sep 17 00:00:00 2001 From: Nishanth Menon <nm@ti.com> Date: Wed, 14 Sep 2016 19:12:42 -0500 Subject: [RFC V2 PATCH] arm64: dts: ti: Add Support for AM654 SoC The AM654 SoC is a lead device of the K3 Multicore SoC architecture platform, targeted for broad market and industrial control with aim to meet the complex processing needs of modern embedded products. Some highlights of this SoC are: * Quad ARMv8 A53 cores split over two clusters * GICv3 compliant GIC500 * Configurable L3 Cache and IO-coherent architecture * Dual lock-step capable R5F uC for safety-critical applications * High data throughput capable distributed DMA architecture under NAVSS * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual PRUs and dual RTUs * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL * Centralized System Controller for Security, Power, and Resource management. * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD * Flash subystem with OSPI and Hyperbus interfaces * Multimedia capability with CAL, DSS7-UL, SGX544, McASP * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, GPIO See AM65x Technical Reference Manual (SPRUID7, April 2018) for further details: http://www.ti.com/lit/pdf/spruid7 We introduce the Kconfig symbol for the SoC along with this patch since it is logically relevant point, however the usage is in subsequent patches. NOTE: AM654 is the first of the device variants, hence we introduce a generic am6.dtsi. Signed-off-by: Benjamin Fair <b-fair@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> --- MAINTAINERS | 1 + arch/arm64/boot/dts/ti/k3-am6.dtsi | 172 +++++++++++++++++++++++++++++++++++ arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++ 3 files changed, 290 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi diff --git a/MAINTAINERS b/MAINTAINERS index cfb35b252ac7..5f5c4eddec7a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Supported F: Documentation/devicetree/bindings/arm/ti/k3.txt +F: arch/arm64/boot/dts/ti/k3-* ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE M: Santosh Shilimkar <ssantosh@kernel.org> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi new file mode 100644 index 000000000000..700c56eda12d --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi @@ -0,0 +1,172 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC Family + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include <dt-bindings/gpio/gpio.h> +#include <dt-bindings/interrupt-controller/irq.h> +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + model = "Texas Instruments K3 AM654 SoC"; + compatible = "ti,am654"; + interrupt-parent = <&gic500>; + #address-cells = <2>; + #size-cells = <2>; + + aliases { + serial0 = &wkup_uart0; + serial1 = &mcu_uart0; + serial2 = &main_uart0; + serial3 = &main_uart1; + serial4 = &main_uart2; + }; + + 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,armv8-pmuv3"; + /* Recommendation from GIC500 TRM Table A.3 */ + interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>; + }; + + soc0: soc0 { + compatible = "simple-bus"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + main_domain: cbass@100000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */ + <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */ + <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */ + <0x01000000 0x00 0x01000000 0x0AF02400>, /* Most peripherals */ + <0x30800000 0x00 0x30800000 0x0BC00000>; /* MAIN NAVSS */ + + gic500: interrupt-controller@1800000 { + compatible = "arm,gic-v3"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x01800000 0x10000>, /* GICD */ + <0x01880000 0x90000>; /* GICR */ + + /* + * vcpumntirq: + * virtual CPU interface maintenance interrupt + */ + interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>; + + gic_its: gic-its@18200000 { + compatible = "arm,gic-v3-its"; + reg = <0x01820000 0x10000>; + msi-controller; + #msi-cells = <1>; + }; + }; + + main_uart0: serial@2800000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x02800000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 192 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart1: serial@2810000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x02810000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + main_uart2: serial@2820000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x02820000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + }; + + wkup_domain: cbass@42040000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x42040000 0x00 0x42040000 0x03AC2400>; /* Basic peripherals */ + + wkup_uart0: serial@42300000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x42300000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 697 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <48000000>; + current-speed = <115200>; + status = "disabled"; + }; + + }; + + mcu_domain: cbass@28380000 { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x28380000 0x00 0x28380000 0x03880000>, /* MCU NAVSS*/ + <0x40200000 0x00 0x40200000 0x00900100>, /* First peripheral window */ + <0x45100000 0x00 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */ + <0x46000000 0x00 0x46000000 0x00200000>, /* CPSW */ + <0x47000000 0x00 0x47000000 0x00068400>; /* OSPI space 1 */ + + mcu_uart0: serial@40a00000 { + compatible = "ti,am654-uart", "ti,omap4-uart", "ns16550a"; + reg = <0x40a00000 0x100>; + reg-shift = <2>; + reg-io-width = <4>; + interrupts = <GIC_SPI 565 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <96000000>; + current-speed = <115200>; + status = "disabled"; + }; + + }; + + }; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi new file mode 100644 index 000000000000..bffa414180ea --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi @@ -0,0 +1,117 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Device Tree Source for AM6 SoC family in Quad core configuration + * + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#include "k3-am6.dtsi" + +/ { + cpus { + #address-cells = <1>; + #size-cells = <0>; + cpu-map { + cluster0: cluster0 { + core0 { + cpu = <&cpu0>; + }; + + core1 { + cpu = <&cpu1>; + }; + }; + + cluster1: cluster1 { + core0 { + cpu = <&cpu2>; + }; + + core1 { + cpu = <&cpu3>; + }; + }; + }; + + cpu0: cpu@0 { + compatible = "arm,cortex-a53", "arm,armv8"; + 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", "arm,armv8"; + 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>; + }; + + cpu2: cpu@100 { + compatible = "arm,cortex-a53", "arm,armv8"; + reg = <0x100>; + 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_1>; + }; + + cpu3: cpu@101 { + compatible = "arm,cortex-a53", "arm,armv8"; + reg = <0x101>; + 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_1>; + }; + }; +}; + +&soc0 { + L2_0: l2-cache0 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + L2_1: l2-cache1 { + compatible = "cache"; + cache-level = <2>; + cache-size = <0x80000>; + cache-line-size = <64>; + cache-sets = <512>; + next-level-cache = <&msmc_l3>; + }; + + msmc_l3: l3-cache0 { + compatible = "cache"; + cache-level = <3>; + }; +}; -- 2.15.1 -- Regards, Nishanth Menon ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-07 23:38 ` Nishanth Menon @ 2018-06-14 12:38 ` Tony Lindgren 2018-06-14 13:04 ` Nishanth Menon 0 siblings, 1 reply; 16+ messages in thread From: Tony Lindgren @ 2018-06-14 12:38 UTC (permalink / raw) To: Nishanth Menon Cc: Rob Herring, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla Hi, Some comments on the ranges below. * Nishanth Menon <nm@ti.com> [180607 16:41]: > + soc0: soc0 { > + compatible = "simple-bus"; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; I suggest you leave out the soc0, that's not real. Just make the cbass@0 the top level interconnect. It can then provide ranges to mcu interconnect which can provide ranges to the wkup interconnect. So just model it after what's in the hardware :) I found the following ranges based on a quick look at the TRM, they could be split further if needed for power domains for genpd for example. main covers 0x0000000000 - 0x5402000000 main provides at least the following ranges for mcu 0x0028380000 - 0x002bc00000 0x0040080000 - 0x0041c80000 0x0045100000 - 0x0045180000 0x0045600000 - 0x0045640000 0x0045810000 - 0x0045860000 0x0045950000 - 0x0045950400 0x0045a50000 - 0x0045a50400 0x0045b04000 - 0x0045b06400 0x0045d10000 - 0x0045d24000 0x0046000000 - 0x0060000000 0x0400000000 - 0x0800000000 0x4c3c020000 - 0x4c3c030000 0x4c3e000000 - 0x4c3e040000 0x5400000000 - 0x5402000000 then mcu provides the following ranges for wkup 0x0042000000 - 0x0044410020 0x0045000000 - 0x0045030000 0x0045080000 - 0x00450a0000 0x0045808000 - 0x0045808800 0x0045b00000 - 0x0045b02400 This based on looking at "figure 1-1. device top-level block diagram" and the memory map in TRM. Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-14 12:38 ` Tony Lindgren @ 2018-06-14 13:04 ` Nishanth Menon 2018-06-15 5:01 ` Tony Lindgren 0 siblings, 1 reply; 16+ messages in thread From: Nishanth Menon @ 2018-06-14 13:04 UTC (permalink / raw) To: Tony Lindgren Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel@vger.kernel.org, Russell King, Tero Kristo, Rob Herring, open list:SERIAL DRIVERS, Greg Kroah-Hartman, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE On 12:38-20180614, Tony Lindgren wrote: > Some comments on the ranges below. Thanks for reviewing in detail (I understand we are in the middle of merge window, so thanks for the extra effort). > > * Nishanth Menon <nm@ti.com> [180607 16:41]: > > + soc0: soc0 { > > + compatible = "simple-bus"; > > + #address-cells = <2>; > > + #size-cells = <2>; > > + ranges; > > I suggest you leave out the soc0, that's not real. Just make Why is that so, on a more complex board representation with multiple SoCs, this is a clear node indicating what the main SoC is in the final dtb representation. > the cbass@0 the top level interconnect. It can then provide > ranges to mcu interconnect which can provide ranges to the wkup > interconnect. So just model it after what's in the hardware :) That might blow up things quite a bit - it is like the comment in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 The trees are pretty deep with many interconnections (example main does have direct connections to wkup as well, which is simplified off in top level diagram) - basically it is not a direct one dimensional relationship. But then, the same is the case for other SoCs.. we can represent NAVSS as a bus segment as well. > > I found the following ranges based on a quick look at the TRM, > they could be split further if needed for power domains for > genpd for example. genpd is not really an issue, since it is handled in system firmware and OSes dont have a visibility into the permitted ranges that the OS is allowed to use. I think it is just how accurate a representation is it worth. > > main covers > 0x0000000000 - 0x5402000000 > > main provides at least the following ranges for mcu > 0x0028380000 - 0x002bc00000 > 0x0040080000 - 0x0041c80000 > 0x0045100000 - 0x0045180000 > 0x0045600000 - 0x0045640000 > 0x0045810000 - 0x0045860000 > 0x0045950000 - 0x0045950400 > 0x0045a50000 - 0x0045a50400 > 0x0045b04000 - 0x0045b06400 > 0x0045d10000 - 0x0045d24000 > 0x0046000000 - 0x0060000000 > 0x0400000000 - 0x0800000000 > 0x4c3c020000 - 0x4c3c030000 > 0x4c3e000000 - 0x4c3e040000 > 0x5400000000 - 0x5402000000 > > then mcu provides the following ranges for wkup > 0x0042000000 - 0x0044410020 > 0x0045000000 - 0x0045030000 > 0x0045080000 - 0x00450a0000 > 0x0045808000 - 0x0045808800 > 0x0045b00000 - 0x0045b02400 > > This based on looking at "figure 1-1. device top-level > block diagram" and the memory map in TRM. Thanks for researching. I did debate something like: >From A53 view, a more accurate view might be - from an interconnect view of the world (still simplified - i have ignored the sub bus segments in the representations below): msmc { navss_main { cbass_main{ cbass_mcu { navss_mcu { }; cbass_wkup{ }; }; }; }; }; >From R5 view, the view will be very different ofcourse: view of the world (still simplified): cbass_mcu { navss_mcu { }; cbass_wkup{ }; cbass_main{ navss_main { msmc { }; }; }; }; Do we really need this level of representation, I am not sure I had seen this detailed a representation in other aarch64 SoCs (I am sure they are as complex as TI SoCs as well). I am trying to understand the direction and logic why we'd want to have such a detailed representation. A more flatter representation of just the main segments allow for dts reuse between r5 and a53 as well (but that is minor). Thoughts? -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-14 13:04 ` Nishanth Menon @ 2018-06-15 5:01 ` Tony Lindgren 2018-06-15 13:38 ` Sekhar Nori 0 siblings, 1 reply; 16+ messages in thread From: Tony Lindgren @ 2018-06-15 5:01 UTC (permalink / raw) To: Nishanth Menon Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel@vger.kernel.org, Russell King, Tero Kristo, Rob Herring, open list:SERIAL DRIVERS, Greg Kroah-Hartman, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE * Nishanth Menon <nm@ti.com> [180614 13:07]: > On 12:38-20180614, Tony Lindgren wrote: > > Some comments on the ranges below. > > Thanks for reviewing in detail (I understand we are in the middle of > merge window, so thanks for the extra effort). > > > > > * Nishanth Menon <nm@ti.com> [180607 16:41]: > > > + soc0: soc0 { > > > + compatible = "simple-bus"; > > > + #address-cells = <2>; > > > + #size-cells = <2>; > > > + ranges; > > > > I suggest you leave out the soc0, that's not real. Just make > > Why is that so, on a more complex board representation with multiple > SoCs, this is a clear node indicating what the main SoC is in the final > dtb representation. It does not have a real reg or range. > > the cbass@0 the top level interconnect. It can then provide > > ranges to mcu interconnect which can provide ranges to the wkup > > interconnect. So just model it after what's in the hardware :) > > That might blow up things quite a bit - it is like the comment in: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/dra7.dtsi#n141 That comment at the link above not true I've found. What we have there as "ocp" should be just "l3" and then the "l4" instances are children of "l3". The direct ports from some "l4" devices are just ranges at the parent "l3". And this will get changed slowly over next few merge cycles. > The trees are pretty deep with many interconnections (example main does > have direct connections to wkup as well, which is simplified off in > top level diagram) - basically it is not a direct one dimensional > relationship. But then, the same is the case for other SoCs.. In the above example the connection from main to wkup is just a range provided by main so not a problem. > we can represent NAVSS as a bus segment as well. Well ideally each module on the interconnects would be set up separately to prevent drivers trying to ioremap ranges from multiple modules. This is important as flushing posted write to one module will not flush it for the other module. > > I found the following ranges based on a quick look at the TRM, > > they could be split further if needed for power domains for > > genpd for example. > > genpd is not really an issue, since it is handled in system firmware and > OSes dont have a visibility into the permitted ranges that the OS is > allowed to use. There are other reasons beyond genpd too. Flushing posted writes to modules is one. Getting rid of pointless deferred probe is another one. Preventing device drivers trying to ioremap multiple module is yet another one.. > I think it is just how accurate a representation is it worth. The dts really is intended to describe the hardware :) So let's not repeat the same mistake again with imaginary ranges. > > > > main covers > > 0x0000000000 - 0x5402000000 > > > > main provides at least the following ranges for mcu > > 0x0028380000 - 0x002bc00000 > > 0x0040080000 - 0x0041c80000 > > 0x0045100000 - 0x0045180000 > > 0x0045600000 - 0x0045640000 > > 0x0045810000 - 0x0045860000 > > 0x0045950000 - 0x0045950400 > > 0x0045a50000 - 0x0045a50400 > > 0x0045b04000 - 0x0045b06400 > > 0x0045d10000 - 0x0045d24000 > > 0x0046000000 - 0x0060000000 > > 0x0400000000 - 0x0800000000 > > 0x4c3c020000 - 0x4c3c030000 > > 0x4c3e000000 - 0x4c3e040000 > > 0x5400000000 - 0x5402000000 > > > > then mcu provides the following ranges for wkup > > 0x0042000000 - 0x0044410020 > > 0x0045000000 - 0x0045030000 > > 0x0045080000 - 0x00450a0000 > > 0x0045808000 - 0x0045808800 > > 0x0045b00000 - 0x0045b02400 > > > > This based on looking at "figure 1-1. device top-level > > block diagram" and the memory map in TRM. > > Thanks for researching. I did debate something like: > > From A53 view, a more accurate view might be - from an interconnect > view of the world (still simplified - i have ignored the sub bus > segments in the representations below): > > msmc { > navss_main { > cbass_main{ > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > }; > }; > }; > }; > > From R5 view, the view will be very different ofcourse: > view of the world (still simplified): > > cbass_mcu { > navss_mcu { > }; > cbass_wkup{ > }; > cbass_main{ > navss_main { > msmc { > }; > }; > }; > }; Well if we follow the hardware representation of the interconnects, it should not matter from which processor view you're looking at things. There are just different ranges provided. > Do we really need this level of representation, I am not sure I had seen > this detailed a representation in other aarch64 SoCs (I am sure they are > as complex as TI SoCs as well). Based on my experience yes. See also the reasons I listed above. > I am trying to understand the direction and logic why we'd want to have > such a detailed representation. > > A more flatter representation of just the main segments allow for dts > reuse between r5 and a53 as well (but that is minor). Just model it based on the hardware, then there's no need to debate it or rework it later on :) Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-15 5:01 ` Tony Lindgren @ 2018-06-15 13:38 ` Sekhar Nori 2018-08-20 14:21 ` Tony Lindgren 0 siblings, 1 reply; 16+ messages in thread From: Sekhar Nori @ 2018-06-15 13:38 UTC (permalink / raw) To: Tony Lindgren, Nishanth Menon Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel@vger.kernel.org, Russell King, Tero Kristo, Rob Herring, open list:SERIAL DRIVERS, Greg Kroah-Hartman, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE Hi Tony, On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote: > * Nishanth Menon <nm@ti.com> [180614 13:07]: >> On 12:38-20180614, Tony Lindgren wrote: >> From A53 view, a more accurate view might be - from an interconnect >> view of the world (still simplified - i have ignored the sub bus >> segments in the representations below): >> >> msmc { >> navss_main { >> cbass_main{ >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> }; >> }; >> }; >> }; >> >> From R5 view, the view will be very different ofcourse: >> view of the world (still simplified): >> >> cbass_mcu { >> navss_mcu { >> }; >> cbass_wkup{ >> }; >> cbass_main{ >> navss_main { >> msmc { >> }; >> }; >> }; >> }; > > Well if we follow the hardware representation of the interconnects, > it should not matter from which processor view you're looking at things. > There are just different ranges provided. AFAIK, the root node needs to have the CPU which is using the DT. So, the hierarchy will change based on CPU view (if we describe it fully). How well we can reuse individual interconnect segments is something I have to think about / experiment. Will have to be wary of any "short paths" or "cross connections". Thanks, Sekhar ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-15 13:38 ` Sekhar Nori @ 2018-08-20 14:21 ` Tony Lindgren 0 siblings, 0 replies; 16+ messages in thread From: Tony Lindgren @ 2018-08-20 14:21 UTC (permalink / raw) To: Sekhar Nori Cc: Nishanth Menon, Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel@vger.kernel.org, Russell King, Tero Kristo, Rob Herring, open list:SERIAL DRIVERS, Greg Kroah-Hartman, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE * Sekhar Nori <nsekhar@ti.com> [180615 13:41]: > > How well we can reuse individual interconnect segments is something I > have to think about / experiment. Will have to be wary of any "short > paths" or "cross connections". These short paths and cross connections are almost certainly just additional ranges from the parent interconnect. See for example what we have in Linux next for wdt3 in omap4.dtsi for separate ranges for L4 and L3 interconnects. Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring 2018-06-05 14:14 ` Tony Lindgren 2018-06-07 23:38 ` Nishanth Menon @ 2018-08-08 6:31 ` Kishon Vijay Abraham I 2018-08-20 14:31 ` Tony Lindgren 2 siblings, 1 reply; 16+ messages in thread From: Kishon Vijay Abraham I @ 2018-08-08 6:31 UTC (permalink / raw) To: Rob Herring, Nishanth Menon Cc: Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Tony Lindgren, Vignesh R, Tero Kristo, Russell King, Sudeep Holla Hi Rob, On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <nm@ti.com> wrote: >> The AM654 SoC is a lead device of the K3 Multicore SoC architecture >> platform, targeted for broad market and industrial control with aim to >> meet the complex processing needs of modern embedded products. >> >> Some highlights of this SoC are: >> * Quad ARMv8 A53 cores split over two clusters >> * GICv3 compliant GIC500 >> * Configurable L3 Cache and IO-coherent architecture >> * Dual lock-step capable R5F uC for safety-critical applications >> * High data throughput capable distributed DMA architecture under NAVSS >> * Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual >> PRUs and dual RTUs >> * Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL >> * Centralized System Controller for Security, Power, and Resource >> management. >> * Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD >> * Flash subystem with OSPI and Hyperbus interfaces >> * Multimedia capability with CAL, DSS7-UL, SGX544, McASP >> * Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI, >> GPIO >> >> See AM65x Technical Reference Manual (SPRUID7, April 2018) >> for further details: http://www.ti.com/lit/pdf/spruid7 >> >> We introduce the Kconfig symbol for the SoC along with this patch since >> it is logically relevant point, however the usage is in subsequent >> patches. >> >> NOTE: AM654 is the first of the device variants, hence we introduce a >> generic am6.dtsi. >> >> Signed-off-by: Benjamin Fair <b-fair@ti.com> >> Signed-off-by: Nishanth Menon <nm@ti.com> >> --- >> MAINTAINERS | 1 + >> arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++++++++++++++++ >> arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 ++++++++++++++++++++++++++++ >> drivers/soc/ti/Kconfig | 14 ++++ >> 4 files changed, 276 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi >> create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index cfb35b252ac7..5f5c4eddec7a 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -2092,6 +2092,7 @@ M: Nishanth Menon <nm@ti.com> >> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) >> S: Supported >> F: Documentation/devicetree/bindings/arm/ti/k3.txt >> +F: arch/arm64/boot/dts/ti/k3-* >> >> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE >> M: Santosh Shilimkar <ssantosh@kernel.org> >> diff --git a/arch/arm64/boot/dts/ti/k3-am6.dtsi b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> new file mode 100644 >> index 000000000000..cdfa12173aac >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am6.dtsi >> @@ -0,0 +1,144 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Device Tree Source for AM6 SoC Family >> + * >> + * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/ >> + */ >> + >> +#include <dt-bindings/gpio/gpio.h> >> +#include <dt-bindings/interrupt-controller/irq.h> >> +#include <dt-bindings/interrupt-controller/arm-gic.h> >> + >> +/ { >> + model = "Texas Instruments K3 AM654 SoC"; >> + compatible = "ti,am654"; >> + interrupt-parent = <&gic>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + aliases { >> + serial0 = &wkup_uart0; >> + serial1 = &mcu_uart0; >> + serial2 = &main_uart0; >> + serial3 = &main_uart1; >> + serial4 = &main_uart2; >> + }; >> + >> + chosen { }; >> + >> + firmware { >> + optee { >> + compatible = "linaro,optee-tz"; >> + method = "smc"; >> + }; >> + >> + psci: psci { >> + compatible = "arm,psci-1.0"; >> + method = "smc"; >> + }; >> + }; >> + >> + soc0: soc0 { >> + compatible = "simple-bus"; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; > > Really need 64-bit addresses and sizes? Use ranges to limit the > address space if possible. We now have address-cells as <1>, https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 However each PCIe instance has 2 data regions and one of the regions (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) is above the 32bit region and requires 2 cells to specify the start address. This region is used to access MEM_SPACE of PCIe endpoint when operating in root complex mode and access memory of PCI root complex when operating in endpoint mode. In order to describe this, should we change the address-cells back to <2> or do you suggest any other alternatives? Thanks Kishon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-08-08 6:31 ` Kishon Vijay Abraham I @ 2018-08-20 14:31 ` Tony Lindgren 2018-08-27 3:02 ` Kishon Vijay Abraham I 0 siblings, 1 reply; 16+ messages in thread From: Tony Lindgren @ 2018-08-20 14:31 UTC (permalink / raw) To: Kishon Vijay Abraham I Cc: Rob Herring, Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: > On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > Really need 64-bit addresses and sizes? Use ranges to limit the > > address space if possible. > > We now have address-cells as <1>, > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > However each PCIe instance has 2 data regions and one of the regions > (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified > in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) > is above the 32bit region and requires 2 cells to specify the start address. > This region is used to access MEM_SPACE of PCIe endpoint when operating in root > complex mode and access memory of PCI root complex when operating in endpoint mode. > > In order to describe this, should we change the address-cells back to <2> or do > you suggest any other alternatives? It's probably best to have the top level cbass interconnect use #size-cells = <2> and then have it's child interconnects have #size-cells = <1> if they don't need ranges above 4GB. BTW, what's the difference between all these three similar PCIE ranges? PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-08-20 14:31 ` Tony Lindgren @ 2018-08-27 3:02 ` Kishon Vijay Abraham I 2018-08-27 15:55 ` Tony Lindgren 0 siblings, 1 reply; 16+ messages in thread From: Kishon Vijay Abraham I @ 2018-08-27 3:02 UTC (permalink / raw) To: Tony Lindgren Cc: Rob Herring, Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla Hi Tony, On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>> Really need 64-bit addresses and sizes? Use ranges to limit the >>> address space if possible. >> >> We now have address-cells as <1>, >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >> >> However each PCIe instance has 2 data regions and one of the regions >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified >> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) >> is above the 32bit region and requires 2 cells to specify the start address. >> This region is used to access MEM_SPACE of PCIe endpoint when operating in root >> complex mode and access memory of PCI root complex when operating in endpoint mode. >> >> In order to describe this, should we change the address-cells back to <2> or do >> you suggest any other alternatives? > > It's probably best to have the top level cbass interconnect use > #size-cells = <2> and then have it's child interconnects have > #size-cells = <1> if they don't need ranges above 4GB. PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address cells and 2 size cells to describe this no? > > BTW, what's the difference between all these three similar PCIE > ranges? > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB This is the register space for the two instances of PCIe controller. > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB The above are regions which can be used by CPU/DMA to access the PCIe address space. The mapping from the above regions to the PCIe address space will be programmed in the PCIe controller. Thanks Kishon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-08-27 3:02 ` Kishon Vijay Abraham I @ 2018-08-27 15:55 ` Tony Lindgren 2018-08-28 1:22 ` Nishanth Menon 0 siblings, 1 reply; 16+ messages in thread From: Tony Lindgren @ 2018-08-27 15:55 UTC (permalink / raw) To: Kishon Vijay Abraham I Cc: Rob Herring, Nishanth Menon, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla * Kishon Vijay Abraham I <kishon@ti.com> [180827 03:06]: > Hi Tony, > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > >>> address space if possible. > >> > >> We now have address-cells as <1>, > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > >> > >> However each PCIe instance has 2 data regions and one of the regions > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified > >> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) > >> is above the 32bit region and requires 2 cells to specify the start address. > >> This region is used to access MEM_SPACE of PCIe endpoint when operating in root > >> complex mode and access memory of PCI root complex when operating in endpoint mode. > >> > >> In order to describe this, should we change the address-cells back to <2> or do > >> you suggest any other alternatives? > > > > It's probably best to have the top level cbass interconnect use > > #size-cells = <2> and then have it's child interconnects have > > #size-cells = <1> if they don't need ranges above 4GB. > > PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address > cells and 2 size cells to describe this no? Yes. > > BTW, what's the difference between all these three similar PCIE > > ranges? > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB > > This is the register space for the two instances of PCIe controller. > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB > > The above are regions which can be used by CPU/DMA to access the PCIe address > space. The mapping from the above regions to the PCIe address space will be > programmed in the PCIe controller. OK so not just somethng for dma-ranges but also accessible by the CPU. Regards, Tony ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-08-27 15:55 ` Tony Lindgren @ 2018-08-28 1:22 ` Nishanth Menon 2018-08-28 3:39 ` Kishon Vijay Abraham I 0 siblings, 1 reply; 16+ messages in thread From: Nishanth Menon @ 2018-08-28 1:22 UTC (permalink / raw) To: Tony Lindgren Cc: Kishon Vijay Abraham I, Rob Herring, Santosh Shilimkar, Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS, linux-kernel@vger.kernel.org, devicetree, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Vignesh R, Tero Kristo, Russell King, Sudeep Holla On 15:55-20180827, Tony Lindgren wrote: > * Kishon Vijay Abraham I <kishon@ti.com> [180827 03:06]: > > Hi Tony, > > > > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: > > > * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: > > >> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: > > >>> Really need 64-bit addresses and sizes? Use ranges to limit the > > >>> address space if possible. > > >> > > >> We now have address-cells as <1>, > > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 > > >> > > >> However each PCIe instance has 2 data regions and one of the regions > > >> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified > > >> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) > > >> is above the 32bit region and requires 2 cells to specify the start address. > > >> This region is used to access MEM_SPACE of PCIe endpoint when operating in root > > >> complex mode and access memory of PCI root complex when operating in endpoint mode. > > >> > > >> In order to describe this, should we change the address-cells back to <2> or do > > >> you suggest any other alternatives? > > > > > > It's probably best to have the top level cbass interconnect use > > > #size-cells = <2> and then have it's child interconnects have > > > #size-cells = <1> if they don't need ranges above 4GB. > > > > PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address > > cells and 2 size cells to describe this no? > > Yes. > > > > BTW, what's the difference between all these three similar PCIE > > > ranges? > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB > > > > This is the register space for the two instances of PCIe controller. > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB > > > > > > PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB > > > PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB > > > > The above are regions which can be used by CPU/DMA to access the PCIe address > > space. The mapping from the above regions to the PCIe address space will be > > programmed in the PCIe controller. > > OK so not just somethng for dma-ranges but also accessible by > the CPU. > Kishon, Sekhar: Can you guys post patches based on v4.19-rc1 for fixing this? I do have a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the changes. -- Regards, Nishanth Menon ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC 2018-08-28 1:22 ` Nishanth Menon @ 2018-08-28 3:39 ` Kishon Vijay Abraham I 0 siblings, 0 replies; 16+ messages in thread From: Kishon Vijay Abraham I @ 2018-08-28 3:39 UTC (permalink / raw) To: Nishanth Menon, Tony Lindgren Cc: Mark Rutland, devicetree, Sudeep Holla, Vignesh R, Catalin Marinas, Santosh Shilimkar, Will Deacon, linux-kernel@vger.kernel.org, Russell King, Tero Kristo, Rob Herring, open list:SERIAL DRIVERS, Greg Kroah-Hartman, moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE Hi, On Tuesday 28 August 2018 06:52 AM, Nishanth Menon wrote: > On 15:55-20180827, Tony Lindgren wrote: >> * Kishon Vijay Abraham I <kishon@ti.com> [180827 03:06]: >>> Hi Tony, >>> >>> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote: >>>> * Kishon Vijay Abraham I <kishon@ti.com> [180808 06:35]: >>>>> On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote: >>>>>> Really need 64-bit addresses and sizes? Use ranges to limit the >>>>>> address space if possible. >>>>> >>>>> We now have address-cells as <1>, >>>>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/ti/k3-am65.dtsi#n49 >>>>> >>>>> However each PCIe instance has 2 data regions and one of the regions >>>>> (PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1/PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 specified >>>>> in the "MAIN Domain Memory Map" table of TRM http://www.ti.com/lit/pdf/spruid7) >>>>> is above the 32bit region and requires 2 cells to specify the start address. >>>>> This region is used to access MEM_SPACE of PCIe endpoint when operating in root >>>>> complex mode and access memory of PCI root complex when operating in endpoint mode. >>>>> >>>>> In order to describe this, should we change the address-cells back to <2> or do >>>>> you suggest any other alternatives? >>>> >>>> It's probably best to have the top level cbass interconnect use >>>> #size-cells = <2> and then have it's child interconnects have >>>> #size-cells = <1> if they don't need ranges above 4GB. >>> >>> PCIe has a region starting at 0x40_00000000 and size 4GB. We need 2 address >>> cells and 2 size cells to describe this no? >> >> Yes. >> >>>> BTW, what's the difference between all these three similar PCIE >>>> ranges? >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005500000 0x0005600000 1 MB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_CORE 0x0005600000 0x0005700000 1 MB >>> >>> This is the register space for the two instances of PCIe controller. >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0010000000 0x0018000000 128 MB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT0 0x0018000000 0x0020000000 128 MB >>>> >>>> PCIE0_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4000000000 0x4100000000 4 GB >>>> PCIE1_CORE_CORE_DAT_SLV_PCIE_DAT1 0x4100000000 0x4200000000 4 GB >>> >>> The above are regions which can be used by CPU/DMA to access the PCIe address >>> space. The mapping from the above regions to the PCIe address space will be >>> programmed in the PCIe controller. >> >> OK so not just somethng for dma-ranges but also accessible by >> the CPU. >> > > Kishon, Sekhar: > > Can you guys post patches based on v4.19-rc1 for fixing this? I do have > a bunch of dts nodes to build as well for v4.20, once Tony / Rob acks the > changes. Sure, I'll post that today. Thanks Kishon ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-08-28 3:39 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <=<20180605060125.9518-1-nm@ti.com>
2018-06-05 6:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Nishanth Menon
2018-06-05 6:05 ` [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board Nishanth Menon
2018-06-05 14:05 ` [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC Rob Herring
2018-06-05 14:14 ` Tony Lindgren
2018-06-07 23:38 ` Nishanth Menon
2018-06-14 12:38 ` Tony Lindgren
2018-06-14 13:04 ` Nishanth Menon
2018-06-15 5:01 ` Tony Lindgren
2018-06-15 13:38 ` Sekhar Nori
2018-08-20 14:21 ` Tony Lindgren
2018-08-08 6:31 ` Kishon Vijay Abraham I
2018-08-20 14:31 ` Tony Lindgren
2018-08-27 3:02 ` Kishon Vijay Abraham I
2018-08-27 15:55 ` Tony Lindgren
2018-08-28 1:22 ` Nishanth Menon
2018-08-28 3:39 ` Kishon Vijay Abraham I
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).