LinuxLists.cc - [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform

2018-06-05 06:03:39

Subject: [RFC PATCH 0/6] arm64: Initial support Texas Instrument's AM654 Platform

Hi,

The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.

The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The series (part 1 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-1-am6-base

Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/

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.

The Linux development follows closely the 66AK2G SoC model in aarch64.

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Lokesh Vutla (1):
serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3

Nishanth Menon (5):
Documentation: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
serial: 8250_omap: Add support for AM654 UART controller
arm64: dts: ti: Add Support for AM654 SoC
arm64: dts: ti: Add support for AM654 EVM base board

Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++
.../devicetree/bindings/serial/omap_serial.txt | 1 +
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am6.dtsi | 144 +++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 40 ++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 117 +++++++++++++++++
drivers/soc/ti/Kconfig | 14 ++
drivers/tty/serial/8250/8250_omap.c | 1 +
drivers/tty/serial/8250/Kconfig | 2 +-
12 files changed, 377 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am6.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi

--
2.15.1

2018-06-05 06:03:14

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

AM654 uses a UART controller that is compatible (partially) with
existing 8250 UART, however, has a few differences with respect to DMA
support and control paths. Introduce a base definition that allows us
to build up the differences in follow on patches.

Cc: Sekhar Nori <[email protected]>
Cc: Vignesh R <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
drivers/tty/serial/8250/8250_omap.c | 1 +
2 files changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 4b0f05adb228..c35d5ece1156 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -1,6 +1,7 @@
OMAP UART controller

Required properties:
+- compatible : should be "ti,am654-uart" for AM654 controllers
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers
diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 1b337fee07ed..a019286f8bb6 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;

static const struct of_device_id omap8250_dt_ids[] = {
+ { .compatible = "ti,am654-uart" },
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart", .data = &omap4_habit, },
--
2.15.1

2018-06-05 06:03:53

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

2018-06-05 06:04:16

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 2/6] arm64: Add support for TI's K3 Multicore SoC architecture

Add support for Texas Instrument's K3 Multicore SoC architecture
processors.

Signed-off-by: Nishanth Menon <[email protected]>
---
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.

+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1

2018-06-05 06:04:16

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 4/6] serial: 8250_omap: Make 8250_omap driver driver depend on ARCH_K3

From: Lokesh Vutla <[email protected]>

Allow 8250 omap serial driver to be used for K3 platforms.

Signed-off-by: Lokesh Vutla <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
drivers/tty/serial/8250/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index f005eaf8bc57..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -375,7 +375,7 @@ config SERIAL_8250_RT288X

config SERIAL_8250_OMAP
tristate "Support for OMAP internal UART (8250 based driver)"
- depends on SERIAL_8250 && ARCH_OMAP2PLUS
+ depends on SERIAL_8250 && (ARCH_OMAP2PLUS || ARCH_K3)
help
If you have a machine based on an Texas Instruments OMAP CPU you
can enable its onboard serial ports by enabling this option.
--
2.15.1

2018-06-05 06:06:22

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 6/6] arm64: dts: ti: Add support for AM654 EVM base board

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 <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
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 <[email protected]>
L: [email protected] (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

2018-06-05 06:06:31

by Nishanth Menon

[permalink] [raw]

Subject: [RFC PATCH 5/6] 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 <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
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 <[email protected]>
L: [email protected] (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 <[email protected]>
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

2018-06-05 14:06:59

by Rob Herring

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <[email protected]> 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 <[email protected]>
> Signed-off-by: Nishanth Menon <[email protected]>
> ---
> 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 <[email protected]>
> L: [email protected] (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 <[email protected]>
> 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
>

2018-06-05 14:16:15

by Tony Lindgren

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

* Rob Herring <[email protected]> [180605 14:08]:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <[email protected]> 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

2018-06-07 23:41:15

by Nishanth Menon

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

On 14:05-20180605, Rob Herring wrote:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <[email protected]> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Nishanth Menon <[email protected]>
---
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 <[email protected]>
L: [email protected] (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 <[email protected]>
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

2018-06-12 21:07:12

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon 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
>
> Signed-off-by: Nishanth Menon <[email protected]>
> ---
> Documentation/devicetree/bindings/arm/ti/k3.txt | 33 +++++++++++++++++++++++++
> MAINTAINERS | 7 ++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
> new file mode 100644
> index 000000000000..cbabb1b89f6f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
> @@ -0,0 +1,33 @@
> +Texas Instruments K3 Multicore SoC architecture device tree bindings
> +--------------------------------------------------------------------
> +
> +Boards based on K3 Multicore SoC architecture shall have the following property:
> +- compatible: Every hardware block introduced in K3 Multicore SoC
> + architecture shall be of the form:
> + "ti,XXX-YYY", where:
> + 'XXX' represents the specific SoC part for which the support is added.
> + 'YYY' represents the corresponding peripheral in SoC being supported.

No need to explain standard DT convention here. (But I don't think we
have this convention documented anywhere, so patches welcome. :))

> +
> + NOTE: Generic devices such as GIC or legacy devices shall use the specified
> + compatible for those devices.
> +
> + Example:
> + compatible = "ti,am654-i2c";
> +
> +SoCs
> +-------------------------------------------
> +
> +Each device tree root node must specify which exact SoC in K3 Multicore SoC
> +architecture it uses, using one of the following compatible values:
> +
> +- AM654
> + compatible = "ti,am654";
> +
> +Boards
> +-------------------------------------------
> +
> +In addition, each device tree root node must specify which one or more
> +of the following board-specific compatible values:
> +
> +- AM654 EVM
> + compatible = "ti,am654-evm", "ti,am654";
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f39a8de1bbd7..cfb35b252ac7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2086,6 +2086,13 @@ L: [email protected]
> S: Maintained
> F: drivers/memory/*emif*
>
> +ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
> +M: Tero Kristo <[email protected]>
> +M: Nishanth Menon <[email protected]>
> +L: [email protected] (moderated for non-subscribers)
> +S: Supported
> +F: Documentation/devicetree/bindings/arm/ti/k3.txt
> +
> ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
> M: Santosh Shilimkar <[email protected]>
> L: [email protected] (moderated for non-subscribers)
> --
> 2.15.1
>

2018-06-12 21:07:28

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
> AM654 uses a UART controller that is compatible (partially) with
> existing 8250 UART, however, has a few differences with respect to DMA
> support and control paths. Introduce a base definition that allows us
> to build up the differences in follow on patches.
>
> Cc: Sekhar Nori <[email protected]>
> Cc: Vignesh R <[email protected]>
> Signed-off-by: Nishanth Menon <[email protected]>
> ---
> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
> drivers/tty/serial/8250/8250_omap.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index 4b0f05adb228..c35d5ece1156 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -1,6 +1,7 @@
> OMAP UART controller
>
> Required properties:
> +- compatible : should be "ti,am654-uart" for AM654 controllers

Not compatible with any existing TI 8250 UARTs?

> - compatible : should be "ti,omap2-uart" for OMAP2 controllers
> - compatible : should be "ti,omap3-uart" for OMAP3 controllers
> - compatible : should be "ti,omap4-uart" for OMAP4 controllers
> diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
> index 1b337fee07ed..a019286f8bb6 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1115,6 +1115,7 @@ static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
> static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
>
> static const struct of_device_id omap8250_dt_ids[] = {
> + { .compatible = "ti,am654-uart" },
> { .compatible = "ti,omap2-uart" },
> { .compatible = "ti,omap3-uart" },
> { .compatible = "ti,omap4-uart", .data = &omap4_habit, },
> --
> 2.15.1
>

2018-06-12 22:02:33

by Nishanth Menon

[permalink] [raw]

Subject: Re: [RFC PATCH 1/6] Documentation: arm: ti: Add bindings for AM654 SoC

On 21:05-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:20AM -0500, Nishanth Menon wrote:
[...]
> > +Boards based on K3 Multicore SoC architecture shall have the following property:
> > +- compatible: Every hardware block introduced in K3 Multicore SoC
> > + architecture shall be of the form:
> > + "ti,XXX-YYY", where:
> > + 'XXX' represents the specific SoC part for which the support is added.
> > + 'YYY' represents the corresponding peripheral in SoC being supported.
>
> No need to explain standard DT convention here. (But I don't think we
> have this convention documented anywhere, so patches welcome. :))
>

Thanks. Will drop off from my series (will skip the generic dts
convention for now ;) ).
--
Regards,
Nishanth Menon

2018-06-12 22:05:14

by Nishanth Menon

[permalink] [raw]

Subject: Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

On 21:06-20180612, Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > index 4b0f05adb228..c35d5ece1156 100644
> > --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> > +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> > @@ -1,6 +1,7 @@
> > OMAP UART controller
> >
> > Required properties:
> > +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?

Base is compatible, however there are differences in DMA operation and
few additional bits. omap4-uart is sufficient for a basic PIO mode of
operation given initialization a bootloader might do for base console.

I will split the bindings off into it's own patch to keep the confusion
to a minimum and allowing serial driver change to go in independently.

--
Regards,
Nishanth Menon

2018-06-14 12:40:01

by Tony Lindgren

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

Hi,

Some comments on the ranges below.

* Nishanth Menon <[email protected]> [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

2018-06-14 13:06:39

by Nishanth Menon

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

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 <[email protected]> [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

2018-06-15 05:10:44

by Tony Lindgren

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

* Nishanth Menon <[email protected]> [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 <[email protected]> [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

2018-06-15 13:39:35

by Sekhar Nori

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

Hi Tony,

On Friday 15 June 2018 10:31 AM, Tony Lindgren wrote:
> * Nishanth Menon <[email protected]> [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

2018-06-15 17:19:07

by Sekhar Nori

[permalink] [raw]

Subject: Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

Hi Rob,

On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>> AM654 uses a UART controller that is compatible (partially) with
>> existing 8250 UART, however, has a few differences with respect to DMA
>> support and control paths. Introduce a base definition that allows us
>> to build up the differences in follow on patches.
>>
>> Cc: Sekhar Nori <[email protected]>
>> Cc: Vignesh R <[email protected]>
>> Signed-off-by: Nishanth Menon <[email protected]>
>> ---
>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>> drivers/tty/serial/8250/8250_omap.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> index 4b0f05adb228..c35d5ece1156 100644
>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> @@ -1,6 +1,7 @@
>> OMAP UART controller
>>
>> Required properties:
>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>
> Not compatible with any existing TI 8250 UARTs?

Curious on why you asked about this. Are you suggesting why not:

"ti,<new-soc>-uart", "ti,<old-soc>-uart"

or you are asking why introduce "ti,<new-soc>-uart" unless there is
clear demonstrable need for using it in driver code.

In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
device-tree (and by extension in binding document) is better even in
there are no _known_ incompatibilities at the time of initial driver
submission. The reason is silicon integration and process differences
many times spill over into driver.

Of course, the idea is not to go postal and create a new compatible for
every pin-compatible part number that gets created, but probably a new
compatible should be created for a new silicon die.

We have just started introducing support for this SoC, and since it
reuses many IPs, this question is likely to come up again.

In this particular case though, Nishanth is perfectly right in not saying

compatible : should be "ti,am654-uart", "ti,omap4-uart"

Because we *know* UART DMA integration is different and a match against
omap4 would result in non-working UART once DMA is enabled by default.

Thanks,
Sekhar

2018-06-15 21:57:12

by Rob Herring (Arm)

[permalink] [raw]

Subject: Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

On Fri, Jun 15, 2018 at 11:17 AM, Sekhar Nori <[email protected]> wrote:
> Hi Rob,
>
> On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
>> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>>> AM654 uses a UART controller that is compatible (partially) with
>>> existing 8250 UART, however, has a few differences with respect to DMA
>>> support and control paths. Introduce a base definition that allows us
>>> to build up the differences in follow on patches.
>>>
>>> Cc: Sekhar Nori <[email protected]>
>>> Cc: Vignesh R <[email protected]>
>>> Signed-off-by: Nishanth Menon <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>> drivers/tty/serial/8250/8250_omap.c | 1 +
>>> 2 files changed, 2 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> index 4b0f05adb228..c35d5ece1156 100644
>>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>>> @@ -1,6 +1,7 @@
>>> OMAP UART controller
>>>
>>> Required properties:
>>> +- compatible : should be "ti,am654-uart" for AM654 controllers
>>
>> Not compatible with any existing TI 8250 UARTs?
>
> Curious on why you asked about this. Are you suggesting why not:
>
> "ti,<new-soc>-uart", "ti,<old-soc>-uart"

Correct.

> or you are asking why introduce "ti,<new-soc>-uart" unless there is
> clear demonstrable need for using it in driver code.
>
> In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
> device-tree (and by extension in binding document) is better even in
> there are no _known_ incompatibilities at the time of initial driver
> submission. The reason is silicon integration and process differences
> many times spill over into driver.

Yes, and chip designers can't be trusted. ;)

> Of course, the idea is not to go postal and create a new compatible for
> every pin-compatible part number that gets created, but probably a new
> compatible should be created for a new silicon die.

Yes, that's the criteria I would use too. That's sometimes hard if
it's not the chip vendor doing the DT bindings.

> We have just started introducing support for this SoC, and since it
> reuses many IPs, this question is likely to come up again.
>
> In this particular case though, Nishanth is perfectly right in not saying
>
> compatible : should be "ti,am654-uart", "ti,omap4-uart"
>
> Because we *know* UART DMA integration is different and a match against
> omap4 would result in non-working UART once DMA is enabled by default.

Okay, makes sense. I'd suggest rewording the commit message to include
this. The "compatible to 8250 except for DMA" part I would have
applied to all TI UARTs rather than DMA differences with other TI
UARTs.

Rob

2018-08-08 06:33:38

by Kishon Vijay Abraham I

[permalink] [raw]

Subject: Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

Hi Rob,

On Tuesday 05 June 2018 07:35 PM, Rob Herring wrote:
> On Tue, Jun 5, 2018 at 1:05 AM, Nishanth Menon <[email protected]> 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 <[email protected]>
>> Signed-off-by: Nishanth Menon <[email protected]>
>> ---
>> 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 <[email protected]>
>> L: [email protected] (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 <[email protected]>
>> 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

2018-08-20 14:25:29

by Tony Lindgren

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

* Sekhar Nori <[email protected]> [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

2018-08-20 14:34:30

by Tony Lindgren

[permalink] [raw]

Subject: Re: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

* Kishon Vijay Abraham I <[email protected]> [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

2018-08-27 03:05:41

by Kishon Vijay Abraham I

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

Hi Tony,

On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <[email protected]> [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

2018-08-27 15:57:29

by Tony Lindgren

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

* Kishon Vijay Abraham I <[email protected]> [180827 03:06]:
> Hi Tony,
>
> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote:
> > * Kishon Vijay Abraham I <[email protected]> [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

2018-08-28 01:24:18

by Nishanth Menon

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

On 15:55-20180827, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <[email protected]> [180827 03:06]:
> > Hi Tony,
> >
> > On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote:
> > > * Kishon Vijay Abraham I <[email protected]> [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

2018-08-28 03:41:55

by Kishon Vijay Abraham I

[permalink] [raw]

Subject: Re: [RFC PATCH 5/6] arm64: dts: ti: Add Support for AM654 SoC

Hi,

On Tuesday 28 August 2018 06:52 AM, Nishanth Menon wrote:
> On 15:55-20180827, Tony Lindgren wrote:
>> * Kishon Vijay Abraham I <[email protected]> [180827 03:06]:
>>> Hi Tony,
>>>
>>> On Monday 20 August 2018 08:01 PM, Tony Lindgren wrote:
>>>> * Kishon Vijay Abraham I <[email protected]> [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