Messages in this thread | | | Subject | Re: [PATCH 3/4] arm64: dts: ti: Add support for J7200 SoC | From | Suman Anna <> | Date | Tue, 28 Jul 2020 14:50:23 -0500 |
| |
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 <lokeshvutla@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
| |