Re: [PATCH 3/4] arm64: dts: ti: Add support for J7200 SoC

[Suman Anna]

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@xxxxxx>
> > ---
> > Â 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