* [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant
@ 2023-12-18 16:35 Jan Kiszka
2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Jan Kiszka @ 2023-12-18 16:35 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su
This bring support for yet another IOT2050 device variant, see last
patch for details. The rest is binding and refactoring to make that
happen.
Jan
Baocheng Su (2):
arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards
dts: iot2050: Support IOT2050-SM variant
Jan Kiszka (1):
arm64: dts: ti: iot2050: Factor out arduino connector bits
Su Bao Cheng (1):
dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant
.../devicetree/bindings/arm/ti/k3.yaml | 1 +
arch/arm64/boot/dts/ti/Makefile | 1 +
.../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++
.../dts/ti/k3-am65-iot2050-common-pg2.dtsi | 7 +-
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 -----------------
.../ti/k3-am6528-iot2050-basic-common.dtsi | 6 +-
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 5 +
.../dts/ti/k3-am6548-iot2050-advanced-m2.dts | 6 +-
.../dts/ti/k3-am6548-iot2050-advanced-pg2.dts | 8 +-
.../dts/ti/k3-am6548-iot2050-advanced-sm.dts | 210 +++++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 1 +
11 files changed, 996 insertions(+), 770 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts
--
2.35.3
^ permalink raw reply [flat|nested] 25+ messages in thread* [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant 2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka @ 2023-12-18 16:35 ` Jan Kiszka 2023-12-19 7:50 ` Krzysztof Kozlowski 2023-12-18 16:35 ` [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards Jan Kiszka ` (2 subsequent siblings) 3 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-18 16:35 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su From: Su Bao Cheng <baocheng.su@siemens.com> This new variant is derived from the Advanced PG2 board, removing the Arduino interface, and adding a new ASIC for communicating with the PLC 1200 signal modules. Signed-off-by: Su Bao Cheng <baocheng.su@siemens.com> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index 03d2a0d79fb0..2cb3f6eb8a43 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -91,6 +91,7 @@ properties: - siemens,iot2050-advanced - siemens,iot2050-advanced-m2 - siemens,iot2050-advanced-pg2 + - siemens,iot2050-advanced-sm - siemens,iot2050-basic - siemens,iot2050-basic-pg2 - ti,am654-evm -- 2.35.3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 SM variant 2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka @ 2023-12-19 7:50 ` Krzysztof Kozlowski 0 siblings, 0 replies; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 7:50 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su On 18/12/2023 17:35, Jan Kiszka wrote: > From: Su Bao Cheng <baocheng.su@siemens.com> > > This new variant is derived from the Advanced PG2 board, removing the > Arduino interface, and adding a new ASIC for communicating with the > PLC 1200 signal modules. > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards 2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka 2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka @ 2023-12-18 16:35 ` Jan Kiszka 2023-12-18 16:35 ` [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits Jan Kiszka 2023-12-18 16:36 ` [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant Jan Kiszka 3 siblings, 0 replies; 25+ messages in thread From: Jan Kiszka @ 2023-12-18 16:35 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su From: Baocheng Su <baocheng.su@siemens.com> The R5 lockstep disabling should be common for all PG2 boards, move it from variants dts to common-pg2.dtsi. As now the Basic PG2 consumes this twice, move Basic disabling to the PG1 variant. Signed-off-by: Baocheng Su <baocheng.su@siemens.com> [Jan: avoid duplication of disabling for Basic PG2] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi | 7 ++++++- arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi | 5 ----- arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts | 5 +++++ arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts | 5 ----- arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts | 7 +------ 5 files changed, 12 insertions(+), 17 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi index e9b57b87e42e..42adb8815f38 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common-pg2.dtsi @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (c) Siemens AG, 2021 + * Copyright (c) Siemens AG, 2021-2023 * * Authors: * Chao Zeng <chao.zeng@siemens.com> @@ -9,6 +9,11 @@ * Common bits of the IOT2050 Basic and Advanced variants, PG2 */ +&mcu_r5fss0 { + /* lock-step mode not supported on PG2 boards */ + ti,cluster-mode = <0>; +}; + &main_pmx0 { cp2102n_reset_pin_default: cp2102n-reset-default-pins { pinctrl-single,pins = < diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi index 5ab434c02ab6..2300abe69e94 100644 --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi @@ -54,8 +54,3 @@ &main_uart0 { pinctrl-names = "default"; pinctrl-0 = <&main_uart0_pins_default>; }; - -&mcu_r5fss0 { - /* lock-step mode not supported on Basic boards */ - ti,cluster-mode = <0>; -}; diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts index 87928ff28214..be9c8db4c43a 100644 --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts @@ -22,3 +22,8 @@ / { compatible = "siemens,iot2050-basic", "ti,am654"; model = "SIMATIC IOT2050 Basic"; }; + +&mcu_r5fss0 { + /* lock-step mode not supported on this board */ + ti,cluster-mode = <0>; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts index bd6f2e696e94..1e5d4d98b69b 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts @@ -21,11 +21,6 @@ / { model = "SIMATIC IOT2050 Advanced M2"; }; -&mcu_r5fss0 { - /* lock-step mode not supported on this board */ - ti,cluster-mode = <0>; -}; - &main_pmx0 { main_bkey_pcie_reset: main-bkey-pcie-reset-default-pins { pinctrl-single,pins = < diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts index f00dc86d01b9..a8ce8c891894 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (c) Siemens AG, 2018-2021 + * Copyright (c) Siemens AG, 2018-2023 * * Authors: * Le Jin <le.jin@siemens.com> @@ -22,8 +22,3 @@ / { compatible = "siemens,iot2050-advanced-pg2", "ti,am654"; model = "SIMATIC IOT2050 Advanced PG2"; }; - -&mcu_r5fss0 { - /* lock-step mode not supported on this board */ - ti,cluster-mode = <0>; -}; -- 2.35.3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits 2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka 2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka 2023-12-18 16:35 ` [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards Jan Kiszka @ 2023-12-18 16:35 ` Jan Kiszka 2023-12-19 7:51 ` Krzysztof Kozlowski 2023-12-18 16:36 ` [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant Jan Kiszka 3 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-18 16:35 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su From: Jan Kiszka <jan.kiszka@siemens.com> A new variant is to be added which will not have a arduino connector like the existing ones. Factor out all bits that are specific to this connector. The split is not perfect because wkup_gpio0 is defined based on what is common to all variants having the connector, thus containing also connector-unrelated information. But this is still cleaner than replicating this node into all 4 variants. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++ .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 ----------------- .../ti/k3-am6528-iot2050-basic-common.dtsi | 1 + .../dts/ti/k3-am6548-iot2050-advanced-m2.dts | 1 + .../dts/ti/k3-am6548-iot2050-advanced-pg2.dts | 1 + .../dts/ti/k3-am6548-iot2050-advanced.dts | 1 + 6 files changed, 772 insertions(+), 753 deletions(-) create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi new file mode 100644 index 000000000000..cd86f412b837 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-arduino-connector.dtsi @@ -0,0 +1,768 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2018-2023 + * + * Authors: + * Le Jin <le.jin@siemens.com> + * Jan Kiszka <jan.kiszka@siemens.com> + * + * Common bits for IOT2050 variants with Arduino connector + */ + +&wkup_pmx0 { + pinctrl-names = + "default", + "d0-uart0-rxd", "d0-gpio", "d0-gpio-pullup", "d0-gpio-pulldown", + "d1-uart0-txd", "d1-gpio", "d1-gpio-pullup", "d1-gpio-pulldown", + "d2-uart0-ctsn", "d2-gpio", "d2-gpio-pullup", "d2-gpio-pulldown", + "d3-uart0-rtsn", "d3-gpio", "d3-gpio-pullup", "d3-gpio-pulldown", + "d10-spi0-cs0", "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown", + "d11-spi0-d0", "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown", + "d12-spi0-d1", "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown", + "d13-spi0-clk", "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown", + "a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown", + "a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown", + "a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown", + "a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown", + "a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown", + "a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown"; + + pinctrl-0 = <&d0_uart0_rxd>; + pinctrl-1 = <&d0_uart0_rxd>; + pinctrl-2 = <&d0_gpio>; + pinctrl-3 = <&d0_gpio_pullup>; + pinctrl-4 = <&d0_gpio_pulldown>; + pinctrl-5 = <&d1_uart0_txd>; + pinctrl-6 = <&d1_gpio>; + pinctrl-7 = <&d1_gpio_pullup>; + pinctrl-8 = <&d1_gpio_pulldown>; + pinctrl-9 = <&d2_uart0_ctsn>; + pinctrl-10 = <&d2_gpio>; + pinctrl-11 = <&d2_gpio_pullup>; + pinctrl-12 = <&d2_gpio_pulldown>; + pinctrl-13 = <&d3_uart0_rtsn>; + pinctrl-14 = <&d3_gpio>; + pinctrl-15 = <&d3_gpio_pullup>; + pinctrl-16 = <&d3_gpio_pulldown>; + pinctrl-17 = <&d10_spi0_cs0>; + pinctrl-18 = <&d10_gpio>; + pinctrl-19 = <&d10_gpio_pullup>; + pinctrl-20 = <&d10_gpio_pulldown>; + pinctrl-21 = <&d11_spi0_d0>; + pinctrl-22 = <&d11_gpio>; + pinctrl-23 = <&d11_gpio_pullup>; + pinctrl-24 = <&d11_gpio_pulldown>; + pinctrl-25 = <&d12_spi0_d1>; + pinctrl-26 = <&d12_gpio>; + pinctrl-27 = <&d12_gpio_pullup>; + pinctrl-28 = <&d12_gpio_pulldown>; + pinctrl-29 = <&d13_spi0_clk>; + pinctrl-30 = <&d13_gpio>; + pinctrl-31 = <&d13_gpio_pullup>; + pinctrl-32 = <&d13_gpio_pulldown>; + pinctrl-33 = <&a0_gpio>; + pinctrl-34 = <&a0_gpio_pullup>; + pinctrl-35 = <&a0_gpio_pulldown>; + pinctrl-36 = <&a1_gpio>; + pinctrl-37 = <&a1_gpio_pullup>; + pinctrl-38 = <&a1_gpio_pulldown>; + pinctrl-39 = <&a2_gpio>; + pinctrl-40 = <&a2_gpio_pullup>; + pinctrl-41 = <&a2_gpio_pulldown>; + pinctrl-42 = <&a3_gpio>; + pinctrl-43 = <&a3_gpio_pullup>; + pinctrl-44 = <&a3_gpio_pulldown>; + pinctrl-45 = <&a4_gpio>; + pinctrl-46 = <&a4_gpio_pullup>; + pinctrl-47 = <&a4_gpio_pulldown>; + pinctrl-48 = <&a5_gpio>; + pinctrl-49 = <&a5_gpio_pullup>; + pinctrl-50 = <&a5_gpio_pulldown>; + + d0_uart0_rxd: d0-uart0-rxd-pins { + pinctrl-single,pins = < + /* (P4) MCU_UART0_RXD */ + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) + >; + }; + + d0_gpio: d0-gpio-pins { + pinctrl-single,pins = < + /* (P4) WKUP_GPIO0_29 */ + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7) + >; + }; + + d0_gpio_pullup: d0-gpio-pullup-pins { + pinctrl-single,pins = < + /* (P4) WKUP_GPIO0_29 */ + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7) + >; + }; + + d0_gpio_pulldown: d0-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (P4) WKUP_GPIO0_29 */ + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d1_uart0_txd: d1-uart0-txd-pins { + pinctrl-single,pins = < + /* (P5) MCU_UART0_TXD */ + AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4) + >; + }; + + d1_gpio: d1-gpio-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_30 */ + AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7) + >; + }; + + d1_gpio_pullup: d1-gpio-pullup-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_30 */ + AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7) + >; + }; + + d1_gpio_pulldown: d1-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_30 */ + AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d2_uart0_ctsn: d2-uart0-ctsn-pins { + pinctrl-single,pins = < + /* (P1) MCU_UART0_CTSn */ + AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4) + >; + }; + + d2_gpio: d2-gpio-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_31 */ + AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7) + >; + }; + + d2_gpio_pullup: d2-gpio-pullup-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_31 */ + AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7) + >; + }; + + d2_gpio_pulldown: d2-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (P5) WKUP_GPIO0_31 */ + AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d3_uart0_rtsn: d3-uart0-rtsn-pins { + pinctrl-single,pins = < + /* (N3) MCU_UART0_RTSn */ + AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4) + >; + }; + + d3_gpio: d3-gpio-pins { + pinctrl-single,pins = < + /* (N3) WKUP_GPIO0_33 */ + AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7) + >; + }; + + d3_gpio_pullup: d3-gpio-pullup-pins { + pinctrl-single,pins = < + /* (N3) WKUP_GPIO0_33 */ + AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7) + >; + }; + + d3_gpio_pulldown: d3-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (N3) WKUP_GPIO0_33 */ + AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d10_spi0_cs0: d10-spi0-cs0-pins { + pinctrl-single,pins = < + /* (Y4) MCU_SPI0_CS0 */ + AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0) + >; + }; + + d10_gpio: d10-gpio-pins { + pinctrl-single,pins = < + /* (Y4) WKUP_GPIO0_51 */ + AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7) + >; + }; + + d10_gpio_pullup: d10-gpio-pullup-pins { + pinctrl-single,pins = < + /* (Y4) WKUP_GPIO0_51 */ + AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7) + >; + }; + + d10_gpio_pulldown: d10-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (Y4) WKUP_GPIO0_51 */ + AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d11_spi0_d0: d11-spi0-d0-pins { + pinctrl-single,pins = < + /* (Y3) MCU_SPI0_D0 */ + AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0) + >; + }; + + d11_gpio: d11-gpio-pins { + pinctrl-single,pins = < + /* (Y3) WKUP_GPIO0_49 */ + AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7) + >; + }; + + d11_gpio_pullup: d11-gpio-pullup-pins { + pinctrl-single,pins = < + /* (Y3) WKUP_GPIO0_49 */ + AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7) + >; + }; + + d11_gpio_pulldown: d11-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (Y3) WKUP_GPIO0_49 */ + AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d12_spi0_d1: d12-spi0-d1-pins { + pinctrl-single,pins = < + /* (Y2) MCU_SPI0_D1 */ + AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0) + >; + }; + + d12_gpio: d12-gpio-pins { + pinctrl-single,pins = < + /* (Y2) WKUP_GPIO0_50 */ + AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7) + >; + }; + + d12_gpio_pullup: d12-gpio-pullup-pins { + pinctrl-single,pins = < + /* (Y2) WKUP_GPIO0_50 */ + AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7) + >; + }; + + d12_gpio_pulldown: d12-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (Y2) WKUP_GPIO0_50 */ + AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d13_spi0_clk: d13-spi0-clk-pins { + pinctrl-single,pins = < + /* (Y1) MCU_SPI0_CLK */ + AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0) + >; + }; + + d13_gpio: d13-gpio-pins { + pinctrl-single,pins = < + /* (Y1) WKUP_GPIO0_48 */ + AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7) + >; + }; + + d13_gpio_pullup: d13-gpio-pullup-pins { + pinctrl-single,pins = < + /* (Y1) WKUP_GPIO0_48 */ + AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7) + >; + }; + + d13_gpio_pulldown: d13-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (Y1) WKUP_GPIO0_48 */ + AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a0_gpio: a0-gpio-pins { + pinctrl-single,pins = < + /* (L6) WKUP_GPIO0_45 */ + AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7) + >; + }; + + a0_gpio_pullup: a0-gpio-pullup-pins { + pinctrl-single,pins = < + /* (L6) WKUP_GPIO0_45 */ + AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7) + >; + }; + + a0_gpio_pulldown: a0-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (L6) WKUP_GPIO0_45 */ + AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a1_gpio: a1-gpio-pins { + pinctrl-single,pins = < + /* (M6) WKUP_GPIO0_44 */ + AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7) + >; + }; + + a1_gpio_pullup: a1-gpio-pullup-pins { + pinctrl-single,pins = < + /* (M6) WKUP_GPIO0_44 */ + AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7) + >; + }; + + a1_gpio_pulldown: a1-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (M6) WKUP_GPIO0_44 */ + AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a2_gpio: a2-gpio-pins { + pinctrl-single,pins = < + /* (L5) WKUP_GPIO0_43 */ + AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7) + >; + }; + + a2_gpio_pullup: a2-gpio-pullup-pins { + pinctrl-single,pins = < + /* (L5) WKUP_GPIO0_43 */ + AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7) + >; + }; + + a2_gpio_pulldown: a2-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (L5) WKUP_GPIO0_43 */ + AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a3_gpio: a3-gpio-pins { + pinctrl-single,pins = < + /* (M5) WKUP_GPIO0_39 */ + AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7) + >; + }; + + a3_gpio_pullup: a3-gpio-pullup-pins { + pinctrl-single,pins = < + /* (M5) WKUP_GPIO0_39 */ + AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7) + >; + }; + + a3_gpio_pulldown: a3-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (M5) WKUP_GPIO0_39 */ + AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a4_gpio: a4-gpio-pins { + pinctrl-single,pins = < + /* (L2) WKUP_GPIO0_42 */ + AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7) + >; + }; + + a4_gpio_pullup: a4-gpio-pullup-pins { + pinctrl-single,pins = < + /* (L2) WKUP_GPIO0_42 */ + AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7) + >; + }; + + a4_gpio_pulldown: a4-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (L2) WKUP_GPIO0_42 */ + AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7) + >; + }; + + a5_gpio: a5-gpio-pins { + pinctrl-single,pins = < + /* (N5) WKUP_GPIO0_35 */ + AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7) + >; + }; + + a5_gpio_pullup: a5-gpio-pullup-pins { + pinctrl-single,pins = < + /* (N5) WKUP_GPIO0_35 */ + AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7) + >; + }; + + a5_gpio_pulldown: a5-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (N5) WKUP_GPIO0_35 */ + AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7) + >; + }; + + wkup_i2c0_pins_default: wkup-i2c0-default-pins { + pinctrl-single,pins = < + /* (AC7) WKUP_I2C0_SCL */ + AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) + /* (AD6) WKUP_I2C0_SDA */ + AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) + >; + }; + + arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins { + pinctrl-single,pins = < + /* (R2) WKUP_GPIO0_21 */ + AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7) + >; + }; + + arduino_io_oe_pins_default: arduino-io-oe-default-pins { + pinctrl-single,pins = < + /* (N4) WKUP_GPIO0_34 */ + AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7) + /* (M2) WKUP_GPIO0_36 */ + AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7) + /* (M3) WKUP_GPIO0_37 */ + AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7) + /* (M4) WKUP_GPIO0_38 */ + AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7) + /* (M1) WKUP_GPIO0_41 */ + AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7) + >; + }; +}; + +&main_pmx0 { + pinctrl-names = + "default", + "d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown", + "d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown", + "d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown", + "d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown", + "d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown", + "d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown"; + + pinctrl-0 = <&d4_ehrpwm0_a>; + pinctrl-1 = <&d4_ehrpwm0_a>; + pinctrl-2 = <&d4_gpio>; + pinctrl-3 = <&d4_gpio_pullup>; + pinctrl-4 = <&d4_gpio_pulldown>; + + pinctrl-5 = <&d5_ehrpwm1_a>; + pinctrl-6 = <&d5_gpio>; + pinctrl-7 = <&d5_gpio_pullup>; + pinctrl-8 = <&d5_gpio_pulldown>; + + pinctrl-9 = <&d6_ehrpwm2_a>; + pinctrl-10 = <&d6_gpio>; + pinctrl-11 = <&d6_gpio_pullup>; + pinctrl-12 = <&d6_gpio_pulldown>; + + pinctrl-13 = <&d7_ehrpwm3_a>; + pinctrl-14 = <&d7_gpio>; + pinctrl-15 = <&d7_gpio_pullup>; + pinctrl-16 = <&d7_gpio_pulldown>; + + pinctrl-17 = <&d8_ehrpwm4_a>; + pinctrl-18 = <&d8_gpio>; + pinctrl-19 = <&d8_gpio_pullup>; + pinctrl-20 = <&d8_gpio_pulldown>; + + pinctrl-21 = <&d9_ehrpwm5_a>; + pinctrl-22 = <&d9_gpio>; + pinctrl-23 = <&d9_gpio_pullup>; + pinctrl-24 = <&d9_gpio_pulldown>; + + d4_ehrpwm0_a: d4-ehrpwm0-a-pins { + pinctrl-single,pins = < + /* (AG18) EHRPWM0_A */ + AM65X_IOPAD(0x0084, PIN_OUTPUT, 5) + >; + }; + + d4_gpio: d4-gpio-pins { + pinctrl-single,pins = < + /* (AG18) GPIO0_33 */ + AM65X_IOPAD(0x0084, PIN_INPUT, 7) + >; + }; + + d4_gpio_pullup: d4-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AG18) GPIO0_33 */ + AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7) + >; + }; + + d4_gpio_pulldown: d4-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AG18) GPIO0_33 */ + AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d5_ehrpwm1_a: d5-ehrpwm1-a-pins { + pinctrl-single,pins = < + /* (AF17) EHRPWM1_A */ + AM65X_IOPAD(0x008C, PIN_OUTPUT, 5) + >; + }; + + d5_gpio: d5-gpio-pins { + pinctrl-single,pins = < + /* (AF17) GPIO0_35 */ + AM65X_IOPAD(0x008C, PIN_INPUT, 7) + >; + }; + + d5_gpio_pullup: d5-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AF17) GPIO0_35 */ + AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7) + >; + }; + + d5_gpio_pulldown: d5-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AF17) GPIO0_35 */ + AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d6_ehrpwm2_a: d6-ehrpwm2-a-pins { + pinctrl-single,pins = < + /* (AH16) EHRPWM2_A */ + AM65X_IOPAD(0x0098, PIN_OUTPUT, 5) + >; + }; + + d6_gpio: d6-gpio-pins { + pinctrl-single,pins = < + /* (AH16) GPIO0_38 */ + AM65X_IOPAD(0x0098, PIN_INPUT, 7) + >; + }; + + d6_gpio_pullup: d6-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AH16) GPIO0_38 */ + AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7) + >; + }; + + d6_gpio_pulldown: d6-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AH16) GPIO0_38 */ + AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d7_ehrpwm3_a: d7-ehrpwm3-a-pins { + pinctrl-single,pins = < + /* (AH15) EHRPWM3_A */ + AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5) + >; + }; + + d7_gpio: d7-gpio-pins { + pinctrl-single,pins = < + /* (AH15) GPIO0_43 */ + AM65X_IOPAD(0x00AC, PIN_INPUT, 7) + >; + }; + + d7_gpio_pullup: d7-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AH15) GPIO0_43 */ + AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7) + >; + }; + + d7_gpio_pulldown: d7-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AH15) GPIO0_43 */ + AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d8_ehrpwm4_a: d8-ehrpwm4-a-pins { + pinctrl-single,pins = < + /* (AG15) EHRPWM4_A */ + AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5) + >; + }; + + d8_gpio: d8-gpio-pins { + pinctrl-single,pins = < + /* (AG15) GPIO0_48 */ + AM65X_IOPAD(0x00C0, PIN_INPUT, 7) + >; + }; + + d8_gpio_pullup: d8-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AG15) GPIO0_48 */ + AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7) + >; + }; + + d8_gpio_pulldown: d8-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AG15) GPIO0_48 */ + AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7) + >; + }; + + d9_ehrpwm5_a: d9-ehrpwm5-a-pins { + pinctrl-single,pins = < + /* (AD15) EHRPWM5_A */ + AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5) + >; + }; + + d9_gpio: d9-gpio-pins { + pinctrl-single,pins = < + /* (AD15) GPIO0_51 */ + AM65X_IOPAD(0x00CC, PIN_INPUT, 7) + >; + }; + + d9_gpio_pullup: d9-gpio-pullup-pins { + pinctrl-single,pins = < + /* (AD15) GPIO0_51 */ + AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7) + >; + }; + + d9_gpio_pulldown: d9-gpio-pulldown-pins { + pinctrl-single,pins = < + /* (AD15) GPIO0_51 */ + AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7) + >; + }; +}; + +&main_gpio0 { + gpio-line-names = + "main_gpio0-base", "", "", "", "", "", "", "", "", "", + "", "", "", "", "", "", "", "", "", "", + "", "", "", "", "", "", "", "", "", "", + "", "", "", "IO4", "", "IO5", "", "", "IO6", "", + "", "", "", "IO7", "", "", "", "", "IO8", "", + "", "IO9"; +}; + +&wkup_gpio0 { + pinctrl-names = "default"; + pinctrl-0 = + <&arduino_i2c_aio_switch_pins_default>, + <&arduino_io_oe_pins_default>, + <&push_button_pins_default>, + <&db9_com_mode_pins_default>; + gpio-line-names = + /* 0..9 */ + "wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0", + "UART0-enable", "UART0-terminate", "", "WIFI-disable", + /* 10..19 */ + "", "", "", "", "", "", "", "", "", "", + /* 20..29 */ + "", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0", + /* 30..39 */ + "IO1", "IO2", "", "IO3", "IO17-direction", "A5", + "IO16-direction", "IO15-direction", "IO14-direction", "A3", + /* 40..49 */ + "", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13", + "IO11", + /* 50..51 */ + "IO12", "IO10"; +}; + +&wkup_i2c0 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&wkup_i2c0_pins_default>; + clock-frequency = <400000>; +}; + +&mcu_i2c0 { + /* D4200 */ + pcal9535_1: gpio@20 { + compatible = "nxp,pcal9535"; + reg = <0x20>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull", + "A5-pull", "", "", + "IO14-enable", "IO15-enable", "IO16-enable", + "IO17-enable", "IO18-enable", "IO19-enable"; + }; + + /* D4201 */ + pcal9535_2: gpio@21 { + compatible = "nxp,pcal9535"; + reg = <0x21>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "IO0-direction", "IO1-direction", "IO2-direction", + "IO3-direction", "IO4-direction", "IO5-direction", + "IO6-direction", "IO7-direction", + "IO8-direction", "IO9-direction", "IO10-direction", + "IO11-direction", "IO12-direction", "IO13-direction", + "IO19-direction"; + }; + + /* D4202 */ + pcal9535_3: gpio@25 { + compatible = "nxp,pcal9535"; + reg = <0x25>; + #gpio-cells = <2>; + gpio-controller; + gpio-line-names = + "IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull", + "IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull", + "IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull", + "IO12-pull", "IO13-pull"; + }; +}; + +&mcu_uart0 { + status = "okay"; +}; + +&tscadc1 { + status = "okay"; + adc { + ti,adc-channels = <0 1 2 3 4 5>; + }; +}; diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi index ab1dffa5c1c6..402afa4bc1b6 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi @@ -187,434 +187,6 @@ icssg0_emac1: port@1 { }; &wkup_pmx0 { - pinctrl-names = - "default", - "d0-uart0-rxd", "d0-gpio", "d0-gpio-pullup", "d0-gpio-pulldown", - "d1-uart0-txd", "d1-gpio", "d1-gpio-pullup", "d1-gpio-pulldown", - "d2-uart0-ctsn", "d2-gpio", "d2-gpio-pullup", "d2-gpio-pulldown", - "d3-uart0-rtsn", "d3-gpio", "d3-gpio-pullup", "d3-gpio-pulldown", - "d10-spi0-cs0", "d10-gpio", "d10-gpio-pullup", "d10-gpio-pulldown", - "d11-spi0-d0", "d11-gpio", "d11-gpio-pullup", "d11-gpio-pulldown", - "d12-spi0-d1", "d12-gpio", "d12-gpio-pullup", "d12-gpio-pulldown", - "d13-spi0-clk", "d13-gpio", "d13-gpio-pullup", "d13-gpio-pulldown", - "a0-gpio", "a0-gpio-pullup", "a0-gpio-pulldown", - "a1-gpio", "a1-gpio-pullup", "a1-gpio-pulldown", - "a2-gpio", "a2-gpio-pullup", "a2-gpio-pulldown", - "a3-gpio", "a3-gpio-pullup", "a3-gpio-pulldown", - "a4-gpio", "a4-gpio-pullup", "a4-gpio-pulldown", - "a5-gpio", "a5-gpio-pullup", "a5-gpio-pulldown"; - - pinctrl-0 = <&d0_uart0_rxd>; - pinctrl-1 = <&d0_uart0_rxd>; - pinctrl-2 = <&d0_gpio>; - pinctrl-3 = <&d0_gpio_pullup>; - pinctrl-4 = <&d0_gpio_pulldown>; - pinctrl-5 = <&d1_uart0_txd>; - pinctrl-6 = <&d1_gpio>; - pinctrl-7 = <&d1_gpio_pullup>; - pinctrl-8 = <&d1_gpio_pulldown>; - pinctrl-9 = <&d2_uart0_ctsn>; - pinctrl-10 = <&d2_gpio>; - pinctrl-11 = <&d2_gpio_pullup>; - pinctrl-12 = <&d2_gpio_pulldown>; - pinctrl-13 = <&d3_uart0_rtsn>; - pinctrl-14 = <&d3_gpio>; - pinctrl-15 = <&d3_gpio_pullup>; - pinctrl-16 = <&d3_gpio_pulldown>; - pinctrl-17 = <&d10_spi0_cs0>; - pinctrl-18 = <&d10_gpio>; - pinctrl-19 = <&d10_gpio_pullup>; - pinctrl-20 = <&d10_gpio_pulldown>; - pinctrl-21 = <&d11_spi0_d0>; - pinctrl-22 = <&d11_gpio>; - pinctrl-23 = <&d11_gpio_pullup>; - pinctrl-24 = <&d11_gpio_pulldown>; - pinctrl-25 = <&d12_spi0_d1>; - pinctrl-26 = <&d12_gpio>; - pinctrl-27 = <&d12_gpio_pullup>; - pinctrl-28 = <&d12_gpio_pulldown>; - pinctrl-29 = <&d13_spi0_clk>; - pinctrl-30 = <&d13_gpio>; - pinctrl-31 = <&d13_gpio_pullup>; - pinctrl-32 = <&d13_gpio_pulldown>; - pinctrl-33 = <&a0_gpio>; - pinctrl-34 = <&a0_gpio_pullup>; - pinctrl-35 = <&a0_gpio_pulldown>; - pinctrl-36 = <&a1_gpio>; - pinctrl-37 = <&a1_gpio_pullup>; - pinctrl-38 = <&a1_gpio_pulldown>; - pinctrl-39 = <&a2_gpio>; - pinctrl-40 = <&a2_gpio_pullup>; - pinctrl-41 = <&a2_gpio_pulldown>; - pinctrl-42 = <&a3_gpio>; - pinctrl-43 = <&a3_gpio_pullup>; - pinctrl-44 = <&a3_gpio_pulldown>; - pinctrl-45 = <&a4_gpio>; - pinctrl-46 = <&a4_gpio_pullup>; - pinctrl-47 = <&a4_gpio_pulldown>; - pinctrl-48 = <&a5_gpio>; - pinctrl-49 = <&a5_gpio_pullup>; - pinctrl-50 = <&a5_gpio_pulldown>; - - d0_uart0_rxd: d0-uart0-rxd-pins { - pinctrl-single,pins = < - /* (P4) MCU_UART0_RXD */ - AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4) - >; - }; - - d0_gpio: d0-gpio-pins { - pinctrl-single,pins = < - /* (P4) WKUP_GPIO0_29 */ - AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7) - >; - }; - - d0_gpio_pullup: d0-gpio-pullup-pins { - pinctrl-single,pins = < - /* (P4) WKUP_GPIO0_29 */ - AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLUP, 7) - >; - }; - - d0_gpio_pulldown: d0-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (P4) WKUP_GPIO0_29 */ - AM65X_WKUP_IOPAD(0x0044, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d1_uart0_txd: d1-uart0-txd-pins { - pinctrl-single,pins = < - /* (P5) MCU_UART0_TXD */ - AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4) - >; - }; - - d1_gpio: d1-gpio-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_30 */ - AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7) - >; - }; - - d1_gpio_pullup: d1-gpio-pullup-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_30 */ - AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7) - >; - }; - - d1_gpio_pulldown: d1-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_30 */ - AM65X_WKUP_IOPAD(0x0048, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d2_uart0_ctsn: d2-uart0-ctsn-pins { - pinctrl-single,pins = < - /* (P1) MCU_UART0_CTSn */ - AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 4) - >; - }; - - d2_gpio: d2-gpio-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_31 */ - AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7) - >; - }; - - d2_gpio_pullup: d2-gpio-pullup-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_31 */ - AM65X_WKUP_IOPAD(0x004C, PIN_INPUT, 7) - >; - }; - - d2_gpio_pulldown: d2-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (P5) WKUP_GPIO0_31 */ - AM65X_WKUP_IOPAD(0x004C, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d3_uart0_rtsn: d3-uart0-rtsn-pins { - pinctrl-single,pins = < - /* (N3) MCU_UART0_RTSn */ - AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 4) - >; - }; - - d3_gpio: d3-gpio-pins { - pinctrl-single,pins = < - /* (N3) WKUP_GPIO0_33 */ - AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7) - >; - }; - - d3_gpio_pullup: d3-gpio-pullup-pins { - pinctrl-single,pins = < - /* (N3) WKUP_GPIO0_33 */ - AM65X_WKUP_IOPAD(0x0054, PIN_INPUT, 7) - >; - }; - - d3_gpio_pulldown: d3-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (N3) WKUP_GPIO0_33 */ - AM65X_WKUP_IOPAD(0x0054, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d10_spi0_cs0: d10-spi0-cs0-pins { - pinctrl-single,pins = < - /* (Y4) MCU_SPI0_CS0 */ - AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0) - >; - }; - - d10_gpio: d10-gpio-pins { - pinctrl-single,pins = < - /* (Y4) WKUP_GPIO0_51 */ - AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7) - >; - }; - - d10_gpio_pullup: d10-gpio-pullup-pins { - pinctrl-single,pins = < - /* (Y4) WKUP_GPIO0_51 */ - AM65X_WKUP_IOPAD(0x009c, PIN_INPUT, 7) - >; - }; - - d10_gpio_pulldown: d10-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (Y4) WKUP_GPIO0_51 */ - AM65X_WKUP_IOPAD(0x009c, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d11_spi0_d0: d11-spi0-d0-pins { - pinctrl-single,pins = < - /* (Y3) MCU_SPI0_D0 */ - AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0) - >; - }; - - d11_gpio: d11-gpio-pins { - pinctrl-single,pins = < - /* (Y3) WKUP_GPIO0_49 */ - AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7) - >; - }; - - d11_gpio_pullup: d11-gpio-pullup-pins { - pinctrl-single,pins = < - /* (Y3) WKUP_GPIO0_49 */ - AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 7) - >; - }; - - d11_gpio_pulldown: d11-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (Y3) WKUP_GPIO0_49 */ - AM65X_WKUP_IOPAD(0x0094, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d12_spi0_d1: d12-spi0-d1-pins { - pinctrl-single,pins = < - /* (Y2) MCU_SPI0_D1 */ - AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0) - >; - }; - - d12_gpio: d12-gpio-pins { - pinctrl-single,pins = < - /* (Y2) WKUP_GPIO0_50 */ - AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7) - >; - }; - - d12_gpio_pullup: d12-gpio-pullup-pins { - pinctrl-single,pins = < - /* (Y2) WKUP_GPIO0_50 */ - AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 7) - >; - }; - - d12_gpio_pulldown: d12-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (Y2) WKUP_GPIO0_50 */ - AM65X_WKUP_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d13_spi0_clk: d13-spi0-clk-pins { - pinctrl-single,pins = < - /* (Y1) MCU_SPI0_CLK */ - AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0) - >; - }; - - d13_gpio: d13-gpio-pins { - pinctrl-single,pins = < - /* (Y1) WKUP_GPIO0_48 */ - AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7) - >; - }; - - d13_gpio_pullup: d13-gpio-pullup-pins { - pinctrl-single,pins = < - /* (Y1) WKUP_GPIO0_48 */ - AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 7) - >; - }; - - d13_gpio_pulldown: d13-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (Y1) WKUP_GPIO0_48 */ - AM65X_WKUP_IOPAD(0x0090, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a0_gpio: a0-gpio-pins { - pinctrl-single,pins = < - /* (L6) WKUP_GPIO0_45 */ - AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7) - >; - }; - - a0_gpio_pullup: a0-gpio-pullup-pins { - pinctrl-single,pins = < - /* (L6) WKUP_GPIO0_45 */ - AM65X_WKUP_IOPAD(0x0084, PIN_INPUT, 7) - >; - }; - - a0_gpio_pulldown: a0-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (L6) WKUP_GPIO0_45 */ - AM65X_WKUP_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a1_gpio: a1-gpio-pins { - pinctrl-single,pins = < - /* (M6) WKUP_GPIO0_44 */ - AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7) - >; - }; - - a1_gpio_pullup: a1-gpio-pullup-pins { - pinctrl-single,pins = < - /* (M6) WKUP_GPIO0_44 */ - AM65X_WKUP_IOPAD(0x0080, PIN_INPUT, 7) - >; - }; - - a1_gpio_pulldown: a1-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (M6) WKUP_GPIO0_44 */ - AM65X_WKUP_IOPAD(0x0080, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a2_gpio: a2-gpio-pins { - pinctrl-single,pins = < - /* (L5) WKUP_GPIO0_43 */ - AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7) - >; - }; - - a2_gpio_pullup: a2-gpio-pullup-pins { - pinctrl-single,pins = < - /* (L5) WKUP_GPIO0_43 */ - AM65X_WKUP_IOPAD(0x007C, PIN_INPUT, 7) - >; - }; - - a2_gpio_pulldown: a2-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (L5) WKUP_GPIO0_43 */ - AM65X_WKUP_IOPAD(0x007C, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a3_gpio: a3-gpio-pins { - pinctrl-single,pins = < - /* (M5) WKUP_GPIO0_39 */ - AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7) - >; - }; - - a3_gpio_pullup: a3-gpio-pullup-pins { - pinctrl-single,pins = < - /* (M5) WKUP_GPIO0_39 */ - AM65X_WKUP_IOPAD(0x006C, PIN_INPUT, 7) - >; - }; - - a3_gpio_pulldown: a3-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (M5) WKUP_GPIO0_39 */ - AM65X_WKUP_IOPAD(0x006C, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a4_gpio: a4-gpio-pins { - pinctrl-single,pins = < - /* (L2) WKUP_GPIO0_42 */ - AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7) - >; - }; - - a4_gpio_pullup: a4-gpio-pullup-pins { - pinctrl-single,pins = < - /* (L2) WKUP_GPIO0_42 */ - AM65X_WKUP_IOPAD(0x0078, PIN_INPUT, 7) - >; - }; - - a4_gpio_pulldown: a4-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (L2) WKUP_GPIO0_42 */ - AM65X_WKUP_IOPAD(0x0078, PIN_INPUT_PULLDOWN, 7) - >; - }; - - a5_gpio: a5-gpio-pins { - pinctrl-single,pins = < - /* (N5) WKUP_GPIO0_35 */ - AM65X_WKUP_IOPAD(0x005C, PIN_INPUT, 7) - >; - }; - - a5_gpio_pullup: a5-gpio-pullup-pins { - pinctrl-single,pins = < - /* (N5) WKUP_GPIO0_35 */ - AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLUP, 7) - >; - }; - - a5_gpio_pulldown: a5-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (N5) WKUP_GPIO0_35 */ - AM65X_WKUP_IOPAD(0x005C, PIN_INPUT_PULLDOWN, 7) - >; - }; - - wkup_i2c0_pins_default: wkup-i2c0-default-pins { - pinctrl-single,pins = < - /* (AC7) WKUP_I2C0_SCL */ - AM65X_WKUP_IOPAD(0x00e0, PIN_INPUT, 0) - /* (AD6) WKUP_I2C0_SDA */ - AM65X_WKUP_IOPAD(0x00e4, PIN_INPUT, 0) - >; - }; - mcu_i2c0_pins_default: mcu-i2c0-default-pins { pinctrl-single,pins = < /* (AD8) MCU_I2C0_SCL */ @@ -624,13 +196,6 @@ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT, 0) >; }; - arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-default-pins { - pinctrl-single,pins = < - /* (R2) WKUP_GPIO0_21 */ - AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7) - >; - }; - push_button_pins_default: push-button-default-pins { pinctrl-single,pins = < /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */ @@ -638,22 +203,6 @@ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7) >; }; - - arduino_io_oe_pins_default: arduino-io-oe-default-pins { - pinctrl-single,pins = < - /* (N4) WKUP_GPIO0_34 */ - AM65X_WKUP_IOPAD(0x0058, PIN_OUTPUT, 7) - /* (M2) WKUP_GPIO0_36 */ - AM65X_WKUP_IOPAD(0x0060, PIN_OUTPUT, 7) - /* (M3) WKUP_GPIO0_37 */ - AM65X_WKUP_IOPAD(0x0064, PIN_OUTPUT, 7) - /* (M4) WKUP_GPIO0_38 */ - AM65X_WKUP_IOPAD(0x0068, PIN_OUTPUT, 7) - /* (M1) WKUP_GPIO0_41 */ - AM65X_WKUP_IOPAD(0x0074, PIN_OUTPUT, 7) - >; - }; - mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-default-pins { pinctrl-single,pins = < /* (V1) MCU_OSPI0_CLK */ @@ -717,214 +266,6 @@ AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7) }; &main_pmx0 { - pinctrl-names = - "default", - "d4-ehrpwm0-a", "d4-gpio", "d4-gpio-pullup", "d4-gpio-pulldown", - "d5-ehrpwm1-a", "d5-gpio", "d5-gpio-pullup", "d5-gpio-pulldown", - "d6-ehrpwm2-a", "d6-gpio", "d6-gpio-pullup", "d6-gpio-pulldown", - "d7-ehrpwm3-a", "d7-gpio", "d7-gpio-pullup", "d7-gpio-pulldown", - "d8-ehrpwm4-a", "d8-gpio", "d8-gpio-pullup", "d8-gpio-pulldown", - "d9-ehrpwm5-a", "d9-gpio", "d9-gpio-pullup", "d9-gpio-pulldown"; - - pinctrl-0 = <&d4_ehrpwm0_a>; - pinctrl-1 = <&d4_ehrpwm0_a>; - pinctrl-2 = <&d4_gpio>; - pinctrl-3 = <&d4_gpio_pullup>; - pinctrl-4 = <&d4_gpio_pulldown>; - - pinctrl-5 = <&d5_ehrpwm1_a>; - pinctrl-6 = <&d5_gpio>; - pinctrl-7 = <&d5_gpio_pullup>; - pinctrl-8 = <&d5_gpio_pulldown>; - - pinctrl-9 = <&d6_ehrpwm2_a>; - pinctrl-10 = <&d6_gpio>; - pinctrl-11 = <&d6_gpio_pullup>; - pinctrl-12 = <&d6_gpio_pulldown>; - - pinctrl-13 = <&d7_ehrpwm3_a>; - pinctrl-14 = <&d7_gpio>; - pinctrl-15 = <&d7_gpio_pullup>; - pinctrl-16 = <&d7_gpio_pulldown>; - - pinctrl-17 = <&d8_ehrpwm4_a>; - pinctrl-18 = <&d8_gpio>; - pinctrl-19 = <&d8_gpio_pullup>; - pinctrl-20 = <&d8_gpio_pulldown>; - - pinctrl-21 = <&d9_ehrpwm5_a>; - pinctrl-22 = <&d9_gpio>; - pinctrl-23 = <&d9_gpio_pullup>; - pinctrl-24 = <&d9_gpio_pulldown>; - - d4_ehrpwm0_a: d4-ehrpwm0-a-pins { - pinctrl-single,pins = < - /* (AG18) EHRPWM0_A */ - AM65X_IOPAD(0x0084, PIN_OUTPUT, 5) - >; - }; - - d4_gpio: d4-gpio-pins { - pinctrl-single,pins = < - /* (AG18) GPIO0_33 */ - AM65X_IOPAD(0x0084, PIN_INPUT, 7) - >; - }; - - d4_gpio_pullup: d4-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AG18) GPIO0_33 */ - AM65X_IOPAD(0x0084, PIN_INPUT_PULLUP, 7) - >; - }; - - d4_gpio_pulldown: d4-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AG18) GPIO0_33 */ - AM65X_IOPAD(0x0084, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d5_ehrpwm1_a: d5-ehrpwm1-a-pins { - pinctrl-single,pins = < - /* (AF17) EHRPWM1_A */ - AM65X_IOPAD(0x008C, PIN_OUTPUT, 5) - >; - }; - - d5_gpio: d5-gpio-pins { - pinctrl-single,pins = < - /* (AF17) GPIO0_35 */ - AM65X_IOPAD(0x008C, PIN_INPUT, 7) - >; - }; - - d5_gpio_pullup: d5-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AF17) GPIO0_35 */ - AM65X_IOPAD(0x008C, PIN_INPUT_PULLUP, 7) - >; - }; - - d5_gpio_pulldown: d5-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AF17) GPIO0_35 */ - AM65X_IOPAD(0x008C, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d6_ehrpwm2_a: d6-ehrpwm2-a-pins { - pinctrl-single,pins = < - /* (AH16) EHRPWM2_A */ - AM65X_IOPAD(0x0098, PIN_OUTPUT, 5) - >; - }; - - d6_gpio: d6-gpio-pins { - pinctrl-single,pins = < - /* (AH16) GPIO0_38 */ - AM65X_IOPAD(0x0098, PIN_INPUT, 7) - >; - }; - - d6_gpio_pullup: d6-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AH16) GPIO0_38 */ - AM65X_IOPAD(0x0098, PIN_INPUT_PULLUP, 7) - >; - }; - - d6_gpio_pulldown: d6-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AH16) GPIO0_38 */ - AM65X_IOPAD(0x0098, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d7_ehrpwm3_a: d7-ehrpwm3-a-pins { - pinctrl-single,pins = < - /* (AH15) EHRPWM3_A */ - AM65X_IOPAD(0x00AC, PIN_OUTPUT, 5) - >; - }; - - d7_gpio: d7-gpio-pins { - pinctrl-single,pins = < - /* (AH15) GPIO0_43 */ - AM65X_IOPAD(0x00AC, PIN_INPUT, 7) - >; - }; - - d7_gpio_pullup: d7-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AH15) GPIO0_43 */ - AM65X_IOPAD(0x00AC, PIN_INPUT_PULLUP, 7) - >; - }; - - d7_gpio_pulldown: d7-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AH15) GPIO0_43 */ - AM65X_IOPAD(0x00AC, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d8_ehrpwm4_a: d8-ehrpwm4-a-pins { - pinctrl-single,pins = < - /* (AG15) EHRPWM4_A */ - AM65X_IOPAD(0x00C0, PIN_OUTPUT, 5) - >; - }; - - d8_gpio: d8-gpio-pins { - pinctrl-single,pins = < - /* (AG15) GPIO0_48 */ - AM65X_IOPAD(0x00C0, PIN_INPUT, 7) - >; - }; - - d8_gpio_pullup: d8-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AG15) GPIO0_48 */ - AM65X_IOPAD(0x00C0, PIN_INPUT_PULLUP, 7) - >; - }; - - d8_gpio_pulldown: d8-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AG15) GPIO0_48 */ - AM65X_IOPAD(0x00C0, PIN_INPUT_PULLDOWN, 7) - >; - }; - - d9_ehrpwm5_a: d9-ehrpwm5-a-pins { - pinctrl-single,pins = < - /* (AD15) EHRPWM5_A */ - AM65X_IOPAD(0x00CC, PIN_OUTPUT, 5) - >; - }; - - d9_gpio: d9-gpio-pins { - pinctrl-single,pins = < - /* (AD15) GPIO0_51 */ - AM65X_IOPAD(0x00CC, PIN_INPUT, 7) - >; - }; - - d9_gpio_pullup: d9-gpio-pullup-pins { - pinctrl-single,pins = < - /* (AD15) GPIO0_51 */ - AM65X_IOPAD(0x00CC, PIN_INPUT_PULLUP, 7) - >; - }; - - d9_gpio_pulldown: d9-gpio-pulldown-pins { - pinctrl-single,pins = < - /* (AD15) GPIO0_51 */ - AM65X_IOPAD(0x00CC, PIN_INPUT_PULLDOWN, 7) - >; - }; - main_pcie_enable_pins_default: main-pcie-enable-default-pins { pinctrl-single,pins = < AM65X_IOPAD(0x01c4, PIN_INPUT_PULLUP, 7) /* (AH13) GPIO1_17 */ @@ -1083,57 +424,11 @@ &main_uart1 { pinctrl-0 = <&main_uart1_pins_default>; }; -&mcu_uart0 { - status = "okay"; -}; - -&main_gpio0 { - gpio-line-names = - "main_gpio0-base", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", - "", "", "", "", "", "", "", "", "", "", - "", "", "", "IO4", "", "IO5", "", "", "IO6", "", - "", "", "", "IO7", "", "", "", "", "IO8", "", - "", "IO9"; -}; - &main_gpio1 { pinctrl-names = "default"; pinctrl-0 = <&main_pcie_enable_pins_default>; }; -&wkup_gpio0 { - pinctrl-names = "default"; - pinctrl-0 = - <&arduino_i2c_aio_switch_pins_default>, - <&arduino_io_oe_pins_default>, - <&push_button_pins_default>, - <&db9_com_mode_pins_default>; - gpio-line-names = - /* 0..9 */ - "wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0", - "UART0-enable", "UART0-terminate", "", "WIFI-disable", - /* 10..19 */ - "", "", "", "", "", "", "", "", "", "", - /* 20..29 */ - "", "A4A5-I2C-mux", "", "", "", "USER-button", "", "", "","IO0", - /* 30..39 */ - "IO1", "IO2", "", "IO3", "IO17-direction", "A5", - "IO16-direction", "IO15-direction", "IO14-direction", "A3", - /* 40..49 */ - "", "IO18-direction", "A4", "A2", "A1", "A0", "", "", "IO13", - "IO11", - /* 50..51 */ - "IO12", "IO10"; -}; - -&wkup_i2c0 { - status = "okay"; - pinctrl-names = "default"; - pinctrl-0 = <&wkup_i2c0_pins_default>; - clock-frequency = <400000>; -}; - &mcu_i2c0 { status = "okay"; pinctrl-names = "default"; @@ -1151,47 +446,6 @@ psu: regulator@60 { ti,vsel1-state-high; ti,enable-vout-discharge; }; - - /* D4200 */ - pcal9535_1: gpio@20 { - compatible = "nxp,pcal9535"; - reg = <0x20>; - #gpio-cells = <2>; - gpio-controller; - gpio-line-names = - "A0-pull", "A1-pull", "A2-pull", "A3-pull", "A4-pull", - "A5-pull", "", "", - "IO14-enable", "IO15-enable", "IO16-enable", - "IO17-enable", "IO18-enable", "IO19-enable"; - }; - - /* D4201 */ - pcal9535_2: gpio@21 { - compatible = "nxp,pcal9535"; - reg = <0x21>; - #gpio-cells = <2>; - gpio-controller; - gpio-line-names = - "IO0-direction", "IO1-direction", "IO2-direction", - "IO3-direction", "IO4-direction", "IO5-direction", - "IO6-direction", "IO7-direction", - "IO8-direction", "IO9-direction", "IO10-direction", - "IO11-direction", "IO12-direction", "IO13-direction", - "IO19-direction"; - }; - - /* D4202 */ - pcal9535_3: gpio@25 { - compatible = "nxp,pcal9535"; - reg = <0x25>; - #gpio-cells = <2>; - gpio-controller; - gpio-line-names = - "IO0-pull", "IO1-pull", "IO2-pull", "IO3-pull", - "IO4-pull", "IO5-pull", "IO6-pull", "IO7-pull", - "IO8-pull", "IO9-pull", "IO10-pull", "IO11-pull", - "IO12-pull", "IO13-pull"; - }; }; &main_i2c0 { @@ -1292,13 +546,6 @@ &mcu_spi0 { ti,pindir-d0-out-d1-in; }; -&tscadc1 { - status = "okay"; - adc { - ti,adc-channels = <0 1 2 3 4 5>; - }; -}; - &ospi0 { status = "okay"; pinctrl-names = "default"; diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi index 2300abe69e94..8c438f101c99 100644 --- a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic-common.dtsi @@ -10,6 +10,7 @@ */ #include "k3-am65-iot2050-common.dtsi" +#include "k3-am65-iot2050-arduino-connector.dtsi" / { memory@80000000 { diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts index 1e5d4d98b69b..2401cbe2b66c 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-m2.dts @@ -15,6 +15,7 @@ #include "k3-am6548-iot2050-advanced-common.dtsi" #include "k3-am65-iot2050-common-pg2.dtsi" +#include "k3-am65-iot2050-arduino-connector.dtsi" / { compatible = "siemens,iot2050-advanced-m2", "ti,am654"; diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts index a8ce8c891894..c1205feef54e 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-pg2.dts @@ -17,6 +17,7 @@ #include "k3-am6548-iot2050-advanced-common.dtsi" #include "k3-am65-iot2050-common-pg2.dtsi" +#include "k3-am65-iot2050-arduino-connector.dtsi" / { compatible = "siemens,iot2050-advanced-pg2", "ti,am654"; diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts index 077f165bdc68..b66965f992b9 100644 --- a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts @@ -17,6 +17,7 @@ #include "k3-am6548-iot2050-advanced-common.dtsi" #include "k3-am65-iot2050-common-pg1.dtsi" +#include "k3-am65-iot2050-arduino-connector.dtsi" / { compatible = "siemens,iot2050-advanced", "ti,am654"; -- 2.35.3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits 2023-12-18 16:35 ` [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits Jan Kiszka @ 2023-12-19 7:51 ` Krzysztof Kozlowski 2023-12-19 8:06 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 7:51 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su On 18/12/2023 17:35, Jan Kiszka wrote: > From: Jan Kiszka <jan.kiszka@siemens.com> > > A new variant is to be added which will not have a arduino connector > like the existing ones. Factor out all bits that are specific to this > connector. > > The split is not perfect because wkup_gpio0 is defined based on what is > common to all variants having the connector, thus containing also > connector-unrelated information. But this is still cleaner than > replicating this node into all 4 variants. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++ > .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 ----------------- Please use proper -B/-M/-C arguments so code movements will be detected. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits 2023-12-19 7:51 ` Krzysztof Kozlowski @ 2023-12-19 8:06 ` Jan Kiszka 2023-12-19 8:12 ` Krzysztof Kozlowski 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 8:06 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su On 19.12.23 08:51, Krzysztof Kozlowski wrote: > On 18/12/2023 17:35, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> A new variant is to be added which will not have a arduino connector >> like the existing ones. Factor out all bits that are specific to this >> connector. >> >> The split is not perfect because wkup_gpio0 is defined based on what is >> common to all variants having the connector, thus containing also >> connector-unrelated information. But this is still cleaner than >> replicating this node into all 4 variants. >> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++ >> .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 ----------------- > > Please use proper -B/-M/-C arguments so code movements will be detected. > Those are in place but have no impact, likely because the source file is still ~700 lines after the shuffling. Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits 2023-12-19 8:06 ` Jan Kiszka @ 2023-12-19 8:12 ` Krzysztof Kozlowski 2023-12-19 8:18 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 8:12 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su On 19/12/2023 09:06, Jan Kiszka wrote: > On 19.12.23 08:51, Krzysztof Kozlowski wrote: >> On 18/12/2023 17:35, Jan Kiszka wrote: >>> From: Jan Kiszka <jan.kiszka@siemens.com> >>> >>> A new variant is to be added which will not have a arduino connector >>> like the existing ones. Factor out all bits that are specific to this >>> connector. >>> >>> The split is not perfect because wkup_gpio0 is defined based on what is >>> common to all variants having the connector, thus containing also >>> connector-unrelated information. But this is still cleaner than >>> replicating this node into all 4 variants. >>> >>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>> --- >>> .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++ >>> .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 ----------------- >> >> Please use proper -B/-M/-C arguments so code movements will be detected. >> > > Those are in place but have no impact, likely because the source file is In place as what? > still ~700 lines after the shuffling. The original file has 720 lines, so if you move 750 (!) of them, I can hardly believe the rename cannot be detected. You are basically moving 90% or 95% of file, so this must be represented with proper diff. Your patches do not apply on next, neither on master, so it is tricky to check. How do you expect us to review it? Compare line by line? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits 2023-12-19 8:12 ` Krzysztof Kozlowski @ 2023-12-19 8:18 ` Jan Kiszka 0 siblings, 0 replies; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 8:18 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su On 19.12.23 09:12, Krzysztof Kozlowski wrote: > On 19/12/2023 09:06, Jan Kiszka wrote: >> On 19.12.23 08:51, Krzysztof Kozlowski wrote: >>> On 18/12/2023 17:35, Jan Kiszka wrote: >>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>> >>>> A new variant is to be added which will not have a arduino connector >>>> like the existing ones. Factor out all bits that are specific to this >>>> connector. >>>> >>>> The split is not perfect because wkup_gpio0 is defined based on what is >>>> common to all variants having the connector, thus containing also >>>> connector-unrelated information. But this is still cleaner than >>>> replicating this node into all 4 variants. >>>> >>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >>>> --- >>>> .../ti/k3-am65-iot2050-arduino-connector.dtsi | 768 ++++++++++++++++++ >>>> .../boot/dts/ti/k3-am65-iot2050-common.dtsi | 753 ----------------- >>> >>> Please use proper -B/-M/-C arguments so code movements will be detected. >>> >> >> Those are in place but have no impact, likely because the source file is > > In place as what? > >> still ~700 lines after the shuffling. > > The original file has 720 lines, so if you move 750 (!) of them, I can The original file has 1446 lines - I should have noted that this goes on top of [1] which is already pending for 6.8 in Nishanth's tree, sorry. Jan [1] https://lore.kernel.org/lkml/cover.1699087938.git.jan.kiszka@siemens.com/ > hardly believe the rename cannot be detected. You are basically moving > 90% or 95% of file, so this must be represented with proper diff. > > Your patches do not apply on next, neither on master, so it is tricky to > check. > > How do you expect us to review it? Compare line by line? > > Best regards, > Krzysztof > -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka ` (2 preceding siblings ...) 2023-12-18 16:35 ` [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits Jan Kiszka @ 2023-12-18 16:36 ` Jan Kiszka 2023-12-19 7:54 ` Krzysztof Kozlowski 3 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-18 16:36 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su, Chao Zeng, Li Hua Qian From: Baocheng Su <baocheng.su@siemens.com> Main differences between the new variant and Advanced PG2: 1. Arduino interface is removed. Instead, an new ASIC is added for communicating with PLC 1200 signal modules. 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is avaiable. 3. DP interface is tailored down. Instead, to communicate with the PLC 1200 signal modules, a USB 3.0 type B connector is added but the signal is not USB. 4. DDR size is increased to 4 GB. 5. Two sensors are added, one tilt sensor and one light sensor. The light sensor it not yet added to the DT at this stage as it depends on to-be-added bindings. Co-developed-by: Chao Zeng <chao.zeng@siemens.com> Signed-off-by: Chao Zeng <chao.zeng@siemens.com> Co-developed-by: Li Hua Qian <huaqian.li@siemens.com> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com> Signed-off-by: Baocheng Su <baocheng.su@siemens.com> [Jan: rebase over arduino refactoring, split-out light sensor] Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- arch/arm64/boot/dts/ti/Makefile | 1 + .../dts/ti/k3-am6548-iot2050-advanced-sm.dts | 210 ++++++++++++++++++ 2 files changed, 211 insertions(+) create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile index 77a347f9f47d..9b15eaad284c 100644 --- a/arch/arm64/boot/dts/ti/Makefile +++ b/arch/arm64/boot/dts/ti/Makefile @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts new file mode 100644 index 000000000000..ab3eef683890 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts @@ -0,0 +1,210 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (c) Siemens AG, 2023 + * + * Authors: + * Baocheng Su <baocheng.su@siemens.com> + * Chao Zeng <chao.zeng@siemens.com> + * Huaqian Li <huaqian.li@siemens.com> + * + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2 + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30 + * + * Product homepage: + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html + */ + +/dts-v1/; + +#include "k3-am6548-iot2050-advanced-common.dtsi" +#include "k3-am65-iot2050-common-pg2.dtsi" + +/ { + compatible = "siemens,iot2050-advanced-sm", "ti,am654"; + model = "SIMATIC IOT2050 Advanced SM"; + + memory@80000000 { + device_type = "memory"; + /* 4G RAM */ + reg = <0x00000000 0x80000000 0x00000000 0x80000000>, + <0x00000008 0x80000000 0x00000000 0x80000000>; + }; + + aliases { + spi1 = &main_spi0; + }; + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>; + + user-led1-red { + gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>; + }; + + user-led1-green { + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; + }; + }; +}; + +&main_pmx0 { + main_pcie_enable_pins_default: main-pcie-enable-default-pins { + pinctrl-single,pins = < + AM65X_IOPAD(0x01d8, PIN_OUTPUT, 7) /* (AH12) GPIO1_22 */ + >; + }; + + main_spi0_pins: main-spi0-default-pins { + pinctrl-single,pins = < + AM65X_IOPAD(0x01c4, PIN_INPUT, 0) /* (AH13) SPI0_CLK */ + AM65X_IOPAD(0x01c8, PIN_INPUT, 0) /* (AE13) SPI0_D0 */ + AM65X_IOPAD(0x01cc, PIN_INPUT, 0) /* (AD13) SPI0_D1 */ + AM65X_IOPAD(0x01bc, PIN_OUTPUT, 0) /* (AG13) SPI0_CS0 */ + >; + }; +}; + +&main_pmx1 { + asic_spi_mux_ctrl_pin: asic-spi-mux-ctrl-default-pins { + pinctrl-single,pins = < + AM65X_IOPAD(0x0010, PIN_OUTPUT, 7) /* (D21) GPIO1_86 */ + >; + }; +}; + +&wkup_pmx0 { + user1_led_pins: user1-led-default-pins { + pinctrl-single,pins = < + /* (AB1) WKUP_UART0_RXD:WKUP_GPIO0_52, as USER 1 led red */ + AM65X_WKUP_IOPAD(0x00a0, PIN_OUTPUT, 7) + /* (AB5) WKUP_UART0_TXD:WKUP_GPIO0_53, as USER 1 led green */ + AM65X_WKUP_IOPAD(0x00a4, PIN_OUTPUT, 7) + >; + }; + + soc_asic_pins: soc-asic-default-pins { + pinctrl-single,pins = < + AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 7) /* (P4) WKUP_GPIO0_29 */ + AM65X_WKUP_IOPAD(0x0048, PIN_INPUT, 7) /* (P5) WKUP_GPIO0_30 */ + AM65X_WKUP_IOPAD(0x004c, PIN_INPUT, 7) /* (P1) WKUP_GPIO0_31 */ + >; + }; +}; + +&main_gpio0 { + gpio-line-names = "main_gpio0-base"; +}; + +&main_gpio1 { + pinctrl-names = "default"; + pinctrl-0 = + <&cp2102n_reset_pin_default>, + <&main_pcie_enable_pins_default>, + <&asic_spi_mux_ctrl_pin>; + gpio-line-names = + /* 0..9 */ + "", "", "", "", "", "", "", "", "", "", + /* 10..19 */ + "", "", "", "", "", "", "", "", "", "", + /* 20..29 */ + "", "", "", "", "CP2102N-RESET", "", "", "", "", "", + /* 30..39 */ + "", "", "", "", "", "", "", "", "", "", + /* 40..49 */ + "", "", "", "", "", "", "", "", "", "", + /* 50..59 */ + "", "", "", "", "", "", "", "", "", "", + /* 60..69 */ + "", "", "", "", "", "", "", "", "", "", + /* 70..79 */ + "", "", "", "", "", "", "", "", "", "", + /* 80..86 */ + "", "", "", "", "", "", "ASIC-spi-mux-ctrl"; +}; + +&wkup_gpio0 { + pinctrl-names = "default"; + pinctrl-0 = + <&push_button_pins_default>, + <&db9_com_mode_pins_default>, + <&soc_asic_pins>; + gpio-line-names = + /* 0..9 */ + "wkup_gpio0-base", "", "", "", "UART0-mode1", "UART0-mode0", + "UART0-enable", "UART0-terminate", "", "WIFI-disable", + /* 10..19 */ + "", "", "", "", "", "", "", "", "", "", + /* 20..29 */ + "", "", "", "", "", "USER-button", "", "", "","ASIC-gpio-0", + /* 30..31 */ + "ASIC-gpio-1", "ASIC-gpio-2"; +}; + +&main_spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&main_spi0_pins>; + + #address-cells = <1>; + #size-cells= <0>; +}; + +&mcu_spi0 { + pinctrl-names = "default"; + pinctrl-0 = <&mcu_spi0_pins_default>; +}; + +&main_i2c3 { + accelerometer: lsm6dso@6a { + compatible = "st,lsm6dso"; + reg = <0x6a>; + }; + + /delete-node/ edp-bridge@f; +}; + +&dss { + status = "disabled"; +}; + +&dss_ports { + /delete-node/ port@1; +}; + +&serdes0 { + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; +}; + +&serdes1 { + status = "disabled"; +}; + +&pcie0_rc { + pinctrl-names = "default"; + pinctrl-0 = <&minipcie_pins_default>; + + num-lanes = <1>; + phys = <&serdes0 PHY_TYPE_PCIE 1>; + phy-names = "pcie-phy0"; + reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>; + status = "okay"; +}; + +&pcie1_rc { + status = "disabled"; +}; + +&dwc3_0 { + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ + /delete-property/ phys; + /delete-property/ phy-names; +}; + +&usb0 { + maximum-speed = "high-speed"; + /delete-property/ snps,dis-u1-entry-quirk; + /delete-property/ snps,dis-u2-entry-quirk; +}; -- 2.35.3 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-18 16:36 ` [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant Jan Kiszka @ 2023-12-19 7:54 ` Krzysztof Kozlowski 2023-12-19 8:22 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 7:54 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, linux-kernel, devicetree, Bao Cheng Su, Chao Zeng, Li Hua Qian On 18/12/2023 17:36, Jan Kiszka wrote: > From: Baocheng Su <baocheng.su@siemens.com> > > Main differences between the new variant and Advanced PG2: Please use subject prefixes matching the subsystem. You can get them for example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory your patch is touching. > > 1. Arduino interface is removed. Instead, an new ASIC is added for > communicating with PLC 1200 signal modules. > 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is > avaiable. > 3. DP interface is tailored down. Instead, to communicate with the > PLC 1200 signal modules, a USB 3.0 type B connector is added but the > signal is not USB. > 4. DDR size is increased to 4 GB. > 5. Two sensors are added, one tilt sensor and one light sensor. > > The light sensor it not yet added to the DT at this stage as it depends > on to-be-added bindings. > > Co-developed-by: Chao Zeng <chao.zeng@siemens.com> > Signed-off-by: Chao Zeng <chao.zeng@siemens.com> > Co-developed-by: Li Hua Qian <huaqian.li@siemens.com> > Signed-off-by: Li Hua Qian <huaqian.li@siemens.com> > Signed-off-by: Baocheng Su <baocheng.su@siemens.com> > [Jan: rebase over arduino refactoring, split-out light sensor] > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> > --- > arch/arm64/boot/dts/ti/Makefile | 1 + > .../dts/ti/k3-am6548-iot2050-advanced-sm.dts | 210 ++++++++++++++++++ > 2 files changed, 211 insertions(+) > create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts > > diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile > index 77a347f9f47d..9b15eaad284c 100644 > --- a/arch/arm64/boot/dts/ti/Makefile > +++ b/arch/arm64/boot/dts/ti/Makefile > @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb > +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb > dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb > diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts > new file mode 100644 > index 000000000000..ab3eef683890 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts > @@ -0,0 +1,210 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (c) Siemens AG, 2023 > + * > + * Authors: > + * Baocheng Su <baocheng.su@siemens.com> > + * Chao Zeng <chao.zeng@siemens.com> > + * Huaqian Li <huaqian.li@siemens.com> > + * > + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2 > + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30 > + * > + * Product homepage: > + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html > + */ > + > +/dts-v1/; > + > +#include "k3-am6548-iot2050-advanced-common.dtsi" > +#include "k3-am65-iot2050-common-pg2.dtsi" > + > +/ { > + compatible = "siemens,iot2050-advanced-sm", "ti,am654"; > + model = "SIMATIC IOT2050 Advanced SM"; > + > + memory@80000000 { > + device_type = "memory"; > + /* 4G RAM */ > + reg = <0x00000000 0x80000000 0x00000000 0x80000000>, > + <0x00000008 0x80000000 0x00000000 0x80000000>; > + }; > + > + aliases { > + spi1 = &main_spi0; > + }; > + > + leds { > + compatible = "gpio-leds"; > + pinctrl-names = "default"; > + pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>; > + > + user-led1-red { led-0 > + gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>; Missing function, missing color. Color goes as property, not as node name. > + }; > + > + user-led1-green { led-1 > + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; Ditto > + > +&dwc3_0 { > + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ > + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ > + /delete-property/ phys; > + /delete-property/ phy-names; If your board need to remove phys from the SoC node, something is wrong. Either your board or SoC. Any removal of properties in DTS is weird and unexpected. It deserves comments. > +}; > + > +&usb0 { > + maximum-speed = "high-speed"; > + /delete-property/ snps,dis-u1-entry-quirk; > + /delete-property/ snps,dis-u2-entry-quirk; Same questions. If SoC has quirks, how can your board be fixed? It's SoC property... or you are using different SoC. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 7:54 ` Krzysztof Kozlowski @ 2023-12-19 8:22 ` Jan Kiszka 2023-12-19 8:48 ` Krzysztof Kozlowski 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 8:22 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 08:54, Krzysztof Kozlowski wrote: > On 18/12/2023 17:36, Jan Kiszka wrote: >> From: Baocheng Su <baocheng.su@siemens.com> >> >> Main differences between the new variant and Advanced PG2: > > Please use subject prefixes matching the subsystem. You can get them for > example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory > your patch is touching. > >> >> 1. Arduino interface is removed. Instead, an new ASIC is added for >> communicating with PLC 1200 signal modules. >> 2. USB 3.0 type A connector is removed, only USB 2.0 type A connector is >> avaiable. >> 3. DP interface is tailored down. Instead, to communicate with the >> PLC 1200 signal modules, a USB 3.0 type B connector is added but the >> signal is not USB. >> 4. DDR size is increased to 4 GB. >> 5. Two sensors are added, one tilt sensor and one light sensor. >> >> The light sensor it not yet added to the DT at this stage as it depends >> on to-be-added bindings. >> >> Co-developed-by: Chao Zeng <chao.zeng@siemens.com> >> Signed-off-by: Chao Zeng <chao.zeng@siemens.com> >> Co-developed-by: Li Hua Qian <huaqian.li@siemens.com> >> Signed-off-by: Li Hua Qian <huaqian.li@siemens.com> >> Signed-off-by: Baocheng Su <baocheng.su@siemens.com> >> [Jan: rebase over arduino refactoring, split-out light sensor] >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> >> --- >> arch/arm64/boot/dts/ti/Makefile | 1 + >> .../dts/ti/k3-am6548-iot2050-advanced-sm.dts | 210 ++++++++++++++++++ >> 2 files changed, 211 insertions(+) >> create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts >> >> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile >> index 77a347f9f47d..9b15eaad284c 100644 >> --- a/arch/arm64/boot/dts/ti/Makefile >> +++ b/arch/arm64/boot/dts/ti/Makefile >> @@ -53,6 +53,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic-pg2.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-m2.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-pg2.dtb >> +dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced-sm.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am654-gp-evm.dtb >> dtb-$(CONFIG_ARCH_K3) += k3-am654-evm.dtb >> diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts >> new file mode 100644 >> index 000000000000..ab3eef683890 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced-sm.dts >> @@ -0,0 +1,210 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Copyright (c) Siemens AG, 2023 >> + * >> + * Authors: >> + * Baocheng Su <baocheng.su@siemens.com> >> + * Chao Zeng <chao.zeng@siemens.com> >> + * Huaqian Li <huaqian.li@siemens.com> >> + * >> + * AM6548-based (quad-core) IOT2050 SM variant, Product Generation 2 >> + * 4 GB RAM, 16 GB eMMC, USB-serial converter on connector X30 >> + * >> + * Product homepage: >> + * https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html >> + */ >> + >> +/dts-v1/; >> + >> +#include "k3-am6548-iot2050-advanced-common.dtsi" >> +#include "k3-am65-iot2050-common-pg2.dtsi" >> + >> +/ { >> + compatible = "siemens,iot2050-advanced-sm", "ti,am654"; >> + model = "SIMATIC IOT2050 Advanced SM"; >> + >> + memory@80000000 { >> + device_type = "memory"; >> + /* 4G RAM */ >> + reg = <0x00000000 0x80000000 0x00000000 0x80000000>, >> + <0x00000008 0x80000000 0x00000000 0x80000000>; >> + }; >> + >> + aliases { >> + spi1 = &main_spi0; >> + }; >> + >> + leds { >> + compatible = "gpio-leds"; >> + pinctrl-names = "default"; >> + pinctrl-0 = <&leds_pins_default>, <&user1_led_pins>; >> + >> + user-led1-red { > > led-0 > >> + gpios = <&wkup_gpio0 52 GPIO_ACTIVE_HIGH>; > > Missing function, missing color. Color goes as property, not as node name. > >> + }; >> + >> + user-led1-green { > > led-1 > >> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; > > Ditto > This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, not introducing new ones. We can add the color properties in a separate patch, but the node names are now part of the kernel ABI. Changing them would break existing userland. > >> + >> +&dwc3_0 { >> + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ >> + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ >> + /delete-property/ phys; >> + /delete-property/ phy-names; > > If your board need to remove phys from the SoC node, something is wrong. > Either your board or SoC. > > Any removal of properties in DTS is weird and unexpected. It deserves > comments. This goes along disabling USB3 which is by default enabled via k3-am65-iot2050-common-pg2.dtsi > >> +}; >> + >> +&usb0 { >> + maximum-speed = "high-speed"; >> + /delete-property/ snps,dis-u1-entry-quirk; >> + /delete-property/ snps,dis-u2-entry-quirk; > > Same questions. If SoC has quirks, how can your board be fixed? It's SoC > property... or you are using different SoC. > Same story. Baocheng, Zeng Chao, correct me if there is more behind that. Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 8:22 ` Jan Kiszka @ 2023-12-19 8:48 ` Krzysztof Kozlowski 2023-12-19 9:03 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 8:48 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 09:22, Jan Kiszka wrote: >> >>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >> >> Ditto >> > > This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, > not introducing new ones. We can add the color properties in a separate Then why aren't you overriding by phandle/label? > patch, but the node names are now part of the kernel ABI. Changing them > would break existing userland. You mean label. Why node names became the ABI? Which interface exposes them? > >> >>> + >>> +&dwc3_0 { >>> + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ >>> + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ >>> + /delete-property/ phys; >>> + /delete-property/ phy-names; >> >> If your board need to remove phys from the SoC node, something is wrong. >> Either your board or SoC. >> >> Any removal of properties in DTS is weird and unexpected. It deserves >> comments. > > This goes along disabling USB3 which is by default enabled via > k3-am65-iot2050-common-pg2.dtsi Isn't this mistake? Common part enables only these pieces which are working in common hardware SoM. If your common part of hardware, which DTSI should represent, has USB3 then why is it being disabled here? If common hardware design does not have USB3, then why is it being enabled in DTSI? > Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 8:48 ` Krzysztof Kozlowski @ 2023-12-19 9:03 ` Jan Kiszka 2023-12-19 9:45 ` Krzysztof Kozlowski 2023-12-19 9:50 ` Krzysztof Kozlowski 0 siblings, 2 replies; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 9:03 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 09:48, Krzysztof Kozlowski wrote: > On 19/12/2023 09:22, Jan Kiszka wrote: >>> >>>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >>> >>> Ditto >>> >> >> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, >> not introducing new ones. We can add the color properties in a separate > > > Then why aren't you overriding by phandle/label? > We could do that as well if we added labels first (they don't exist so far). Not seeing any difference, though. >> patch, but the node names are now part of the kernel ABI. Changing them >> would break existing userland. > > You mean label. Why node names became the ABI? Which interface exposes them? root@iot2050-debian:~# ls -l /sys/class/leds/ total 0 lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red >>>> + >>>> +&dwc3_0 { >>>> + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ >>>> + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ >>>> + /delete-property/ phys; >>>> + /delete-property/ phy-names; >>> >>> If your board need to remove phys from the SoC node, something is wrong. >>> Either your board or SoC. >>> >>> Any removal of properties in DTS is weird and unexpected. It deserves >>> comments. >> >> This goes along disabling USB3 which is by default enabled via >> k3-am65-iot2050-common-pg2.dtsi > > Isn't this mistake? Common part enables only these pieces which are > working in common hardware SoM. If your common part of hardware, which > DTSI should represent, has USB3 then why is it being disabled here? If > common hardware design does not have USB3, then why is it being enabled > in DTSI? It's a trade-off between adding yet another dtsi for those widely common bits vs. adjusting the differences of only one variant from that. We do the same for the Display Port so far. Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:03 ` Jan Kiszka @ 2023-12-19 9:45 ` Krzysztof Kozlowski 2023-12-19 9:50 ` Krzysztof Kozlowski 1 sibling, 0 replies; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 9:45 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 10:03, Jan Kiszka wrote: > On 19.12.23 09:48, Krzysztof Kozlowski wrote: >> On 19/12/2023 09:22, Jan Kiszka wrote: >>>> >>>>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >>>> >>>> Ditto >>>> >>> >>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, >>> not introducing new ones. We can add the color properties in a separate >> >> >> Then why aren't you overriding by phandle/label? >> > > We could do that as well if we added labels first (they don't exist so > far). Not seeing any difference, though. > >>> patch, but the node names are now part of the kernel ABI. Changing them >>> would break existing userland. >> >> You mean label. Why node names became the ABI? Which interface exposes them? > > root@iot2050-debian:~# ls -l /sys/class/leds/ > total 0 > lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: > lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: > lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red > >>>>> + >>>>> +&dwc3_0 { >>>>> + assigned-clock-parents = <&k3_clks 151 4>, /* set REF_CLK to 20MHz i.e. PER0_PLL/48 */ >>>>> + <&k3_clks 151 9>; /* set PIPE3_TXB_CLK to CLK_12M_RC/256 (for HS only) */ >>>>> + /delete-property/ phys; >>>>> + /delete-property/ phy-names; >>>> >>>> If your board need to remove phys from the SoC node, something is wrong. >>>> Either your board or SoC. >>>> >>>> Any removal of properties in DTS is weird and unexpected. It deserves >>>> comments. >>> >>> This goes along disabling USB3 which is by default enabled via >>> k3-am65-iot2050-common-pg2.dtsi >> >> Isn't this mistake? Common part enables only these pieces which are >> working in common hardware SoM. If your common part of hardware, which >> DTSI should represent, has USB3 then why is it being disabled here? If >> common hardware design does not have USB3, then why is it being enabled >> in DTSI? > > It's a trade-off between adding yet another dtsi for those widely > common bits vs. adjusting the differences of only one variant from You don't need to add one more DTSI to achieve proper architecture of DTS/DTSI split. > that. We do the same for the Display Port so far. DTSI represents common piece of hardware, like SoM or re-usable blocks, not trade-off. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:03 ` Jan Kiszka 2023-12-19 9:45 ` Krzysztof Kozlowski @ 2023-12-19 9:50 ` Krzysztof Kozlowski 2023-12-19 9:54 ` Jan Kiszka 1 sibling, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 9:50 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 10:03, Jan Kiszka wrote: > On 19.12.23 09:48, Krzysztof Kozlowski wrote: >> On 19/12/2023 09:22, Jan Kiszka wrote: >>>> >>>>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >>>> >>>> Ditto >>>> >>> >>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, >>> not introducing new ones. We can add the color properties in a separate >> >> >> Then why aren't you overriding by phandle/label? >> > > We could do that as well if we added labels first (they don't exist so > far). Not seeing any difference, though. Confusion? Your code suggests new node, thus you got review like you got. > >>> patch, but the node names are now part of the kernel ABI. Changing them >>> would break existing userland. >> >> You mean label. Why node names became the ABI? Which interface exposes them? > > root@iot2050-debian:~# ls -l /sys/class/leds/ > total 0 > lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: > lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: > lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green > lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red I replied too fast previous and did not include answer here: You have label for that... Somehow all these nodes are half-baked, without all the expected properties and now you call node name as ABI. The node name is not the ABI. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:50 ` Krzysztof Kozlowski @ 2023-12-19 9:54 ` Jan Kiszka 2023-12-19 9:56 ` Jan Kiszka 2023-12-19 9:58 ` Krzysztof Kozlowski 0 siblings, 2 replies; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 9:54 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 10:50, Krzysztof Kozlowski wrote: > On 19/12/2023 10:03, Jan Kiszka wrote: >> On 19.12.23 09:48, Krzysztof Kozlowski wrote: >>> On 19/12/2023 09:22, Jan Kiszka wrote: >>>>> >>>>>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >>>>> >>>>> Ditto >>>>> >>>> >>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, >>>> not introducing new ones. We can add the color properties in a separate >>> >>> >>> Then why aren't you overriding by phandle/label? >>> >> >> We could do that as well if we added labels first (they don't exist so >> far). Not seeing any difference, though. > > Confusion? Your code suggests new node, thus you got review like you got. > >> >>>> patch, but the node names are now part of the kernel ABI. Changing them >>>> would break existing userland. >>> >>> You mean label. Why node names became the ABI? Which interface exposes them? >> >> root@iot2050-debian:~# ls -l /sys/class/leds/ >> total 0 >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: >> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green >> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red > > I replied too fast previous and did not include answer here: > > You have label for that... Somehow all these nodes are half-baked, > without all the expected properties and now you call node name as ABI. > The node name is not the ABI. Well, existing userspace uses those names, and adding the properties would break that interface. Now, does Linux do that? Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:54 ` Jan Kiszka @ 2023-12-19 9:56 ` Jan Kiszka 2023-12-19 9:58 ` Krzysztof Kozlowski 1 sibling, 0 replies; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 9:56 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 10:54, Jan Kiszka wrote: > On 19.12.23 10:50, Krzysztof Kozlowski wrote: >> On 19/12/2023 10:03, Jan Kiszka wrote: >>> On 19.12.23 09:48, Krzysztof Kozlowski wrote: >>>> On 19/12/2023 09:22, Jan Kiszka wrote: >>>>>> >>>>>>> + gpios = <&wkup_gpio0 53 GPIO_ACTIVE_HIGH>; >>>>>> >>>>>> Ditto >>>>>> >>>>> >>>>> This is adjusting the existing LED nodes in k3-am65-iot2050-common.dtsi, >>>>> not introducing new ones. We can add the color properties in a separate >>>> >>>> >>>> Then why aren't you overriding by phandle/label? >>>> >>> >>> We could do that as well if we added labels first (they don't exist so >>> far). Not seeing any difference, though. >> >> Confusion? Your code suggests new node, thus you got review like you got. >> >>> >>>>> patch, but the node names are now part of the kernel ABI. Changing them >>>>> would break existing userland. >>>> >>>> You mean label. Why node names became the ABI? Which interface exposes them? >>> >>> root@iot2050-debian:~# ls -l /sys/class/leds/ >>> total 0 >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: >>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red >> >> I replied too fast previous and did not include answer here: >> >> You have label for that... Somehow all these nodes are half-baked, >> without all the expected properties and now you call node name as ABI. >> The node name is not the ABI. > > Well, existing userspace uses those names, and adding the properties > would break that interface. Now, does Linux do that? > Obviously, we could deviate from the existing naming scheme only for the new variant, keeping it for the other 5, but that will be "fun" to maintain. Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:54 ` Jan Kiszka 2023-12-19 9:56 ` Jan Kiszka @ 2023-12-19 9:58 ` Krzysztof Kozlowski 2023-12-19 15:37 ` Jan Kiszka 1 sibling, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 9:58 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 10:54, Jan Kiszka wrote: >>>> You mean label. Why node names became the ABI? Which interface exposes them? >>> >>> root@iot2050-debian:~# ls -l /sys/class/leds/ >>> total 0 >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: >>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green >>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red >> >> I replied too fast previous and did not include answer here: >> >> You have label for that... Somehow all these nodes are half-baked, >> without all the expected properties and now you call node name as ABI. >> The node name is not the ABI. > > Well, existing userspace uses those names, and adding the properties > would break that interface. Now, does Linux do that? I don't think you understood the concept. There is no change for userspace. Same interface, same names. No ABI break. Anyway, changing them is not part of this patchset since these are not new nodes. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 9:58 ` Krzysztof Kozlowski @ 2023-12-19 15:37 ` Jan Kiszka 2023-12-19 15:39 ` Krzysztof Kozlowski 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 15:37 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 10:58, Krzysztof Kozlowski wrote: > On 19/12/2023 10:54, Jan Kiszka wrote: >>>>> You mean label. Why node names became the ABI? Which interface exposes them? >>>> >>>> root@iot2050-debian:~# ls -l /sys/class/leds/ >>>> total 0 >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: >>>> lrwxrwxrwx 1 root root 0 Dec 14 21:12 status-led-green -> ../../devices/platform/leds/leds/status-led-green >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 status-led-red -> ../../devices/platform/leds/leds/status-led-red >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-green -> ../../devices/platform/leds/leds/user-led1-green >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led1-red -> ../../devices/platform/leds/leds/user-led1-red >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-green -> ../../devices/platform/leds/leds/user-led2-green >>>> lrwxrwxrwx 1 root root 0 Dec 19 08:55 user-led2-red -> ../../devices/platform/leds/leds/user-led2-red >>> >>> I replied too fast previous and did not include answer here: >>> >>> You have label for that... Somehow all these nodes are half-baked, >>> without all the expected properties and now you call node name as ABI. >>> The node name is not the ABI. >> >> Well, existing userspace uses those names, and adding the properties >> would break that interface. Now, does Linux do that? > > I don't think you understood the concept. There is no change for > userspace. Same interface, same names. No ABI break. I do understand the impact very well: open("/sys/class/leds/user-led1-red") has to work for all the variants, consistently and backward-compatible for userspace. > > Anyway, changing them is not part of this patchset since these are not > new nodes. Fine, then we can leave the LED topic aside for now. I will look into the other comments. Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 15:37 ` Jan Kiszka @ 2023-12-19 15:39 ` Krzysztof Kozlowski 2023-12-19 15:40 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 15:39 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 16:37, Jan Kiszka wrote: >>>> >>>> You have label for that... Somehow all these nodes are half-baked, >>>> without all the expected properties and now you call node name as ABI. >>>> The node name is not the ABI. >>> >>> Well, existing userspace uses those names, and adding the properties >>> would break that interface. Now, does Linux do that? >> >> I don't think you understood the concept. There is no change for >> userspace. Same interface, same names. No ABI break. > > I do understand the impact very well: > open("/sys/class/leds/user-led1-red") has to work for all the variants, > consistently and backward-compatible for userspace. And it will. The name is the same. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 15:39 ` Krzysztof Kozlowski @ 2023-12-19 15:40 ` Jan Kiszka 2023-12-19 15:42 ` Krzysztof Kozlowski 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 15:40 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 16:39, Krzysztof Kozlowski wrote: > On 19/12/2023 16:37, Jan Kiszka wrote: >>>>> >>>>> You have label for that... Somehow all these nodes are half-baked, >>>>> without all the expected properties and now you call node name as ABI. >>>>> The node name is not the ABI. >>>> >>>> Well, existing userspace uses those names, and adding the properties >>>> would break that interface. Now, does Linux do that? >>> >>> I don't think you understood the concept. There is no change for >>> userspace. Same interface, same names. No ABI break. >> >> I do understand the impact very well: >> open("/sys/class/leds/user-led1-red") has to work for all the variants, >> consistently and backward-compatible for userspace. > > And it will. The name is the same. Nope, it's not - I tried that already :) root@iot2050-debian:~# ls -l /sys/class/leds/ total 0 lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:status -> ../../devices/platform/leds/leds/green:status lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc0:: -> ../../devices/platform/bus@100000/4fa0000.mmc/leds/mmc0:: lrwxrwxrwx 1 root root 0 Dec 19 09:49 mmc1:: -> ../../devices/platform/bus@100000/4f80000.mmc/leds/mmc1:: lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator -> ../../devices/platform/leds/leds/red:indicator lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_1 -> ../../devices/platform/leds/leds/red:indicator_1 lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:indicator_2 -> ../../devices/platform/leds/leds/red:indicator_2 lrwxrwxrwx 1 root root 0 Dec 19 09:49 red:status -> ../../devices/platform/leds/leds/red:status Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 15:40 ` Jan Kiszka @ 2023-12-19 15:42 ` Krzysztof Kozlowski 2023-12-19 15:48 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 15:42 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 16:40, Jan Kiszka wrote: > On 19.12.23 16:39, Krzysztof Kozlowski wrote: >> On 19/12/2023 16:37, Jan Kiszka wrote: >>>>>> >>>>>> You have label for that... Somehow all these nodes are half-baked, >>>>>> without all the expected properties and now you call node name as ABI. >>>>>> The node name is not the ABI. >>>>> >>>>> Well, existing userspace uses those names, and adding the properties >>>>> would break that interface. Now, does Linux do that? >>>> >>>> I don't think you understood the concept. There is no change for >>>> userspace. Same interface, same names. No ABI break. >>> >>> I do understand the impact very well: >>> open("/sys/class/leds/user-led1-red") has to work for all the variants, >>> consistently and backward-compatible for userspace. >> >> And it will. The name is the same. > > Nope, it's not - I tried that already :) > > root@iot2050-debian:~# ls -l /sys/class/leds/ > total 0 > lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator And how does your DTS look like? Because I also tried and it is exactly the same. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 15:42 ` Krzysztof Kozlowski @ 2023-12-19 15:48 ` Jan Kiszka 2023-12-19 15:56 ` Krzysztof Kozlowski 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2023-12-19 15:48 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19.12.23 16:42, Krzysztof Kozlowski wrote: > On 19/12/2023 16:40, Jan Kiszka wrote: >> On 19.12.23 16:39, Krzysztof Kozlowski wrote: >>> On 19/12/2023 16:37, Jan Kiszka wrote: >>>>>>> >>>>>>> You have label for that... Somehow all these nodes are half-baked, >>>>>>> without all the expected properties and now you call node name as ABI. >>>>>>> The node name is not the ABI. >>>>>> >>>>>> Well, existing userspace uses those names, and adding the properties >>>>>> would break that interface. Now, does Linux do that? >>>>> >>>>> I don't think you understood the concept. There is no change for >>>>> userspace. Same interface, same names. No ABI break. >>>> >>>> I do understand the impact very well: >>>> open("/sys/class/leds/user-led1-red") has to work for all the variants, >>>> consistently and backward-compatible for userspace. >>> >>> And it will. The name is the same. >> >> Nope, it's not - I tried that already :) >> >> root@iot2050-debian:~# ls -l /sys/class/leds/ >> total 0 >> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator > > And how does your DTS look like? > > Because I also tried and it is exactly the same. > I played with diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi index 402afa4bc1b6..a791444eeb93 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi @@ -10,6 +10,7 @@ */ #include "k3-am654.dtsi" +#include <dt-bindings/leds/common.h> #include <dt-bindings/phy/phy.h> #include <dt-bindings/net/ti-dp83867.h> @@ -84,27 +85,39 @@ leds { pinctrl-0 = <&leds_pins_default>; status-led-red { + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_STATUS; gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>; panic-indicator; }; status-led-green { + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_STATUS; gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>; }; user-led1-red { + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_INDICATOR; gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>; }; user-led1-green { + color = <LED_COLOR_ID_GREEN>; + function = LED_FUNCTION_INDICATOR; gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>; }; user-led2-red { + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_INDICATOR; gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>; }; user-led2-green { + color = <LED_COLOR_ID_RED>; + function = LED_FUNCTION_INDICATOR; gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>; }; }; Jan -- Siemens AG, Technology Linux Expert Center ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant 2023-12-19 15:48 ` Jan Kiszka @ 2023-12-19 15:56 ` Krzysztof Kozlowski 0 siblings, 0 replies; 25+ messages in thread From: Krzysztof Kozlowski @ 2023-12-19 15:56 UTC (permalink / raw) To: Jan Kiszka, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bao Cheng Su, Chao Zeng Cc: linux-arm-kernel, linux-kernel, devicetree, Li Hua Qian On 19/12/2023 16:48, Jan Kiszka wrote: > On 19.12.23 16:42, Krzysztof Kozlowski wrote: >> On 19/12/2023 16:40, Jan Kiszka wrote: >>> On 19.12.23 16:39, Krzysztof Kozlowski wrote: >>>> On 19/12/2023 16:37, Jan Kiszka wrote: >>>>>>>> >>>>>>>> You have label for that... Somehow all these nodes are half-baked, >>>>>>>> without all the expected properties and now you call node name as ABI. >>>>>>>> The node name is not the ABI. >>>>>>> >>>>>>> Well, existing userspace uses those names, and adding the properties >>>>>>> would break that interface. Now, does Linux do that? >>>>>> >>>>>> I don't think you understood the concept. There is no change for >>>>>> userspace. Same interface, same names. No ABI break. >>>>> >>>>> I do understand the impact very well: >>>>> open("/sys/class/leds/user-led1-red") has to work for all the variants, >>>>> consistently and backward-compatible for userspace. >>>> >>>> And it will. The name is the same. >>> >>> Nope, it's not - I tried that already :) >>> >>> root@iot2050-debian:~# ls -l /sys/class/leds/ >>> total 0 >>> lrwxrwxrwx 1 root root 0 Dec 19 09:49 green:indicator -> ../../devices/platform/leds/leds/green:indicator >> >> And how does your DTS look like? >> >> Because I also tried and it is exactly the same. >> > > I played with > > diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > index 402afa4bc1b6..a791444eeb93 100644 > --- a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > +++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi > @@ -10,6 +10,7 @@ > */ > > #include "k3-am654.dtsi" > +#include <dt-bindings/leds/common.h> > #include <dt-bindings/phy/phy.h> > #include <dt-bindings/net/ti-dp83867.h> > > @@ -84,27 +85,39 @@ leds { > pinctrl-0 = <&leds_pins_default>; > > status-led-red { > + color = <LED_COLOR_ID_RED>; > + function = LED_FUNCTION_STATUS; > gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>; > panic-indicator; And where is the label property? Please read my message again: >> You: >> patch, but the node names are now part of the kernel ABI. Changing them would break existing userland. > Me: > You mean label. Why node names became the ABI? Which interface exposes them? >> You: >> root@iot2050-debian:~# ls -l /sys/class/leds/ > Me: > I replied too fast previous and did not include answer here: > You have label for that... So again: The stable ABI is fulfilled by using label property. Not the Devicetree "label" phandle in front of the node, but the dedicated property. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2023-12-19 15:56 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-18 16:35 [PATCH 0/4] arm64: dts: iot2050: Add support for new SM variant Jan Kiszka 2023-12-18 16:35 ` [PATCH 1/4] dt-bindings: arm: ti: Add binding for Siemens IOT2050 " Jan Kiszka 2023-12-19 7:50 ` Krzysztof Kozlowski 2023-12-18 16:35 ` [PATCH 2/4] arm64: dts: ti: iot2050: Disable R5 lockstep for all PG2 boards Jan Kiszka 2023-12-18 16:35 ` [PATCH 3/4] arm64: dts: ti: iot2050: Factor out arduino connector bits Jan Kiszka 2023-12-19 7:51 ` Krzysztof Kozlowski 2023-12-19 8:06 ` Jan Kiszka 2023-12-19 8:12 ` Krzysztof Kozlowski 2023-12-19 8:18 ` Jan Kiszka 2023-12-18 16:36 ` [PATCH 4/4] dts: iot2050: Support IOT2050-SM variant Jan Kiszka 2023-12-19 7:54 ` Krzysztof Kozlowski 2023-12-19 8:22 ` Jan Kiszka 2023-12-19 8:48 ` Krzysztof Kozlowski 2023-12-19 9:03 ` Jan Kiszka 2023-12-19 9:45 ` Krzysztof Kozlowski 2023-12-19 9:50 ` Krzysztof Kozlowski 2023-12-19 9:54 ` Jan Kiszka 2023-12-19 9:56 ` Jan Kiszka 2023-12-19 9:58 ` Krzysztof Kozlowski 2023-12-19 15:37 ` Jan Kiszka 2023-12-19 15:39 ` Krzysztof Kozlowski 2023-12-19 15:40 ` Jan Kiszka 2023-12-19 15:42 ` Krzysztof Kozlowski 2023-12-19 15:48 ` Jan Kiszka 2023-12-19 15:56 ` Krzysztof Kozlowski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®