Hi Grygorii,
On 7/28/20 2:16 PM, Grygorii Strashko wrote:
On 23/07/2020 11:46, Lokesh Vutla wrote:
The J7200 SoC is a part of the K3 Multicore SoC architecture platform.
It is targeted for automotive gateway, vehicle compute systems,
Vehicle-to-Vehicle (V2V) and Vehicle-to-Everything (V2X) applications.
The SoC aims to meet the complex processing needs of modern embedded
products.
Some highlights of this SoC are:
* Dual Cortex-A72s in a single cluster, two clusters of lockstep
capable dual Cortex-R5F MCUs and a Centralized Device Management and
Security Controller (DMSC).
* Configurable L3 Cache and IO-coherent architecture with high data
throughput capable distributed DMA architecture under NAVSS.
* Integrated Ethernet switch supporting up to a total of 4 external ports
in addition to legacy Ethernet switch of up to 2 ports.
* Upto 1 PCIe-GEN3 controller, 1 USB3.0 Dual-role device subsystems,
20 MCANs, 3 McASP, eMMC and SD, OSPI/HyperBus memory controller, I3C
and I2C, eCAP/eQEP, eHRPWM among other peripherals.
* One hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
management.
See J7200 Technical Reference Manual (SPRUIU1, June 2020)
for further details: https://www.ti.com/lit/pdf/spruiu1
Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
---
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 199 ++++++++++++++++++
.../boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 84 ++++++++
arch/arm64/boot/dts/ti/k3-j7200.dtsi | 165 +++++++++++++++
3 files changed, 448 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-j7200.dtsi
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
new file mode 100644
index 000000000000..70c8f7e941fb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for J7200 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2020 Texas Instruments Incorporated -
https://www.ti.com/
+ */
+
+&cbass_main {
+ msmc_ram: sram@70000000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x70000000 0x0 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x70000000 0x100000>;
+
+ atf-sram@0 {
+ reg = <0x0 0x20000>;
+ };
+ };
+
+ gic500: interrupt-controller@1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
+ <0x00 0x01900000 0x00 0x100000>; /* GICR */
+
+ /* vcpumntirq: virtual CPU interface maintenance interrupt */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: msi-controller@1820000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x00 0x01820000 0x00 0x10000>;
+ socionext,synquacer-pre-its = <0x1000000 0x400000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ main_navss: navss@30000000 {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0x00 0x30000000 0x00 0x30000000 0x00 0x0c400000>;
Can we return back
ti,sci-dev-id = <199>;
here? it's needed for DMA PSI-L pairing.
Oh, I wasn't aware of this. Lokesh removed it based on my earlier
comments. Is this used by more than one driver? Anytime you see a
ti,sci-dev-id, you would also expect to see the ti,sci reference in
general for that driver to really leverage it.
The lack of a specific binding for this node also makes one think it is
not needed.
Option: add it as part of dma/net submission.
Yeah, I think we should go with this approach on upstream if we aren't
respinning the series. Any reason, this couldn't be added to the udma
node itself?
regards
Suman
