* [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, 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, 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, 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, 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: Rob Herring, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Vignesh R, Tero Kristo, Russell King, Sudeep Holla
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: Rob Herring, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Vignesh R, Tero Kristo, Russell King, Sudeep Holla
* 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,
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: 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, 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: [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, 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-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, 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, 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, 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, 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: Rob Herring, Santosh Shilimkar, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, open list:SERIAL DRIVERS,
linux-kernel, devicetree,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Vignesh R, Tero Kristo, Russell King, Sudeep Holla
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:40 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).