| Message ID | 20221116130428.161329-5-a-nandan@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add initial support for J784S4 SoC | expand |
On 18:34-20221116, 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 > > Signed-off-by: Hari Nagalla <hnagalla@ti.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > Signed-off-by: Apurva Nandan <a-nandan@ti.com> > --- > arch/arm64/boot/dts/ti/Makefile | 2 + > arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 197 +++++++++++++++++++++++ > 2 files changed, 199 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 4555a5be2257..67621b349e88 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..53516fb2b346 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts > @@ -0,0 +1,196 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ > + * > + * EVM Board Schematics: https://www.ti.com/lit/zip/sprr458 > + */ > + > +/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"; > + }; > + > + aliases { > + serial2 = &main_uart8; > + mmc1 = &main_sdhci1; > + i2c0 = &main_i2c0; > + }; > + > + memory@80000000 { > + device_type = "memory"; > + /* 32G RAM */ > + reg = <0x00 0x80000000 0x00 0x80000000>, > + <0x08 0x80000000 0x07 0x80000000>; > + }; > + > + reserved_memory: reserved-memory { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + secure_ddr: optee@9e800000 { > + reg = <0x00 0x9e800000 0x00 0x01800000>; > + no-map; > + }; > + }; > + > + evm_12v0: 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: regulator-vsys3v3 { > + /* 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: regulator-vsys5v0 { > + /* 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: regulator-sd { > + /* 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: regulator-TLV71033 { > + /* 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>; > + }; > +}; > + > +&main_pmx0 { > + main_uart8_pins_default: main-uart8-pins-default { > + pinctrl-single,pins = < > + J784S4_IOPAD(0x040, PIN_INPUT, 14) /* (AF37) MCASP0_AXR0.UART8_CTSn */ > + J784S4_IOPAD(0x044, PIN_OUTPUT, 14) /* (AG37) MCASP0_AXR1.UART8_RTSn */ > + J784S4_IOPAD(0x0d0, PIN_INPUT, 11) /* (AP38) SPI0_CS1.UART8_RXD */ > + J784S4_IOPAD(0x0d4, PIN_OUTPUT, 11) /* (AN38) SPI0_CLK.UART8_TXD */ > + >; > + }; > + > + main_i2c0_pins_default: main-i2c0-pins-default { > + pinctrl-single,pins = < > + J784S4_IOPAD(0x0e0, PIN_INPUT_PULLUP, 0) /* (AN36) I2C0_SCL */ > + J784S4_IOPAD(0x0e4, PIN_INPUT_PULLUP, 0) /* (AP37) I2C0_SDA */ > + >; > + }; > + > + main_mmc1_pins_default: main-mmc1-pins-default { > + pinctrl-single,pins = < > + J784S4_IOPAD(0x104, PIN_INPUT, 0) /* (AB38) MMC1_CLK */ > + J784S4_IOPAD(0x108, PIN_INPUT, 0) /* (AB36) MMC1_CMD */ > + J784S4_IOPAD(0x100, PIN_INPUT, 0) /* (No Pin) MMC1_CLKLB */ > + J784S4_IOPAD(0x0fc, PIN_INPUT, 0) /* (AA33) MMC1_DAT0 */ > + J784S4_IOPAD(0x0f8, PIN_INPUT, 0) /* (AB34) MMC1_DAT1 */ > + J784S4_IOPAD(0x0f4, PIN_INPUT, 0) /* (AA32) MMC1_DAT2 */ > + J784S4_IOPAD(0x0f0, PIN_INPUT, 0) /* (AC38) MMC1_DAT3 */ > + J784S4_IOPAD(0x0e8, PIN_INPUT, 8) /* (AR38) TIMER_IO0.MMC1_SDCD */ > + >; > + }; > + > + vdd_sd_dv_pins_default: vdd-sd-dv-pins-default { > + pinctrl-single,pins = < > + J784S4_IOPAD(0x020, PIN_INPUT, 7) /* (AJ35) MCAN15_RX.GPIO0_8 */ > + >; > + }; > +}; > + > +&main_uart8 { > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&main_uart8_pins_default>; > +}; > + > +&main_i2c0 { > + status = "okay"; > + pinctrl-names = "default"; > + pinctrl-0 = <&main_i2c0_pins_default>; > + > + clock-frequency = <400000>; > + > + exp1: gpio@20 { > + compatible = "ti,tca6416"; > + reg = <0x20>; > + gpio-controller; > + #gpio-cells = <2>; > + gpio-line-names = "PCIE1_2L_MODE_SEL", "PCIE1_4L_PERSTZ", "PCIE1_2L_RC_RSTZ", > + "PCIE1_2L_EP_RST_EN", "PCIE0_4L_MODE_SEL", "PCIE0_4L_PERSTZ", > + "PCIE0_4L_RC_RSTZ", "PCIE0_4L_EP_RST_EN", "PCIE1_4L_PRSNT#", > + "PCIE0_4L_PRSNT#", "CDCI1_OE1/OE4", "CDCI1_OE2/OE3", > + "AUDIO_MUX_SEL", "EXP_MUX2", "EXP_MUX3", "GESI_EXP_PHY_RSTZ"; > + }; > + > + exp2: gpio@22 { > + compatible = "ti,tca6424"; > + reg = <0x22>; > + gpio-controller; > + #gpio-cells = <2>; > + gpio-line-names = "R_GPIO_RGMII1_RST", "ENET2_I2CMUX_SEL", "GPIO_USD_PWR_EN", > + "USBC_PWR_EN", "USBC_MODE_SEL1", "USBC_MODE_SEL0", > + "GPIO_LIN_EN", "R_CAN_STB", "CTRL_PM_I2C_OE#", > + "ENET2_EXP_PWRDN", "ENET2_EXP_SPARE2", "CDCI2_RSTZ", > + "USB2.0_MUX_SEL", "CANUART_MUX_SEL0", "CANUART_MUX2_SEL1", > + "CANUART_MUX1_SEL1", "ENET1_EXP_PWRDN", "ENET1_EXP_RESETZ", > + "ENET1_I2CMUX_SEL", "ENET1_EXP_SPARE2", "ENET2_EXP_RESETZ", > + "USER_INPUT1", "USER_LED1", "USER_LED2"; > + }; > +}; > + > +&main_sdhci1 { > + /* SD card */ > + status = "okay"; > + pinctrl-0 = <&main_mmc1_pins_default>; > + pinctrl-names = "default"; > + disable-wp; > + vmmc-supply = <&vdd_mmc1>; > + vqmmc-supply = <&vdd_sd_dv>; > +}; > + > +&main_gpio0 { > + status = "okay"; > +}; > -- > 2.17.1 > Tested-by: Manorit Chawdhry <m-chawdhry@ti.com> Manorit
On 11/18/22 11:47 AM, Nishanth Menon wrote: > On 11:40-20221118, Andrew Davis wrote: >> On 11/16/22 7:04 AM, Apurva Nandan wrote: > > [...] > >>> +#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"; >>> + }; >>> + >>> + aliases { >>> + serial2 = &main_uart8; >> >> This feels hacky. Your chosen node picks serial2 as that is usually >> the one that is wired up on K3 boards. But on this board it is main_uart8. >> So why not have this be serial10, then choose >> >> stdout-path = "serial10:115200n8"; >> >> Also, I've made comments on previous version of this series, it is >> nice to include folks who have commented before in the CC for future >> versions, that way our filters don't hide these away and we can more >> easily check that our comments have been addressed. > > Please stick with the standard of serial2 as the linux console standard. > We ended up with that to ease up capabilities of various distros to > uniformly work across SoC and board variants. > The chosen "stdout-path" is for setting the kernel's default output terminal. Distros and other userspaces need to use their own policy mechanisms for picking what serial port to run getty on or whatever the issue may be. Some look at the kernel command line, and our bootloader provides that too, so still no reason to fake alias names here. Andrew > I do agree that phandle is the wrong approach here (baud etc information > missing). "serial2:115200n8" is probably the way to do this right. >
On 11/18/22 12:08 PM, Nishanth Menon wrote: > On 11:56-20221118, Andrew Davis wrote: >> On 11/18/22 11:47 AM, Nishanth Menon wrote: >>> On 11:40-20221118, Andrew Davis wrote: >>>> On 11/16/22 7:04 AM, Apurva Nandan wrote: >>> >>> [...] >>> >>>>> +#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"; >>>>> + }; >>>>> + >>>>> + aliases { >>>>> + serial2 = &main_uart8; >>>> >>>> This feels hacky. Your chosen node picks serial2 as that is usually >>>> the one that is wired up on K3 boards. But on this board it is main_uart8. >>>> So why not have this be serial10, then choose >>>> >>>> stdout-path = "serial10:115200n8"; >>>> >>>> Also, I've made comments on previous version of this series, it is >>>> nice to include folks who have commented before in the CC for future >>>> versions, that way our filters don't hide these away and we can more >>>> easily check that our comments have been addressed. >>> >>> Please stick with the standard of serial2 as the linux console standard. >>> We ended up with that to ease up capabilities of various distros to >>> uniformly work across SoC and board variants. >>> >> >> The chosen "stdout-path" is for setting the kernel's default output terminal. >> Distros and other userspaces need to use their own policy mechanisms for >> picking what serial port to run getty on or whatever the issue may be. >> >> Some look at the kernel command line, and our bootloader provides >> that too, so still no reason to fake alias names here. > > > We have had this conversation earlier as well. > > https://lore.kernel.org/linux-arm-kernel/CAK8P3a2VSBvOn1o+q1PYZaQ6LS9U4cz+DZGuDbisHkwNs2dAAw@mail.gmail.com/T/#m4ecb0dc6a78c84631f072faa1b0df0df46333d09 > > This is also the reason why we picked serial2 as linux console as a > standard across the boards based on the ecosystem. > I don't see either of those addressed in that thread, only that the aliases should go in the .dts files and be trimmed, nothing stops us from: chosen { stdout-path = "serial10:115200n8"; }; aliases { serial10 = &main_uart8; }; Andrew
On 12:15-20221118, Andrew Davis wrote: > I don't see either of those addressed in that thread, only that > the aliases should go in the .dts files and be trimmed, nothing Key is trimmed to what the system and ecosystem needs. > stops us from: > > chosen { > stdout-path = "serial10:115200n8"; > }; > > aliases { > serial10 = &main_uart8; > }; Do we need 10 serial aliases? There are'nt 10 serial ports exposed in j782s2. ok - lets say we do this, then: [1] is needed to boot? but why do we need to do that for all armv8 platforms when aliases allows us to trim it to just the 3 or 4 serial ports the platform really needs That + being able to use the convention that serial2 is always linux console, is'nt that a good thing? Hence recommending to just expose the serialports as aliases to exactly what we need while keeping serial2 as the linux console (which in this case happens to be main_uart8 - example as j721s2 does). [1] https://lore.kernel.org/lkml/3ab9addf-7938-fcf3-6147-15a998e37d2d@ti.com/
On 15:08-20221118, Andrew Davis wrote: > On 11/18/22 1:27 PM, Nishanth Menon wrote: > > On 12:15-20221118, Andrew Davis wrote: > > > I don't see either of those addressed in that thread, only that > > > the aliases should go in the .dts files and be trimmed, nothing > > > > Key is trimmed to what the system and ecosystem needs. > > > > > stops us from: > > > > > > chosen { > > > stdout-path = "serial10:115200n8"; > > > }; > > > > > > aliases { > > > serial10 = &main_uart8; > > > }; > > > > Do we need 10 serial aliases? There are'nt 10 serial ports exposed in > > j782s2. ok - lets say we do this, then: [1] is needed to boot? but why > > do we need to do that for all armv8 platforms when aliases allows us > > Why do we need SERIAL_8250_NR_UARTS at all, might be a better question. > These should be dynamically allocated if the number goes over the > default count imposed by the TTY framework. Maybe folks are still a > bit too afraid to touch the TTY subsystem core, I don't blame them.. > > > to trim it to just the 3 or 4 serial ports the platform really needs > > That + being able to use the convention that serial2 is always linux > > console, is'nt that a good thing? Hence recommending to just expose the > > serialports as aliases to exactly what we need while keeping serial2 as > > the linux console (which in this case happens to be main_uart8 - example > > as j721s2 does). > > > > "serial2 as the linux console" is *not* a convention, we just don't want to > fix up our bootloader/userspace to actually reason about what serial ports to > put logins on. Why not make ttyS10 the default, or ttyS666, it doesn't solve > your multi-distro issue either way since they usually only start a login on > ttyS0, console=, and/or the first virtual tty. Never on ttyS2. So you are > hacking up DT for a solution that doesn't do what you want in the end. ttyS2 is an accidental convention not a "by design" or definition convention. I suspect we ended up here from old OMAP days - all platforms in k3 ended up with ttyS2. In hindsight, if I had to do it by design, I would probably have picked ttyS0, well, we did'nt. $ git grep stdout-path arch/arm/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c 379 "serial0 21 "serial1 33 "serial2 13 "serial3 1 "/slaves@3e000000/serial@0 $ git grep stdout-path arch/arm64/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c 245 "serial0 17 "serial0"; 7 "serial1 49 "serial2 3 "serial3 2 "serial4 2 "serial5 2 "serial6 $ git grep stdout-path arch/arm64/boot/dts/ti|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c 8 "serial2 1 "serial3 I don't buy the argument here for 1-1 mapping of aliased serial instances to instances - why should main_uart8 be ttyS10, why not ttyS8 (it is equally valid - why was it called uart8?).. That mapping is just a convention we are choosing to create. The iot2050 ecosystem picked ttyS3 as the linux console for reasons of that ecosystem. K3 so far has selected ttyS2 as the convention for console - no matter where the serial instances have been located. I want to maintain consistency of existing TI platforms here without needing to shove a dozen things on existing users (yes j78-evm is a new board, but it is within the existing k3 s/w ecosystem and yes, getty, systemd etc are smarter today than once upon a time) So, given TI K3 history does'nt follow rest of the non-TI instances unfortunately - and I am going to put my foot down here - serial8 or 10 is "fake" anyways - rationalization can be made in different ways. So pushing for one over the other is not something I will entertain.
On 19/11/22 03:45, Nishanth Menon wrote: > On 15:08-20221118, Andrew Davis wrote: >> On 11/18/22 1:27 PM, Nishanth Menon wrote: >>> On 12:15-20221118, Andrew Davis wrote: >>>> I don't see either of those addressed in that thread, only that >>>> the aliases should go in the .dts files and be trimmed, nothing >>> Key is trimmed to what the system and ecosystem needs. >>> >>>> stops us from: >>>> >>>> chosen { >>>> stdout-path = "serial10:115200n8"; >>>> }; >>>> >>>> aliases { >>>> serial10 = &main_uart8; >>>> }; >>> Do we need 10 serial aliases? There are'nt 10 serial ports exposed in >>> j782s2. ok - lets say we do this, then: [1] is needed to boot? but why >>> do we need to do that for all armv8 platforms when aliases allows us >> Why do we need SERIAL_8250_NR_UARTS at all, might be a better question. >> These should be dynamically allocated if the number goes over the >> default count imposed by the TTY framework. Maybe folks are still a >> bit too afraid to touch the TTY subsystem core, I don't blame them.. >> >>> to trim it to just the 3 or 4 serial ports the platform really needs >>> That + being able to use the convention that serial2 is always linux >>> console, is'nt that a good thing? Hence recommending to just expose the >>> serialports as aliases to exactly what we need while keeping serial2 as >>> the linux console (which in this case happens to be main_uart8 - example >>> as j721s2 does). >>> >> "serial2 as the linux console" is *not* a convention, we just don't want to >> fix up our bootloader/userspace to actually reason about what serial ports to >> put logins on. Why not make ttyS10 the default, or ttyS666, it doesn't solve >> your multi-distro issue either way since they usually only start a login on >> ttyS0, console=, and/or the first virtual tty. Never on ttyS2. So you are >> hacking up DT for a solution that doesn't do what you want in the end. > ttyS2 is an accidental convention not a "by design" or definition > convention. I suspect we ended up here from old OMAP days - all > platforms in k3 ended up with ttyS2. In hindsight, if I had to do it > by design, I would probably have picked ttyS0, well, we did'nt. > > $ git grep stdout-path arch/arm/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c > 379 "serial0 > 21 "serial1 > 33 "serial2 > 13 "serial3 > 1 "/slaves@3e000000/serial@0 > > $ git grep stdout-path arch/arm64/boot/dts|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c > 245 "serial0 > 17 "serial0"; > 7 "serial1 > 49 "serial2 > 3 "serial3 > 2 "serial4 > 2 "serial5 > 2 "serial6 > > $ git grep stdout-path arch/arm64/boot/dts/ti|grep serial|cut -d '=' -f 2|cut -d ':' -f1|grep -v '&'|sort|uniq -c > 8 "serial2 > 1 "serial3 > > I don't buy the argument here for 1-1 mapping of aliased serial > instances to instances - why should main_uart8 be ttyS10, why not > ttyS8 (it is equally valid - why was it called uart8?).. That mapping > is just a convention we are choosing to create. > > The iot2050 ecosystem picked ttyS3 as the linux console for reasons of > that ecosystem. K3 so far has selected ttyS2 as the convention for > console - no matter where the serial instances have been located. > > I want to maintain consistency of existing TI platforms here without > needing to shove a dozen things on existing users (yes j78-evm is a new > board, but it is within the existing k3 s/w ecosystem and yes, getty, > systemd etc are smarter today than once upon a time) > > So, given TI K3 history does'nt follow rest of the non-TI instances > unfortunately - and I am going to put my foot down here - serial8 or 10 > is "fake" anyways - rationalization can be made in different ways. So > pushing for one over the other is not something I will entertain. > > From usage model point of view - serial0 will be the best candidate as > console followed by serial2 (purely statistically speaking). In K3 > context, it is just serial2 in TI board ecosystem. > > That is a discussion for pros and cons - Open to hearing opinions. > Unless I hear 1000% strong reasons with _backing data_ - not an > subjective "it is correct thing to do" - why we'd want to move TI > board ecosystem (including all the pains of bootloader combinations > etc) switch over to ttyS0[1], having a mix and churn for the s/w > ecosystem of having to deal with ttyS0 and ttyS2 nodes in arm64/dts/ti > at least for the TI board ecosystem.. I cant see why i want to put the > ecosystem through another churn on consoles.. But, fine, i will keep > my ears open. If there are no strong arguments with _data_, then we > stick with serial2 and y'all can curse me for another decade+ for that > call :) > > [1] I have'nt forgotten ttyO2 to ttyS2 transition of OMAP > https://duckduckgo.com/?q=ttyO2+to+ttyS2+omap Hi all, I agree that there could be different standpoints on the aliasing of serial, and the current way might not be the right way, but we have been using that a quite long without any issues. (All K3 platforms use the same serial2 for console). IMO, if needed, the right way to change to other serial would be to: 1. Change all the serial aliases across K3 platforms, along with other serial dependencies in userspace. 2. And have that as a separate patch series, i.e. a series that changes all the incorrect aliases across K3 platforms. And this J784S4 patch series is not that one. Coming to a consensus would take time, lets do that separately and no point blocking this series for it. All the previous platforms use the serial2 for console uart and I will post my next series with the same. If there is a need to change the serial aliasing, change it across all previous platforms in a separate patch series.
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile index 4555a5be2257..67621b349e88 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..53516fb2b346 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts @@ -0,0 +1,196 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ + * + * EVM Board Schematics: https://www.ti.com/lit/zip/sprr458 + */ + +/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"; + }; + + aliases { + serial2 = &main_uart8; + mmc1 = &main_sdhci1; + i2c0 = &main_i2c0; + }; + + memory@80000000 { + device_type = "memory"; + /* 32G RAM */ + reg = <0x00 0x80000000 0x00 0x80000000>, + <0x08 0x80000000 0x07 0x80000000>; + }; + + reserved_memory: reserved-memory { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + secure_ddr: optee@9e800000 { + reg = <0x00 0x9e800000 0x00 0x01800000>; + no-map; + }; + }; + + evm_12v0: 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: regulator-vsys3v3 { + /* 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: regulator-vsys5v0 { + /* 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: regulator-sd { + /* 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: regulator-TLV71033 { + /* 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>; + }; +}; + +&main_pmx0 { + main_uart8_pins_default: main-uart8-pins-default { + pinctrl-single,pins = < + J784S4_IOPAD(0x040, PIN_INPUT, 14) /* (AF37) MCASP0_AXR0.UART8_CTSn */ + J784S4_IOPAD(0x044, PIN_OUTPUT, 14) /* (AG37) MCASP0_AXR1.UART8_RTSn */ + J784S4_IOPAD(0x0d0, PIN_INPUT, 11) /* (AP38) SPI0_CS1.UART8_RXD */ + J784S4_IOPAD(0x0d4, PIN_OUTPUT, 11) /* (AN38) SPI0_CLK.UART8_TXD */ + >; + }; + + main_i2c0_pins_default: main-i2c0-pins-default { + pinctrl-single,pins = < + J784S4_IOPAD(0x0e0, PIN_INPUT_PULLUP, 0) /* (AN36) I2C0_SCL */ + J784S4_IOPAD(0x0e4, PIN_INPUT_PULLUP, 0) /* (AP37) I2C0_SDA */ + >; + }; + + main_mmc1_pins_default: main-mmc1-pins-default { + pinctrl-single,pins = < + J784S4_IOPAD(0x104, PIN_INPUT, 0) /* (AB38) MMC1_CLK */ + J784S4_IOPAD(0x108, PIN_INPUT, 0) /* (AB36) MMC1_CMD */ + J784S4_IOPAD(0x100, PIN_INPUT, 0) /* (No Pin) MMC1_CLKLB */ + J784S4_IOPAD(0x0fc, PIN_INPUT, 0) /* (AA33) MMC1_DAT0 */ + J784S4_IOPAD(0x0f8, PIN_INPUT, 0) /* (AB34) MMC1_DAT1 */ + J784S4_IOPAD(0x0f4, PIN_INPUT, 0) /* (AA32) MMC1_DAT2 */ + J784S4_IOPAD(0x0f0, PIN_INPUT, 0) /* (AC38) MMC1_DAT3 */ + J784S4_IOPAD(0x0e8, PIN_INPUT, 8) /* (AR38) TIMER_IO0.MMC1_SDCD */ + >; + }; + + vdd_sd_dv_pins_default: vdd-sd-dv-pins-default { + pinctrl-single,pins = < + J784S4_IOPAD(0x020, PIN_INPUT, 7) /* (AJ35) MCAN15_RX.GPIO0_8 */ + >; + }; +}; + +&main_uart8 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&main_uart8_pins_default>; +}; + +&main_i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c0_pins_default>; + + clock-frequency = <400000>; + + exp1: gpio@20 { + compatible = "ti,tca6416"; + reg = <0x20>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "PCIE1_2L_MODE_SEL", "PCIE1_4L_PERSTZ", "PCIE1_2L_RC_RSTZ", + "PCIE1_2L_EP_RST_EN", "PCIE0_4L_MODE_SEL", "PCIE0_4L_PERSTZ", + "PCIE0_4L_RC_RSTZ", "PCIE0_4L_EP_RST_EN", "PCIE1_4L_PRSNT#", + "PCIE0_4L_PRSNT#", "CDCI1_OE1/OE4", "CDCI1_OE2/OE3", + "AUDIO_MUX_SEL", "EXP_MUX2", "EXP_MUX3", "GESI_EXP_PHY_RSTZ"; + }; + + exp2: gpio@22 { + compatible = "ti,tca6424"; + reg = <0x22>; + gpio-controller; + #gpio-cells = <2>; + gpio-line-names = "R_GPIO_RGMII1_RST", "ENET2_I2CMUX_SEL", "GPIO_USD_PWR_EN", + "USBC_PWR_EN", "USBC_MODE_SEL1", "USBC_MODE_SEL0", + "GPIO_LIN_EN", "R_CAN_STB", "CTRL_PM_I2C_OE#", + "ENET2_EXP_PWRDN", "ENET2_EXP_SPARE2", "CDCI2_RSTZ", + "USB2.0_MUX_SEL", "CANUART_MUX_SEL0", "CANUART_MUX2_SEL1", + "CANUART_MUX1_SEL1", "ENET1_EXP_PWRDN", "ENET1_EXP_RESETZ", + "ENET1_I2CMUX_SEL", "ENET1_EXP_SPARE2", "ENET2_EXP_RESETZ", + "USER_INPUT1", "USER_LED1", "USER_LED2"; + }; +}; + +&main_sdhci1 { + /* SD card */ + status = "okay"; + pinctrl-0 = <&main_mmc1_pins_default>; + pinctrl-names = "default"; + disable-wp; + vmmc-supply = <&vdd_mmc1>; + vqmmc-supply = <&vdd_sd_dv>; +}; + +&main_gpio0 { + status = "okay"; +};