[v3,4/4] arm64: dts: ti: Add support for J784S4 EVM board

  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
  

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/16/22 7:04 AM, 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;

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.

Andrew

> +		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";
> +};
  

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.

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 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: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.
  

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 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.

Andrew

> [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.

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
  

* Nishanth Menon <nm@ti.com> [221118 22:12]:
> 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.

Heh yeah IMO uart8 should be ttyS8.. I agree let's not break the userspace
device names as we've seen what kind of nightmare that ends up being.

Regards,

Tony
  

* Andrew Davis <afd@ti.com> [221118 21:05]:
> 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..

The 8250 core preallocates a number of ports for use, see
serial8250_isa_init_ports() and serial8250_register_8250_port(). As the
serial port driver probes, the preallocated ports get re-assigned to
the port driver.

Maybe we could keep the static serial8250_ports[] and add those ports
to a list where also the dynamically allocated ports would go..

Regards,

Tony
  

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.