| Message ID | 20220819190054.31348-1-a-nandan@ti.com |
|---|---|
| Headers | show |
| Series | Add initial support for J784s4 SoC | expand |
On 19/08/2022 22:00, Apurva Nandan wrote: > The J784S4 SoC belongs to the K3 Multicore SoC architecture platform, > providing advanced system integration in automotive ADAS applications > and industrial applications requiring AI at the network edge. This SoC > extends the Jacinto 7 family of SoCs with focus on high performance > providing significant levels of processing power, graphics capability, > video and imaging processing, virtualization and coherent memory > support. > > Some highlights of this SoC are: Thank you for your patch. There is something to discuss/improve. > + > + main_gpio_intr: interrupt-controller@a00000 { > + compatible = "ti,sci-intr"; > + reg = <0x00 0x00a00000 0x00 0x800>; 0x0, not 0x00. Here and all other places. > + ti,intr-trigger-type = <1>; > + interrupt-controller; > + interrupt-parent = <&gic500>; > + #interrupt-cells = <1>; > + ti,sci = <&sms>; > + ti,sci-dev-id = <10>; > + ti,interrupt-ranges = <8 360 56>; > + }; > + > + main_pmx0: pinctrl@11c000 { > + compatible = "pinctrl-single"; > + /* Proxy 0 addressing */ > + reg = <0x0 0x11c000 0x0 0x120>; > + #pinctrl-cells = <1>; > + pinctrl-single,register-width = <32>; > + pinctrl-single,function-mask = <0xffffffff>; > + }; > + (...) > + > + main_udmass_inta: msi-controller@33d00000 { > + compatible = "ti,sci-inta"; > + reg = <0x00 0x33d00000 0x00 0x100000>; > + interrupt-controller; > + #interrupt-cells = <0>; > + interrupt-parent = <&main_navss_intr>; > + msi-controller; > + ti,sci = <&sms>; > + ti,sci-dev-id = <321>; > + ti,interrupt-ranges = <0 0 256>; > + }; > + > + secure_proxy_main: mailbox@32c00000 { > + compatible = "ti,am654-secure-proxy"; > + #mbox-cells = <1>; > + reg-names = "target_data", "rt", "scfg"; > + reg = <0x00 0x32c00000 0x00 0x100000>, > + <0x00 0x32400000 0x00 0x100000>, > + <0x00 0x32800000 0x00 0x100000>; > + interrupt-names = "rx_011"; > + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>; > + }; > + > + hwspinlock: spinlock@30e00000 { Node name: hwlock (spinlock is Linux specific) > + compatible = "ti,am654-hwspinlock"; > + reg = <0x00 0x30e00000 0x00 0x1000>; > + #hwlock-cells = <1>; > + }; > + > + mailbox0_cluster0: mailbox@31f80000 { > + compatible = "ti,am654-mailbox"; > + reg = <0x00 0x31f80000 0x00 0x200>; > + #mbox-cells = <1>; > + ti,mbox-num-users = <4>; > + ti,mbox-num-fifos = <16>; > + interrupt-parent = <&main_navss_intr>; > + }; (...) > + > + wkup_pmx0: pinctrl@4301c000 { > + compatible = "pinctrl-single"; > + /* Proxy 0 addressing */ > + reg = <0x00 0x4301c000 0x00 0x178>; > + #pinctrl-cells = <1>; > + pinctrl-single,register-width = <32>; > + pinctrl-single,function-mask = <0xffffffff>; > + }; > + > + wkup_gpio_intr: interrupt-controller@42200000 { > + compatible = "ti,sci-intr"; > + reg = <0x00 0x42200000 0x00 0x400>; > + ti,intr-trigger-type = <1>; > + interrupt-controller; > + interrupt-parent = <&gic500>; > + #interrupt-cells = <1>; > + ti,sci = <&sms>; > + ti,sci-dev-id = <177>; > + ti,interrupt-ranges = <16 928 16>; > + }; > + > + mcu_conf: syscon@40f00000 { > + compatible = "syscon", "simple-mfd"; You need device specific compatible. Alone this is not allowed. Best regards, Krzysztof
On 19/08/2022 22:00, Apurva Nandan wrote: > J784s4 EVM board is designed for TI J784s4 SoC. It supports the following > interfaces: > * 32 GB DDR4 RAM > * x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode > * x1 Input Audio Jack, x1 Output Audio Jack > * x1 USB2.0 Hub with two Type A host and x1 USB 3.1 Type-C Port > * x2 4L PCIe connector > * x1 UHS-1 capable micro-SD card slot > * 512 Mbit OSPI flash, 1 Gbit Octal NAND flash, 512 Mbit QSPI flash, > UFS flash. > * x6 UART through UART-USB bridge > * XDS110 for onboard JTAG debug using USB > * Temperature sensors, user push buttons and LEDs > * 40-pin User Expansion Connector > * x2 ENET Expansion Connector, x1 GESI expander, x2 Display connector > * x1 15-pin CSI header > * x6 MCAN instances > > Add basic support for J784s4-EVM. > > Schematics: https://www.ti.com/lit/zip/sprr458 Use subject perfixes matching the subsystem (git log --oneline -- ...). For example: arm64: dts: ti: > > Signed-off-by: Hari Nagalla <hnagalla@ti.com> > Signed-off-by: Apurva Nandan <a-nandan@ti.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > Signed-off-by: Matt Ranostay <mranostay@ti.com> > Signed-off-by: Rahul T R <r-ravikumar@ti.com> > Signed-off-by: Suman Anna <s-anna@ti.com> > Signed-off-by: Pratyush Yadav <p.yadav@ti.com> > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > --- > arch/arm64/boot/dts/ti/Makefile | 2 + > arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 602 +++++++++++++++++++++++ > 2 files changed, 604 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-j784s4-evm.dts > > diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile > index 02e5d80344d0..6381c458738a 100644 > --- a/arch/arm64/boot/dts/ti/Makefile > +++ b/arch/arm64/boot/dts/ti/Makefile > @@ -19,6 +19,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-j7200-common-proc-board.dtb > > dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb > > +dtb-$(CONFIG_ARCH_K3) += k3-j784s4-evm.dtb > + > dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb > > diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts > new file mode 100644 > index 000000000000..7ca08e115e67 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts > @@ -0,0 +1,602 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > + * > + * Common Processor Board: https://www.ti.com/tool/J721EXCPXEVM > + */ > + > +/dts-v1/; > + > +#include <dt-bindings/net/ti-dp83867.h> > +#include <dt-bindings/gpio/gpio.h> > +#include "k3-j784s4.dtsi" > + > +/ { > + compatible = "ti,j784s4-evm", "ti,j784s4"; > + model = "Texas Instruments J784S4 EVM"; > + > + chosen { > + stdout-path = "serial2:115200n8"; > + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x2880000"; earlycon is not a property of hardware. Console is defined in stdout-path, so please drop entire bootargs. > + }; > + > + aliases { > + serial2 = &main_uart8; > + mmc0 = &main_sdhci0; > + mmc1 = &main_sdhci1; > + i2c0 = &main_i2c0; > + can0 = &mcu_mcan0; > + can1 = &mcu_mcan1; > + }; > + > + memory@80000000 { > + device_type = "memory"; > + /* 32G RAM */ > + reg = <0x00 0x80000000 0x00 0x80000000>, > + <0x08 0x80000000 0x07 0x80000000>; > + }; > + > + /* Reserving memory regions still pending */ > + reserved_memory: reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + secure_ddr: optee@9e800000 { > + reg = <0x00 0x9e800000 0x00 0x01800000>; > + alignment = <0x1000>; > + no-map; > + }; > + }; > + > + evm_12v0: fixedregulator-evm12v0 { Node name should be generic, so: regulator-evm12v0 > + /* main supply */ > + compatible = "regulator-fixed"; > + regulator-name = "evm_12v0"; > + regulator-min-microvolt = <12000000>; > + regulator-max-microvolt = <12000000>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + vsys_3v3: fixedregulator-vsys3v3 { ditto > + /* Output of LM5140 */ > + compatible = "regulator-fixed"; > + regulator-name = "vsys_3v3"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + vin-supply = <&evm_12v0>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + vsys_5v0: fixedregulator-vsys5v0 { ditto > + /* Output of LM5140 */ > + compatible = "regulator-fixed"; > + regulator-name = "vsys_5v0"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + vin-supply = <&evm_12v0>; > + regulator-always-on; > + regulator-boot-on; > + }; > + > + vdd_mmc1: fixedregulator-sd { ditto > + /* Output of TPS22918 */ > + compatible = "regulator-fixed"; > + regulator-name = "vdd_mmc1"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + regulator-boot-on; > + enable-active-high; > + vin-supply = <&vsys_3v3>; > + gpio = <&exp2 2 GPIO_ACTIVE_HIGH>; > + }; > + > + vdd_sd_dv: gpio-regulator-TLV71033 { ditto > + /* Output of TLV71033 */ > + compatible = "regulator-gpio"; > + regulator-name = "tlv71033"; > + pinctrl-names = "default"; > + pinctrl-0 = <&vdd_sd_dv_pins_default>; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <3300000>; > + regulator-boot-on; > + vin-supply = <&vsys_5v0>; > + gpios = <&main_gpio0 8 GPIO_ACTIVE_HIGH>; > + states = <1800000 0x0>, > + <3300000 0x1>; > + }; > + > + transceiver1: can-phy1 { > + compatible = "ti,tcan1042"; > + #phy-cells = <0>; > + max-bitrate = <5000000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&mcu_mcan0_gpio_pins_default>; > + standby-gpios = <&wkup_gpio0 69 GPIO_ACTIVE_HIGH>; > + }; > + > + transceiver2: can-phy2 { > + compatible = "ti,tcan1042"; > + #phy-cells = <0>; > + max-bitrate = <5000000>; > + pinctrl-names = "default"; > + pinctrl-0 = <&mcu_mcan1_gpio_pins_default>; > + standby-gpios = <&wkup_gpio0 2 GPIO_ACTIVE_HIGH>; > + }; Best regards, Krzysztof
On 13:18-20220823, Krzysztof Kozlowski wrote: > > + main_gpio_intr: interrupt-controller@a00000 { > > + compatible = "ti,sci-intr"; > > + reg = <0x00 0x00a00000 0x00 0x800>; > > 0x0, not 0x00. Here and all other places. Krzysztof is this a convention we have started following strongly? The reason I ask is to be able to cleanup elsewhere in the dts as well.. So far, I have insisted on 0x00 usage. [...]
On 13:21-20220823, Krzysztof Kozlowski wrote: > > + > > +/ { > > + compatible = "ti,j784s4-evm", "ti,j784s4"; > > + model = "Texas Instruments J784S4 EVM"; > > + > > + chosen { > > + stdout-path = "serial2:115200n8"; > > + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x2880000"; > > earlycon is not a property of hardware. Console is defined in > stdout-path, so please drop entire bootargs. We will probably have to cleanup elsewhere as well - point noted. [...]
Hi Krzysztof, On 24/08/22 10:36, Nishanth Menon wrote: > On 13:21-20220823, Krzysztof Kozlowski wrote: >>> + >>> +/ { >>> + compatible = "ti,j784s4-evm", "ti,j784s4"; >>> + model = "Texas Instruments J784S4 EVM"; >>> + >>> + chosen { >>> + stdout-path = "serial2:115200n8"; >>> + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x2880000"; >> >> earlycon is not a property of hardware. Console is defined in earlycon is helpful for debugging early crashes. How is it any different from "console =" property as described in Documentation/devicetree/usage-model.rst? >> stdout-path, so please drop entire bootargs. > > We will probably have to cleanup elsewhere as well - point noted. > Whats the alternative to pass default bootargs to kernel if bootloader does not pass bootargs via cmdline? I see quite a few dts file use bootargs = "earlycon" at least
On 24/08/2022 08:33, Vignesh Raghavendra wrote: > Hi Krzysztof, > > On 24/08/22 10:36, Nishanth Menon wrote: >> On 13:21-20220823, Krzysztof Kozlowski wrote: >>>> + >>>> +/ { >>>> + compatible = "ti,j784s4-evm", "ti,j784s4"; >>>> + model = "Texas Instruments J784S4 EVM"; >>>> + >>>> + chosen { >>>> + stdout-path = "serial2:115200n8"; >>>> + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x2880000"; >>> >>> earlycon is not a property of hardware. Console is defined in > > earlycon is helpful for debugging early crashes. How is it any different > from "console =" property as described in > Documentation/devicetree/usage-model.rst? choice of console is needed for basic operation and is chosen based on current hardware setup. earlycon is purely for debugging and should be enabled only when debugging is intended, not on mainline wide-available sources. > >>> stdout-path, so please drop entire bootargs. >> >> We will probably have to cleanup elsewhere as well - point noted. >> > > Whats the alternative to pass default bootargs to kernel if bootloader > does not pass bootargs via cmdline? I see quite a few dts file use > bootargs = "earlycon" at least Uboot, your own out-of-tree testing patches? What's the point to have earlycon available for every user which does not want to debug? Sorry, but bootargs are not accepted in DTS. We have several discussions around it over time... Best regards, Krzysztof
On 24/08/22 12:42, Krzysztof Kozlowski wrote: > On 24/08/2022 08:33, Vignesh Raghavendra wrote: >> Hi Krzysztof, >> >> On 24/08/22 10:36, Nishanth Menon wrote: >>> On 13:21-20220823, Krzysztof Kozlowski wrote: >>>>> + >>>>> +/ { >>>>> + compatible = "ti,j784s4-evm", "ti,j784s4"; >>>>> + model = "Texas Instruments J784S4 EVM"; >>>>> + >>>>> + chosen { >>>>> + stdout-path = "serial2:115200n8"; >>>>> + bootargs = "console=ttyS2,115200n8 earlycon=ns16550a,mmio32,0x2880000"; >>>> >>>> earlycon is not a property of hardware. Console is defined in >> >> earlycon is helpful for debugging early crashes. How is it any different >> from "console =" property as described in >> Documentation/devicetree/usage-model.rst? > > choice of console is needed for basic operation and is chosen based on > current hardware setup. earlycon is purely for debugging and should be > enabled only when debugging is intended, not on mainline wide-available > sources. > >> >>>> stdout-path, so please drop entire bootargs. >>> >>> We will probably have to cleanup elsewhere as well - point noted. >>> >> >> Whats the alternative to pass default bootargs to kernel if bootloader >> does not pass bootargs via cmdline? I see quite a few dts file use >> bootargs = "earlycon" at least > > Uboot, your own out-of-tree testing patches? What's the point to have > earlycon available for every user which does not want to debug? > > Sorry, but bootargs are not accepted in DTS. We have several discussions > around it over time... Understood, just wanted to make sure what the latest stance is, as I see lot of files in arm64 dts folder still use bootargs and earlycon. Thanks for the clarification!
On 24/08/2022 08:02, Nishanth Menon wrote: > On 13:18-20220823, Krzysztof Kozlowski wrote: >>> + main_gpio_intr: interrupt-controller@a00000 { >>> + compatible = "ti,sci-intr"; >>> + reg = <0x00 0x00a00000 0x00 0x800>; >> >> 0x0, not 0x00. Here and all other places. > > > Krzysztof is this a convention we have started following strongly? > > The reason I ask is to be able to cleanup elsewhere in the dts as well.. > > > So far, I have insisted on 0x00 usage. Not really, just stick to one. Your other nodes have 0x0, so just choose one. Anyway additional zeros seem redundant, but it is up to you which convention you prefer. Just choose one, not mixed. Best regards, Krzysztof