* [PATCH v4 0/3] arm64: Add TI AM65x-based IOT2050 boards
@ 2021-03-10 9:37 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su
Changes in v4:
- rebased over ti-k3-dts-next and resent completely (no changes)
- added ack and review tags
Jan
Jan Kiszka (3):
dt-bindings: Add Siemens vendor prefix
dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
arm64: dts: ti: Add support for Siemens IOT2050 boards
.../devicetree/bindings/arm/ti/k3.yaml | 2 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++++++++++++++++++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
6 files changed, 788 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
--
2.26.2
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v4 0/3] arm64: Add TI AM65x-based IOT2050 boards
@ 2021-03-10 9:37 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su
Changes in v4:
- rebased over ti-k3-dts-next and resent completely (no changes)
- added ack and review tags
Jan
Jan Kiszka (3):
dt-bindings: Add Siemens vendor prefix
dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
arm64: dts: ti: Add support for Siemens IOT2050 boards
.../devicetree/bindings/arm/ti/k3.yaml | 2 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++++++++++++++++++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
6 files changed, 788 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v4 1/3] dt-bindings: Add Siemens vendor prefix
2021-03-10 9:37 ` Jan Kiszka
@ 2021-03-10 9:37 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Rob Herring
From: Jan Kiszka <jan.kiszka@siemens.com>
Add prefix for Siemens AG.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a424..91f99130a933 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1024,6 +1024,8 @@ patternProperties:
description: Silex Insight
"^siliconmitus,.*":
description: Silicon Mitus, Inc.
+ "^siemens,.*":
+ description: Siemens AG
"^simtek,.*":
description: Cypress Semiconductor Corporation (Simtek Corporation)
"^sinlinx,.*":
--
2.26.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v4 1/3] dt-bindings: Add Siemens vendor prefix
@ 2021-03-10 9:37 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Rob Herring
From: Jan Kiszka <jan.kiszka@siemens.com>
Add prefix for Siemens AG.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f6064d84a424..91f99130a933 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1024,6 +1024,8 @@ patternProperties:
description: Silex Insight
"^siliconmitus,.*":
description: Silicon Mitus, Inc.
+ "^siemens,.*":
+ description: Siemens AG
"^simtek,.*":
description: Cypress Semiconductor Corporation (Simtek Corporation)
"^sinlinx,.*":
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v4 2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
2021-03-10 9:37 ` Jan Kiszka
@ 2021-03-10 9:37 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Rob Herring
From: Jan Kiszka <jan.kiszka@siemens.com>
These boards are based on AM6528 GP and AM6548 HS SOCs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index a9e7f981631e..c5aa362e4026 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -23,6 +23,8 @@ properties:
items:
- enum:
- ti,am654-evm
+ - siemens,iot2050-basic
+ - siemens,iot2050-advanced
- const: ti,am654
- description: K3 J721E SoC
--
2.26.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v4 2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards
@ 2021-03-10 9:37 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Rob Herring
From: Jan Kiszka <jan.kiszka@siemens.com>
These boards are based on AM6528 GP and AM6548 HS SOCs.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index a9e7f981631e..c5aa362e4026 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -23,6 +23,8 @@ properties:
items:
- enum:
- ti,am654-evm
+ - siemens,iot2050-basic
+ - siemens,iot2050-advanced
- const: ti,am654
- description: K3 J721E SoC
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-10 9:37 ` Jan Kiszka
@ 2021-03-10 9:37 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Vignesh Raghavendra
From: Jan Kiszka <jan.kiszka@siemens.com>
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link: https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++++++++++++++++++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 784 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 386ef98ccf7d..d56c742f5a10 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index 000000000000..34bca374bb76
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include <dt-bindings/phy/phy.h>
+
+/ {
+ aliases {
+ spi0 = &mcu_spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02810000";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa0000000 0 0x100000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa0100000 0 0xf00000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa1000000 0 0x100000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a1100000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa1100000 0 0xf00000>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a2000000 {
+ reg = <0x00 0xa2000000 0x00 0x00200000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ status-led-red {
+ gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <19200000>;
+ };
+};
+
+&wkup_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ 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-pins-default {
+ pinctrl-single,pins = <
+ /* (AD8) MCU_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0)
+ /* (AD7) MCU_I2C0_SDA */
+ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT, 0)
+ >;
+ };
+
+ arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-pins-default {
+ pinctrl-single,pins = <
+ /* (R2) WKUP_GPIO0_21 */
+ AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
+ >;
+ };
+
+ push_button_pins_default: push-button-pins-default {
+ pinctrl-single,pins = <
+ /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
+ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7)
+ >;
+ };
+
+ arduino_uart_pins_default: arduino-uart-pins-default {
+ pinctrl-single,pins = <
+ /* (P4) MCU_UART0_RXD */
+ AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
+ /* (P5) MCU_UART0_TXD */
+ AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
+ >;
+ };
+
+ arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-pins-default {
+ pinctrl-single,pins = <
+ /* (P1) WKUP_GPIO0_31 */
+ AM65X_WKUP_IOPAD(0x004C, PIN_OUTPUT, 7)
+ /* (N3) WKUP_GPIO0_33 */
+ AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 7)
+ >;
+ };
+
+ arduino_io_oe_pins_default: arduino-io-oe-pins-default {
+ 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-pins-default {
+ pinctrl-single,pins = <
+ /* (V1) MCU_OSPI0_CLK */
+ AM65X_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0)
+ /* (U2) MCU_OSPI0_DQS */
+ AM65X_WKUP_IOPAD(0x0008, PIN_INPUT, 0)
+ /* (U4) MCU_OSPI0_D0 */
+ AM65X_WKUP_IOPAD(0x000c, PIN_INPUT, 0)
+ /* (U5) MCU_OSPI0_D1 */
+ AM65X_WKUP_IOPAD(0x0010, PIN_INPUT, 0)
+ /* (R4) MCU_OSPI0_CSn0 */
+ AM65X_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0)
+ >;
+ };
+
+ db9_com_mode_pins_default: db9-com-mode-pins-default {
+ pinctrl-single,pins = <
+ /* (AD3) WKUP_GPIO0_5, used as uart0 mode 0 */
+ AM65X_WKUP_IOPAD(0x00c4, PIN_OUTPUT, 7)
+ /* (AC3) WKUP_GPIO0_4, used as uart0 mode 1 */
+ AM65X_WKUP_IOPAD(0x00c0, PIN_OUTPUT, 7)
+ /* (AC1) WKUP_GPIO0_7, used as uart0 term */
+ AM65X_WKUP_IOPAD(0x00cc, PIN_OUTPUT, 7)
+ /* (AC2) WKUP_GPIO0_6, used as uart0 en */
+ AM65X_WKUP_IOPAD(0x00c8, PIN_OUTPUT, 7)
+ >;
+ };
+
+ leds_pins_default: leds-pins-default {
+ pinctrl-single,pins = <
+ /* (T2) WKUP_GPIO0_17, used as user led1 red */
+ AM65X_WKUP_IOPAD(0x0014, PIN_OUTPUT, 7)
+ /* (R3) WKUP_GPIO0_22, used as user led1 green */
+ AM65X_WKUP_IOPAD(0x0028, PIN_OUTPUT, 7)
+ /* (R5) WKUP_GPIO0_24, used as status led red */
+ AM65X_WKUP_IOPAD(0x0030, PIN_OUTPUT, 7)
+ /* (N2) WKUP_GPIO0_32, used as status led green */
+ AM65X_WKUP_IOPAD(0x0050, PIN_OUTPUT, 7)
+ >;
+ };
+
+ mcu_spi0_pins_default: mcu-spi0-pins-default {
+ pinctrl-single,pins = <
+ /* (Y1) MCU_SPI0_CLK */
+ AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
+ /* (Y3) MCU_SPI0_D0 */
+ AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
+ /* (Y2) MCU_SPI0_D1 */
+ AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
+ /* (Y4) MCU_SPI0_CS0 */
+ AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
+ >;
+ };
+
+ minipcie_pins_default: minipcie-pins-default {
+ pinctrl-single,pins = <
+ /* (P2) MCU_OSPI1_DQS.WKUP_GPIO0_27 */
+ AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7)
+ >;
+ };
+};
+
+&main_pmx0 {
+ main_uart1_pins_default: main-uart1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0174, PIN_INPUT, 6) /* (AE23) UART1_RXD */
+ AM65X_IOPAD(0x014c, PIN_OUTPUT, 6) /* (AD23) UART1_TXD */
+ AM65X_IOPAD(0x0178, PIN_INPUT, 6) /* (AD22) UART1_CTSn */
+ AM65X_IOPAD(0x017c, PIN_OUTPUT, 6) /* (AC21) UART1_RTSn */
+ >;
+ };
+
+ main_i2c3_pins_default: main-i2c3-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01c0, PIN_INPUT, 2) /* (AF13) I2C3_SCL */
+ AM65X_IOPAD(0x01d4, PIN_INPUT, 2) /* (AG12) I2C3_SDA */
+ >;
+ };
+
+ main_mmc1_pins_default: main-mmc1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN, 0) /* (C27) MMC1_CLK */
+ AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP, 0) /* (C28) MMC1_CMD */
+ AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP, 0) /* (D28) MMC1_DAT0 */
+ AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP, 0) /* (E27) MMC1_DAT1 */
+ AM65X_IOPAD(0x02c8, PIN_INPUT_PULLUP, 0) /* (D26) MMC1_DAT2 */
+ AM65X_IOPAD(0x02c4, PIN_INPUT_PULLUP, 0) /* (D27) MMC1_DAT3 */
+ AM65X_IOPAD(0x02dc, PIN_INPUT_PULLUP, 0) /* (B24) MMC1_SDCD */
+ AM65X_IOPAD(0x02e0, PIN_INPUT_PULLUP, 0) /* (C24) MMC1_SDWP */
+ >;
+ };
+
+ usb0_pins_default: usb0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02bc, PIN_OUTPUT, 0) /* (AD9) USB0_DRVVBUS */
+ >;
+ };
+
+ usb1_pins_default: usb1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02c0, PIN_OUTPUT, 0) /* (AC8) USB1_DRVVBUS */
+ >;
+ };
+
+ arduino_io_d4_to_d9_pins_default: arduino-io-d4-to-d9-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0084, PIN_OUTPUT, 7) /* (AG18) GPIO0_33 */
+ AM65X_IOPAD(0x008C, PIN_OUTPUT, 7) /* (AF17) GPIO0_35 */
+ AM65X_IOPAD(0x0098, PIN_OUTPUT, 7) /* (AH16) GPIO0_38 */
+ AM65X_IOPAD(0x00AC, PIN_OUTPUT, 7) /* (AH15) GPIO0_43 */
+ AM65X_IOPAD(0x00C0, PIN_OUTPUT, 7) /* (AG15) GPIO0_48 */
+ AM65X_IOPAD(0x00CC, PIN_OUTPUT, 7) /* (AD15) GPIO0_51 */
+ >;
+ };
+
+ dss_vout1_pins_default: dss-vout1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0000, PIN_OUTPUT, 1) /* VOUT1_DATA0 */
+ AM65X_IOPAD(0x0004, PIN_OUTPUT, 1) /* VOUT1_DATA1 */
+ AM65X_IOPAD(0x0008, PIN_OUTPUT, 1) /* VOUT1_DATA2 */
+ AM65X_IOPAD(0x000c, PIN_OUTPUT, 1) /* VOUT1_DATA3 */
+ AM65X_IOPAD(0x0010, PIN_OUTPUT, 1) /* VOUT1_DATA4 */
+ AM65X_IOPAD(0x0014, PIN_OUTPUT, 1) /* VOUT1_DATA5 */
+ AM65X_IOPAD(0x0018, PIN_OUTPUT, 1) /* VOUT1_DATA6 */
+ AM65X_IOPAD(0x001c, PIN_OUTPUT, 1) /* VOUT1_DATA7 */
+ AM65X_IOPAD(0x0020, PIN_OUTPUT, 1) /* VOUT1_DATA8 */
+ AM65X_IOPAD(0x0024, PIN_OUTPUT, 1) /* VOUT1_DATA9 */
+ AM65X_IOPAD(0x0028, PIN_OUTPUT, 1) /* VOUT1_DATA10 */
+ AM65X_IOPAD(0x002c, PIN_OUTPUT, 1) /* VOUT1_DATA11 */
+ AM65X_IOPAD(0x0030, PIN_OUTPUT, 1) /* VOUT1_DATA12 */
+ AM65X_IOPAD(0x0034, PIN_OUTPUT, 1) /* VOUT1_DATA13 */
+ AM65X_IOPAD(0x0038, PIN_OUTPUT, 1) /* VOUT1_DATA14 */
+ AM65X_IOPAD(0x003c, PIN_OUTPUT, 1) /* VOUT1_DATA15 */
+ AM65X_IOPAD(0x0040, PIN_OUTPUT, 1) /* VOUT1_DATA16 */
+ AM65X_IOPAD(0x0044, PIN_OUTPUT, 1) /* VOUT1_DATA17 */
+ AM65X_IOPAD(0x0048, PIN_OUTPUT, 1) /* VOUT1_DATA18 */
+ AM65X_IOPAD(0x004c, PIN_OUTPUT, 1) /* VOUT1_DATA19 */
+ AM65X_IOPAD(0x0050, PIN_OUTPUT, 1) /* VOUT1_DATA20 */
+ AM65X_IOPAD(0x0054, PIN_OUTPUT, 1) /* VOUT1_DATA21 */
+ AM65X_IOPAD(0x0058, PIN_OUTPUT, 1) /* VOUT1_DATA22 */
+ AM65X_IOPAD(0x005c, PIN_OUTPUT, 1) /* VOUT1_DATA23 */
+ AM65X_IOPAD(0x0060, PIN_OUTPUT, 1) /* VOUT1_VSYNC */
+ AM65X_IOPAD(0x0064, PIN_OUTPUT, 1) /* VOUT1_HSYNC */
+ AM65X_IOPAD(0x0068, PIN_OUTPUT, 1) /* VOUT1_PCLK */
+ AM65X_IOPAD(0x006c, PIN_OUTPUT, 1) /* VOUT1_DE */
+ >;
+ };
+
+ dp_pins_default: dp-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0078, PIN_OUTPUT, 7) /* (AF18) DP rst_n */
+ >;
+ };
+
+ main_i2c2_pins_default: main-i2c2-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0074, PIN_INPUT, 5) /* (T27) I2C2_SCL */
+ AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25) I2C2_SDA */
+ >;
+ };
+};
+
+&main_pmx1 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0000, PIN_INPUT, 0) /* (D20) I2C0_SCL */
+ AM65X_IOPAD(0x0004, PIN_INPUT, 0) /* (C21) I2C0_SDA */
+ >;
+ };
+
+ main_i2c1_pins_default: main-i2c1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0008, PIN_INPUT, 0) /* (B21) I2C1_SCL */
+ AM65X_IOPAD(0x000c, PIN_INPUT, 0) /* (E21) I2C1_SDA */
+ >;
+ };
+
+ ecap0_pins_default: ecap0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21) ECAP0_IN_APWM_OUT */
+ >;
+ };
+};
+
+&wkup_uart0 {
+ /* Wakeup UART is used by System firmware */
+ status = "reserved";
+};
+
+&main_uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart1_pins_default>;
+};
+
+&main_uart2 {
+ status = "disabled";
+};
+
+&mcu_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&arduino_uart_pins_default>;
+};
+
+&main_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&arduino_io_d4_to_d9_pins_default>;
+ gpio-line-names =
+ "main_gpio0-base", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "IO4", "", "IO5", "", "", "IO6", "",
+ "", "", "", "IO7", "", "", "", "", "IO8", "",
+ "", "IO9";
+};
+
+&wkup_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &arduino_io_d2_to_d3_pins_default
+ &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 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&mcu_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_i2c0_pins_default>;
+ clock-frequency = <400000>;
+
+ psu: regulator@60 {
+ compatible = "ti,tps62363";
+ reg = <0x60>;
+ regulator-name = "tps62363-vout";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ ti,vsel0-state-high;
+ 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 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+
+ rtc: rtc8564@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ eeprom: eeprom@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ pagesize = <16>;
+ };
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&main_i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c2_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&main_i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp-bridge@f {
+ compatible = "toshiba,tc358767";
+ reg = <0x0f>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_pins_default>;
+ reset-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ clock-names = "ref";
+ clocks = <&dp_refclk>;
+
+ toshiba,hpd-pin = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ bridge_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+ };
+};
+
+&mcu_cpsw {
+ status = "disabled";
+};
+
+&ecap0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap0_pins_default>;
+};
+
+&sdhci1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_pins_default>;
+ dr_mode = "host";
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins_default>;
+ dr_mode = "host";
+};
+
+&mcu_spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_spi0_pins_default>;
+
+ #address-cells = <1>;
+ #size-cells= <0>;
+ ti,pindir-d0-out-d1-in = <1>;
+
+ spidev@0 {
+ compatible = "rohm,dh2228fv";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&tscadc0 {
+ status = "disabled";
+};
+
+&tscadc1 {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5>;
+ };
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ spi-max-frequency = <50000000>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_vout1_pins_default>;
+
+ assigned-clocks = <&k3_clks 67 2>;
+ assigned-clock-parents = <&k3_clks 67 5>;
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&bridge_in>;
+ };
+ };
+};
+
+&serdes0 {
+ status = "disabled";
+};
+
+&pcie0_rc {
+ status = "disabled";
+};
+
+&pcie0_ep {
+ status = "disabled";
+};
+
+&pcie1_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&minipcie_pins_default>;
+
+ num-lanes = <1>;
+ phys = <&serdes1 PHY_TYPE_PCIE 0>;
+ phy-names = "pcie-phy0";
+ reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>;
+};
+
+&pcie1_ep {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
new file mode 100644
index 000000000000..4f7e3f2a6265
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * AM6528-based (dual-core) IOT2050 Basic variant
+ * 1 GB RAM, no eMMC, main_uart0 on connector X30
+ */
+
+/dts-v1/;
+
+#include "k3-am65-iot2050-common.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-basic", "ti,am654";
+ model = "SIMATIC IOT2050 Basic";
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 1G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x40000000>;
+ };
+
+ cpus {
+ cpu-map {
+ /delete-node/ cluster1;
+ };
+ /delete-node/ cpu@100;
+ /delete-node/ cpu@101;
+ };
+
+ /delete-node/ l2-cache1;
+};
+
+/* eMMC */
+&sdhci0 {
+ status = "disabled";
+};
+
+&main_pmx0 {
+ main_uart0_pins_default: main-uart0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01e4, PIN_INPUT, 0) /* (AF11) UART0_RXD */
+ AM65X_IOPAD(0x01e8, PIN_OUTPUT, 0) /* (AE11) UART0_TXD */
+ AM65X_IOPAD(0x01ec, PIN_INPUT, 0) /* (AG11) UART0_CTSn */
+ AM65X_IOPAD(0x01f0, PIN_OUTPUT, 0) /* (AD11) UART0_RTSn */
+ AM65X_IOPAD(0x0188, PIN_INPUT, 1) /* (D25) UART0_DCDn */
+ AM65X_IOPAD(0x018c, PIN_INPUT, 1) /* (B26) UART0_DSRn */
+ AM65X_IOPAD(0x0190, PIN_OUTPUT, 1) /* (A24) UART0_DTRn */
+ AM65X_IOPAD(0x0194, PIN_INPUT, 1) /* (E24) UART0_RIN */
+ >;
+ };
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
new file mode 100644
index 000000000000..ec9617c13cdb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * AM6548-based (quad-core) IOT2050 Advanced variant
+ * 2 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
+ */
+
+/dts-v1/;
+
+#include "k3-am65-iot2050-common.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-advanced", "ti,am654";
+ model = "SIMATIC IOT2050 Advanced";
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 2G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+ };
+};
+
+&main_pmx0 {
+ main_mmc0_pins_default: main-mmc0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /* (B25) MMC0_CLK */
+ AM65X_IOPAD(0x01ac, PIN_INPUT_PULLUP, 0) /* (B27) MMC0_CMD */
+ AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0) /* (A26) MMC0_DAT0 */
+ AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0) /* (E25) MMC0_DAT1 */
+ AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0) /* (C26) MMC0_DAT2 */
+ AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0) /* (A25) MMC0_DAT3 */
+ AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0) /* (E24) MMC0_DAT4 */
+ AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0) /* (A24) MMC0_DAT5 */
+ AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0) /* (B26) MMC0_DAT6 */
+ AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0) /* (D25) MMC0_DAT7 */
+ AM65X_IOPAD(0x01b8, PIN_OUTPUT_PULLUP, 7) /* (B23) MMC0_SDWP */
+ AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0) /* (A23) MMC0_SDCD */
+ AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /* (C25) MMC0_DS */
+ >;
+ };
+};
+
+/* eMMC */
+&sdhci0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc0_pins_default>;
+ bus-width = <8>;
+ non-removable;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+};
+
+&main_uart0 {
+ status = "disabled";
+};
--
2.26.2
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-10 9:37 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-10 9:37 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring
Cc: linux-arm-kernel, linux-kernel, devicetree, Le Jin, Bao Cheng Su,
Vignesh Raghavendra
From: Jan Kiszka <jan.kiszka@siemens.com>
Add support for two Siemens SIMATIC IOT2050 variants, Basic and
Advanced. They are based on the TI AM6528 GP and AM6548 SOCs HS, thus
differ in their number of cores and availability of security features.
Furthermore the Advanced version comes with more RAM, an eMMC and a few
internal differences.
Based on original version by Le Jin.
Link: https://new.siemens.com/global/en/products/automation/pc-based/iot-gateways/simatic-iot2050.html
Link: https://github.com/siemens/meta-iot2050
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am65-iot2050-common.dtsi | 661 ++++++++++++++++++
.../boot/dts/ti/k3-am6528-iot2050-basic.dts | 61 ++
.../dts/ti/k3-am6548-iot2050-advanced.dts | 60 ++
4 files changed, 784 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 386ef98ccf7d..d56c742f5a10 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -7,6 +7,8 @@
#
dtb-$(CONFIG_ARCH_K3) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6528-iot2050-basic.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am6548-iot2050-advanced.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721e-common-proc-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
new file mode 100644
index 000000000000..34bca374bb76
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi
@@ -0,0 +1,661 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * Common bits of the IOT2050 Basic and Advanced variants
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+#include <dt-bindings/phy/phy.h>
+
+/ {
+ aliases {
+ spi0 = &mcu_spi0;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02810000";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: secure-ddr@9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa0000000 0 0x100000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa0100000 0 0xf00000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa1000000 0 0x100000>;
+ no-map;
+ };
+
+ mcu_r5fss0_core1_memory_region: r5f-memory@a1100000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0xa1100000 0 0xf00000>;
+ no-map;
+ };
+
+ rtos_ipc_memory_region: ipc-memories@a2000000 {
+ reg = <0x00 0xa2000000 0x00 0x00200000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ status-led-red {
+ gpios = <&wkup_gpio0 32 GPIO_ACTIVE_HIGH>;
+ panic-indicator;
+ };
+
+ status-led-green {
+ gpios = <&wkup_gpio0 24 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-red {
+ gpios = <&pcal9535_3 14 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led1-green {
+ gpios = <&pcal9535_2 15 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-red {
+ gpios = <&wkup_gpio0 17 GPIO_ACTIVE_HIGH>;
+ };
+
+ user-led2-green {
+ gpios = <&wkup_gpio0 22 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ dp_refclk: clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <19200000>;
+ };
+};
+
+&wkup_pmx0 {
+ wkup_i2c0_pins_default: wkup-i2c0-pins-default {
+ 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-pins-default {
+ pinctrl-single,pins = <
+ /* (AD8) MCU_I2C0_SCL */
+ AM65X_WKUP_IOPAD(0x00e8, PIN_INPUT, 0)
+ /* (AD7) MCU_I2C0_SDA */
+ AM65X_WKUP_IOPAD(0x00ec, PIN_INPUT, 0)
+ >;
+ };
+
+ arduino_i2c_aio_switch_pins_default: arduino-i2c-aio-switch-pins-default {
+ pinctrl-single,pins = <
+ /* (R2) WKUP_GPIO0_21 */
+ AM65X_WKUP_IOPAD(0x0024, PIN_OUTPUT, 7)
+ >;
+ };
+
+ push_button_pins_default: push-button-pins-default {
+ pinctrl-single,pins = <
+ /* (T1) MCU_OSPI1_CLK.WKUP_GPIO0_25 */
+ AM65X_WKUP_IOPAD(0x0034, PIN_INPUT, 7)
+ >;
+ };
+
+ arduino_uart_pins_default: arduino-uart-pins-default {
+ pinctrl-single,pins = <
+ /* (P4) MCU_UART0_RXD */
+ AM65X_WKUP_IOPAD(0x0044, PIN_INPUT, 4)
+ /* (P5) MCU_UART0_TXD */
+ AM65X_WKUP_IOPAD(0x0048, PIN_OUTPUT, 4)
+ >;
+ };
+
+ arduino_io_d2_to_d3_pins_default: arduino-io-d2-to-d3-pins-default {
+ pinctrl-single,pins = <
+ /* (P1) WKUP_GPIO0_31 */
+ AM65X_WKUP_IOPAD(0x004C, PIN_OUTPUT, 7)
+ /* (N3) WKUP_GPIO0_33 */
+ AM65X_WKUP_IOPAD(0x0054, PIN_OUTPUT, 7)
+ >;
+ };
+
+ arduino_io_oe_pins_default: arduino-io-oe-pins-default {
+ 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-pins-default {
+ pinctrl-single,pins = <
+ /* (V1) MCU_OSPI0_CLK */
+ AM65X_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0)
+ /* (U2) MCU_OSPI0_DQS */
+ AM65X_WKUP_IOPAD(0x0008, PIN_INPUT, 0)
+ /* (U4) MCU_OSPI0_D0 */
+ AM65X_WKUP_IOPAD(0x000c, PIN_INPUT, 0)
+ /* (U5) MCU_OSPI0_D1 */
+ AM65X_WKUP_IOPAD(0x0010, PIN_INPUT, 0)
+ /* (R4) MCU_OSPI0_CSn0 */
+ AM65X_WKUP_IOPAD(0x002c, PIN_OUTPUT, 0)
+ >;
+ };
+
+ db9_com_mode_pins_default: db9-com-mode-pins-default {
+ pinctrl-single,pins = <
+ /* (AD3) WKUP_GPIO0_5, used as uart0 mode 0 */
+ AM65X_WKUP_IOPAD(0x00c4, PIN_OUTPUT, 7)
+ /* (AC3) WKUP_GPIO0_4, used as uart0 mode 1 */
+ AM65X_WKUP_IOPAD(0x00c0, PIN_OUTPUT, 7)
+ /* (AC1) WKUP_GPIO0_7, used as uart0 term */
+ AM65X_WKUP_IOPAD(0x00cc, PIN_OUTPUT, 7)
+ /* (AC2) WKUP_GPIO0_6, used as uart0 en */
+ AM65X_WKUP_IOPAD(0x00c8, PIN_OUTPUT, 7)
+ >;
+ };
+
+ leds_pins_default: leds-pins-default {
+ pinctrl-single,pins = <
+ /* (T2) WKUP_GPIO0_17, used as user led1 red */
+ AM65X_WKUP_IOPAD(0x0014, PIN_OUTPUT, 7)
+ /* (R3) WKUP_GPIO0_22, used as user led1 green */
+ AM65X_WKUP_IOPAD(0x0028, PIN_OUTPUT, 7)
+ /* (R5) WKUP_GPIO0_24, used as status led red */
+ AM65X_WKUP_IOPAD(0x0030, PIN_OUTPUT, 7)
+ /* (N2) WKUP_GPIO0_32, used as status led green */
+ AM65X_WKUP_IOPAD(0x0050, PIN_OUTPUT, 7)
+ >;
+ };
+
+ mcu_spi0_pins_default: mcu-spi0-pins-default {
+ pinctrl-single,pins = <
+ /* (Y1) MCU_SPI0_CLK */
+ AM65X_WKUP_IOPAD(0x0090, PIN_INPUT, 0)
+ /* (Y3) MCU_SPI0_D0 */
+ AM65X_WKUP_IOPAD(0x0094, PIN_INPUT, 0)
+ /* (Y2) MCU_SPI0_D1 */
+ AM65X_WKUP_IOPAD(0x0098, PIN_INPUT, 0)
+ /* (Y4) MCU_SPI0_CS0 */
+ AM65X_WKUP_IOPAD(0x009c, PIN_OUTPUT, 0)
+ >;
+ };
+
+ minipcie_pins_default: minipcie-pins-default {
+ pinctrl-single,pins = <
+ /* (P2) MCU_OSPI1_DQS.WKUP_GPIO0_27 */
+ AM65X_WKUP_IOPAD(0x003C, PIN_OUTPUT, 7)
+ >;
+ };
+};
+
+&main_pmx0 {
+ main_uart1_pins_default: main-uart1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0174, PIN_INPUT, 6) /* (AE23) UART1_RXD */
+ AM65X_IOPAD(0x014c, PIN_OUTPUT, 6) /* (AD23) UART1_TXD */
+ AM65X_IOPAD(0x0178, PIN_INPUT, 6) /* (AD22) UART1_CTSn */
+ AM65X_IOPAD(0x017c, PIN_OUTPUT, 6) /* (AC21) UART1_RTSn */
+ >;
+ };
+
+ main_i2c3_pins_default: main-i2c3-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01c0, PIN_INPUT, 2) /* (AF13) I2C3_SCL */
+ AM65X_IOPAD(0x01d4, PIN_INPUT, 2) /* (AG12) I2C3_SDA */
+ >;
+ };
+
+ main_mmc1_pins_default: main-mmc1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN, 0) /* (C27) MMC1_CLK */
+ AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP, 0) /* (C28) MMC1_CMD */
+ AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP, 0) /* (D28) MMC1_DAT0 */
+ AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP, 0) /* (E27) MMC1_DAT1 */
+ AM65X_IOPAD(0x02c8, PIN_INPUT_PULLUP, 0) /* (D26) MMC1_DAT2 */
+ AM65X_IOPAD(0x02c4, PIN_INPUT_PULLUP, 0) /* (D27) MMC1_DAT3 */
+ AM65X_IOPAD(0x02dc, PIN_INPUT_PULLUP, 0) /* (B24) MMC1_SDCD */
+ AM65X_IOPAD(0x02e0, PIN_INPUT_PULLUP, 0) /* (C24) MMC1_SDWP */
+ >;
+ };
+
+ usb0_pins_default: usb0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02bc, PIN_OUTPUT, 0) /* (AD9) USB0_DRVVBUS */
+ >;
+ };
+
+ usb1_pins_default: usb1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x02c0, PIN_OUTPUT, 0) /* (AC8) USB1_DRVVBUS */
+ >;
+ };
+
+ arduino_io_d4_to_d9_pins_default: arduino-io-d4-to-d9-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0084, PIN_OUTPUT, 7) /* (AG18) GPIO0_33 */
+ AM65X_IOPAD(0x008C, PIN_OUTPUT, 7) /* (AF17) GPIO0_35 */
+ AM65X_IOPAD(0x0098, PIN_OUTPUT, 7) /* (AH16) GPIO0_38 */
+ AM65X_IOPAD(0x00AC, PIN_OUTPUT, 7) /* (AH15) GPIO0_43 */
+ AM65X_IOPAD(0x00C0, PIN_OUTPUT, 7) /* (AG15) GPIO0_48 */
+ AM65X_IOPAD(0x00CC, PIN_OUTPUT, 7) /* (AD15) GPIO0_51 */
+ >;
+ };
+
+ dss_vout1_pins_default: dss-vout1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0000, PIN_OUTPUT, 1) /* VOUT1_DATA0 */
+ AM65X_IOPAD(0x0004, PIN_OUTPUT, 1) /* VOUT1_DATA1 */
+ AM65X_IOPAD(0x0008, PIN_OUTPUT, 1) /* VOUT1_DATA2 */
+ AM65X_IOPAD(0x000c, PIN_OUTPUT, 1) /* VOUT1_DATA3 */
+ AM65X_IOPAD(0x0010, PIN_OUTPUT, 1) /* VOUT1_DATA4 */
+ AM65X_IOPAD(0x0014, PIN_OUTPUT, 1) /* VOUT1_DATA5 */
+ AM65X_IOPAD(0x0018, PIN_OUTPUT, 1) /* VOUT1_DATA6 */
+ AM65X_IOPAD(0x001c, PIN_OUTPUT, 1) /* VOUT1_DATA7 */
+ AM65X_IOPAD(0x0020, PIN_OUTPUT, 1) /* VOUT1_DATA8 */
+ AM65X_IOPAD(0x0024, PIN_OUTPUT, 1) /* VOUT1_DATA9 */
+ AM65X_IOPAD(0x0028, PIN_OUTPUT, 1) /* VOUT1_DATA10 */
+ AM65X_IOPAD(0x002c, PIN_OUTPUT, 1) /* VOUT1_DATA11 */
+ AM65X_IOPAD(0x0030, PIN_OUTPUT, 1) /* VOUT1_DATA12 */
+ AM65X_IOPAD(0x0034, PIN_OUTPUT, 1) /* VOUT1_DATA13 */
+ AM65X_IOPAD(0x0038, PIN_OUTPUT, 1) /* VOUT1_DATA14 */
+ AM65X_IOPAD(0x003c, PIN_OUTPUT, 1) /* VOUT1_DATA15 */
+ AM65X_IOPAD(0x0040, PIN_OUTPUT, 1) /* VOUT1_DATA16 */
+ AM65X_IOPAD(0x0044, PIN_OUTPUT, 1) /* VOUT1_DATA17 */
+ AM65X_IOPAD(0x0048, PIN_OUTPUT, 1) /* VOUT1_DATA18 */
+ AM65X_IOPAD(0x004c, PIN_OUTPUT, 1) /* VOUT1_DATA19 */
+ AM65X_IOPAD(0x0050, PIN_OUTPUT, 1) /* VOUT1_DATA20 */
+ AM65X_IOPAD(0x0054, PIN_OUTPUT, 1) /* VOUT1_DATA21 */
+ AM65X_IOPAD(0x0058, PIN_OUTPUT, 1) /* VOUT1_DATA22 */
+ AM65X_IOPAD(0x005c, PIN_OUTPUT, 1) /* VOUT1_DATA23 */
+ AM65X_IOPAD(0x0060, PIN_OUTPUT, 1) /* VOUT1_VSYNC */
+ AM65X_IOPAD(0x0064, PIN_OUTPUT, 1) /* VOUT1_HSYNC */
+ AM65X_IOPAD(0x0068, PIN_OUTPUT, 1) /* VOUT1_PCLK */
+ AM65X_IOPAD(0x006c, PIN_OUTPUT, 1) /* VOUT1_DE */
+ >;
+ };
+
+ dp_pins_default: dp-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0078, PIN_OUTPUT, 7) /* (AF18) DP rst_n */
+ >;
+ };
+
+ main_i2c2_pins_default: main-i2c2-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0074, PIN_INPUT, 5) /* (T27) I2C2_SCL */
+ AM65X_IOPAD(0x0070, PIN_INPUT, 5) /* (R25) I2C2_SDA */
+ >;
+ };
+};
+
+&main_pmx1 {
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0000, PIN_INPUT, 0) /* (D20) I2C0_SCL */
+ AM65X_IOPAD(0x0004, PIN_INPUT, 0) /* (C21) I2C0_SDA */
+ >;
+ };
+
+ main_i2c1_pins_default: main-i2c1-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0008, PIN_INPUT, 0) /* (B21) I2C1_SCL */
+ AM65X_IOPAD(0x000c, PIN_INPUT, 0) /* (E21) I2C1_SDA */
+ >;
+ };
+
+ ecap0_pins_default: ecap0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x0010, PIN_INPUT, 0) /* (D21) ECAP0_IN_APWM_OUT */
+ >;
+ };
+};
+
+&wkup_uart0 {
+ /* Wakeup UART is used by System firmware */
+ status = "reserved";
+};
+
+&main_uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart1_pins_default>;
+};
+
+&main_uart2 {
+ status = "disabled";
+};
+
+&mcu_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&arduino_uart_pins_default>;
+};
+
+&main_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&arduino_io_d4_to_d9_pins_default>;
+ gpio-line-names =
+ "main_gpio0-base", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "", "", "",
+ "", "", "", "IO4", "", "IO5", "", "", "IO6", "",
+ "", "", "", "IO7", "", "", "", "", "IO8", "",
+ "", "IO9";
+};
+
+&wkup_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &arduino_io_d2_to_d3_pins_default
+ &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 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&mcu_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_i2c0_pins_default>;
+ clock-frequency = <400000>;
+
+ psu: regulator@60 {
+ compatible = "ti,tps62363";
+ reg = <0x60>;
+ regulator-name = "tps62363-vout";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-boot-on;
+ ti,vsel0-state-high;
+ 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 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ clock-frequency = <400000>;
+
+ rtc: rtc8564@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+
+ eeprom: eeprom@54 {
+ compatible = "atmel,24c08";
+ reg = <0x54>;
+ pagesize = <16>;
+ };
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&main_i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c2_pins_default>;
+ clock-frequency = <400000>;
+};
+
+&main_i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ edp-bridge@f {
+ compatible = "toshiba,tc358767";
+ reg = <0x0f>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp_pins_default>;
+ reset-gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+
+ clock-names = "ref";
+ clocks = <&dp_refclk>;
+
+ toshiba,hpd-pin = <0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ bridge_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+ };
+};
+
+&mcu_cpsw {
+ status = "disabled";
+};
+
+&ecap0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ecap0_pins_default>;
+};
+
+&sdhci1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+};
+
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_pins_default>;
+ dr_mode = "host";
+};
+
+&usb1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins_default>;
+ dr_mode = "host";
+};
+
+&mcu_spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_spi0_pins_default>;
+
+ #address-cells = <1>;
+ #size-cells= <0>;
+ ti,pindir-d0-out-d1-in = <1>;
+
+ spidev@0 {
+ compatible = "rohm,dh2228fv";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ };
+};
+
+&tscadc0 {
+ status = "disabled";
+};
+
+&tscadc1 {
+ adc {
+ ti,adc-channels = <0 1 2 3 4 5>;
+ };
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ spi-max-frequency = <50000000>;
+ cdns,tshsl-ns = <60>;
+ cdns,tsd2d-ns = <60>;
+ cdns,tchsh-ns = <60>;
+ cdns,tslch-ns = <60>;
+ cdns,read-delay = <2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+};
+
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dss_vout1_pins_default>;
+
+ assigned-clocks = <&k3_clks 67 2>;
+ assigned-clock-parents = <&k3_clks 67 5>;
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@1 {
+ reg = <1>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&bridge_in>;
+ };
+ };
+};
+
+&serdes0 {
+ status = "disabled";
+};
+
+&pcie0_rc {
+ status = "disabled";
+};
+
+&pcie0_ep {
+ status = "disabled";
+};
+
+&pcie1_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&minipcie_pins_default>;
+
+ num-lanes = <1>;
+ phys = <&serdes1 PHY_TYPE_PCIE 0>;
+ phy-names = "pcie-phy0";
+ reset-gpios = <&wkup_gpio0 27 GPIO_ACTIVE_HIGH>;
+};
+
+&pcie1_ep {
+ status = "disabled";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
new file mode 100644
index 000000000000..4f7e3f2a6265
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6528-iot2050-basic.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * AM6528-based (dual-core) IOT2050 Basic variant
+ * 1 GB RAM, no eMMC, main_uart0 on connector X30
+ */
+
+/dts-v1/;
+
+#include "k3-am65-iot2050-common.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-basic", "ti,am654";
+ model = "SIMATIC IOT2050 Basic";
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 1G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x40000000>;
+ };
+
+ cpus {
+ cpu-map {
+ /delete-node/ cluster1;
+ };
+ /delete-node/ cpu@100;
+ /delete-node/ cpu@101;
+ };
+
+ /delete-node/ l2-cache1;
+};
+
+/* eMMC */
+&sdhci0 {
+ status = "disabled";
+};
+
+&main_pmx0 {
+ main_uart0_pins_default: main-uart0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01e4, PIN_INPUT, 0) /* (AF11) UART0_RXD */
+ AM65X_IOPAD(0x01e8, PIN_OUTPUT, 0) /* (AE11) UART0_TXD */
+ AM65X_IOPAD(0x01ec, PIN_INPUT, 0) /* (AG11) UART0_CTSn */
+ AM65X_IOPAD(0x01f0, PIN_OUTPUT, 0) /* (AD11) UART0_RTSn */
+ AM65X_IOPAD(0x0188, PIN_INPUT, 1) /* (D25) UART0_DCDn */
+ AM65X_IOPAD(0x018c, PIN_INPUT, 1) /* (B26) UART0_DSRn */
+ AM65X_IOPAD(0x0190, PIN_OUTPUT, 1) /* (A24) UART0_DTRn */
+ AM65X_IOPAD(0x0194, PIN_INPUT, 1) /* (E24) UART0_RIN */
+ >;
+ };
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
new file mode 100644
index 000000000000..ec9617c13cdb
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am6548-iot2050-advanced.dts
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) Siemens AG, 2018-2021
+ *
+ * Authors:
+ * Le Jin <le.jin@siemens.com>
+ * Jan Kiszka <jan.kiszk@siemens.com>
+ *
+ * AM6548-based (quad-core) IOT2050 Advanced variant
+ * 2 GB RAM, 16 GB eMMC, USB-serial converter on connector X30
+ */
+
+/dts-v1/;
+
+#include "k3-am65-iot2050-common.dtsi"
+
+/ {
+ compatible = "siemens,iot2050-advanced", "ti,am654";
+ model = "SIMATIC IOT2050 Advanced";
+
+ memory@80000000 {
+ device_type = "memory";
+ /* 2G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>;
+ };
+};
+
+&main_pmx0 {
+ main_mmc0_pins_default: main-mmc0-pins-default {
+ pinctrl-single,pins = <
+ AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /* (B25) MMC0_CLK */
+ AM65X_IOPAD(0x01ac, PIN_INPUT_PULLUP, 0) /* (B27) MMC0_CMD */
+ AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0) /* (A26) MMC0_DAT0 */
+ AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0) /* (E25) MMC0_DAT1 */
+ AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0) /* (C26) MMC0_DAT2 */
+ AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0) /* (A25) MMC0_DAT3 */
+ AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0) /* (E24) MMC0_DAT4 */
+ AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0) /* (A24) MMC0_DAT5 */
+ AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0) /* (B26) MMC0_DAT6 */
+ AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0) /* (D25) MMC0_DAT7 */
+ AM65X_IOPAD(0x01b8, PIN_OUTPUT_PULLUP, 7) /* (B23) MMC0_SDWP */
+ AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0) /* (A23) MMC0_SDCD */
+ AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /* (C25) MMC0_DS */
+ >;
+ };
+};
+
+/* eMMC */
+&sdhci0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc0_pins_default>;
+ bus-width = <8>;
+ non-removable;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+};
+
+&main_uart0 {
+ status = "disabled";
+};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-10 9:37 ` Jan Kiszka
@ 2021-03-11 13:17 ` Nishanth Menon
-1 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 13:17 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 10:37-20210310, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> + spidev@0 {
> + compatible = "rohm,dh2228fv";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
Jan,
As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
#629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
compatible = "rohm,dh2228fv";
I cannot pick up nodes that are'nt documented as yaml in
Documentation/devicetree
I know this is irritating to find such nodes that already have previous
users and the person coming last gets to deal with "new rules".. but
sorry for catching this so late.
Here are the options that come to mind:
option 1) - drop the node and resubmit.
option 2) - get the documentation into linux master tree and then submit
the patches.
I think we should just drop the node and resubmit - since this is a more
intrusive change and I don't have your platform handy, I am going to
suggest you make a call :(
Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
see more than a few warnings there which may need some closer look.
A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/
PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
I have been using my script to verify with kpv -C -V -n num_patches and
then digging through the logs.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 13:17 ` Nishanth Menon
0 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 13:17 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 10:37-20210310, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
> + spidev@0 {
> + compatible = "rohm,dh2228fv";
> + spi-max-frequency = <20000000>;
> + reg = <0>;
Jan,
As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
#629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
compatible = "rohm,dh2228fv";
I cannot pick up nodes that are'nt documented as yaml in
Documentation/devicetree
I know this is irritating to find such nodes that already have previous
users and the person coming last gets to deal with "new rules".. but
sorry for catching this so late.
Here are the options that come to mind:
option 1) - drop the node and resubmit.
option 2) - get the documentation into linux master tree and then submit
the patches.
I think we should just drop the node and resubmit - since this is a more
intrusive change and I don't have your platform handy, I am going to
suggest you make a call :(
Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
see more than a few warnings there which may need some closer look.
A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/
PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
I have been using my script to verify with kpv -C -V -n num_patches and
then digging through the logs.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 13:17 ` Nishanth Menon
@ 2021-03-11 13:44 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 13:44 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 14:17, Nishanth Menon wrote:
> On 10:37-20210310, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> + spidev@0 {
>> + compatible = "rohm,dh2228fv";
>> + spi-max-frequency = <20000000>;
>> + reg = <0>;
>
> Jan,
>
> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
>
> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> compatible = "rohm,dh2228fv";
>
> I cannot pick up nodes that are'nt documented as yaml in
> Documentation/devicetree
>
> I know this is irritating to find such nodes that already have previous
> users and the person coming last gets to deal with "new rules".. but
> sorry for catching this so late.
>
> Here are the options that come to mind:
>
> option 1) - drop the node and resubmit.
>
> option 2) - get the documentation into linux master tree and then submit
> the patches.
>
As you said, I'm not setting a precedence here:
arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
Was just just never documented as binding? Or why is no one allowed to
use this anymore? What is to be used instead for spidev?
>
> I think we should just drop the node and resubmit - since this is a more
> intrusive change and I don't have your platform handy, I am going to
> suggest you make a call :(
This breaks userspace here, and we would need to carry that node on top.
BTW, I already brought up the topic internally to get you some boards
for testing.
>
> Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
> see more than a few warnings there which may need some closer look.
>
I've done that and addressed all that I could (former patch 4). We
import those from k3, and I don't feel confident how to resolve them.
See also v1 of this patch.
Jan
>
> A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/
>
>
> PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
>
> I have been using my script to verify with kpv -C -V -n num_patches and
> then digging through the logs.
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 13:44 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 13:44 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 14:17, Nishanth Menon wrote:
> On 10:37-20210310, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> + spidev@0 {
>> + compatible = "rohm,dh2228fv";
>> + spi-max-frequency = <20000000>;
>> + reg = <0>;
>
> Jan,
>
> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
>
> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> compatible = "rohm,dh2228fv";
>
> I cannot pick up nodes that are'nt documented as yaml in
> Documentation/devicetree
>
> I know this is irritating to find such nodes that already have previous
> users and the person coming last gets to deal with "new rules".. but
> sorry for catching this so late.
>
> Here are the options that come to mind:
>
> option 1) - drop the node and resubmit.
>
> option 2) - get the documentation into linux master tree and then submit
> the patches.
>
As you said, I'm not setting a precedence here:
arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
Was just just never documented as binding? Or why is no one allowed to
use this anymore? What is to be used instead for spidev?
>
> I think we should just drop the node and resubmit - since this is a more
> intrusive change and I don't have your platform handy, I am going to
> suggest you make a call :(
This breaks userspace here, and we would need to carry that node on top.
BTW, I already brought up the topic internally to get you some boards
for testing.
>
> Additionally please install yamlint and dtbs_schema -> run dtbs_check. I
> see more than a few warnings there which may need some closer look.
>
I've done that and addressed all that I could (former patch 4). We
import those from k3, and I don't feel confident how to resolve them.
See also v1 of this patch.
Jan
>
> A full log against linux-next is here: https://pastebin.ubuntu.com/p/qR69h28c5f/
>
>
> PS: https://github.com/nmenon/kernel_patch_verify/blob/master/kpv
>
> I have been using my script to verify with kpv -C -V -n num_patches and
> then digging through the logs.
>
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 13:44 ` Jan Kiszka
@ 2021-03-11 14:00 ` Nishanth Menon
-1 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 14:00 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 14:44-20210311, Jan Kiszka wrote:
> On 11.03.21 14:17, Nishanth Menon wrote:
> > On 10:37-20210310, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >> + spidev@0 {
> >> + compatible = "rohm,dh2228fv";
> >> + spi-max-frequency = <20000000>;
> >> + reg = <0>;
> >
> > Jan,
> >
> > As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
> >
> > WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
> > #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> > compatible = "rohm,dh2228fv";
> >
> > I cannot pick up nodes that are'nt documented as yaml in
> > Documentation/devicetree
> >
> > I know this is irritating to find such nodes that already have previous
> > users and the person coming last gets to deal with "new rules".. but
> > sorry for catching this so late.
> >
> > Here are the options that come to mind:
> >
> > option 1) - drop the node and resubmit.
> >
> > option 2) - get the documentation into linux master tree and then submit
> > the patches.
> >
>
> As you said, I'm not setting a precedence here:
>
> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>
> Was just just never documented as binding? Or why is no one allowed to
> use this anymore? What is to be used instead for spidev?
See [1] compare the compatibles against
Documentation/devicetree/bindings -> I think you should describe what
your hardware really is though.
Unfortunately devicetree migration has been far from being smooth.. it
was like chewing an elephant - linux community had to attack it in
pieces..
Yes - it was unfortunately one of those cases where the driver support
was introduced long back and no binding was introduced at that time (it
was'nt mandatory then).. then we added a mandatory requirement that it
be documented in txt.. over years realized things are'nt great with
unstructured txt description of binding, now moving on converting
existing txt files to yaml and schemas to static check the dts...
evolution over the years, I guess.
I am on a fight internally as well to have all our legacy txt files
converted over to yaml.. and am having to put up a stance - see [2]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
[2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
> >
> > I think we should just drop the node and resubmit - since this is a more
> > intrusive change and I don't have your platform handy, I am going to
> > suggest you make a call :(
>
> This breaks userspace here, and we would need to carry that node on top.
>
Uggh... that sucks.. but I think that would be lower tradeoff to make
than me (as it stands now) having to drop the patch series.
> BTW, I already brought up the topic internally to get you some boards
> for testing.
Thanks.. While it might help me personally to get some on my internal
farm, it might be good to get them on kernelci as well on the longer
run.
>
> I've done that and addressed all that I could (former patch 4). We
> import those from k3, and I don't feel confident how to resolve them.
> See also v1 of this patch.
Yeah - i noticed that upstream dt-schema has gotten even more stricter
even though the dts has remained the same.. I need to spend time in
digging at it.
At this point the only big kicker is the checkpatch stuff which I cant
let through - if i do that arnd will probably kick everything from my
PR out :( - which I cant do.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 14:00 ` Nishanth Menon
0 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 14:00 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 14:44-20210311, Jan Kiszka wrote:
> On 11.03.21 14:17, Nishanth Menon wrote:
> > On 10:37-20210310, Jan Kiszka wrote:
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >> + spidev@0 {
> >> + compatible = "rohm,dh2228fv";
> >> + spi-max-frequency = <20000000>;
> >> + reg = <0>;
> >
> > Jan,
> >
> > As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
> >
> > WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
> > #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
> > compatible = "rohm,dh2228fv";
> >
> > I cannot pick up nodes that are'nt documented as yaml in
> > Documentation/devicetree
> >
> > I know this is irritating to find such nodes that already have previous
> > users and the person coming last gets to deal with "new rules".. but
> > sorry for catching this so late.
> >
> > Here are the options that come to mind:
> >
> > option 1) - drop the node and resubmit.
> >
> > option 2) - get the documentation into linux master tree and then submit
> > the patches.
> >
>
> As you said, I'm not setting a precedence here:
>
> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>
> Was just just never documented as binding? Or why is no one allowed to
> use this anymore? What is to be used instead for spidev?
See [1] compare the compatibles against
Documentation/devicetree/bindings -> I think you should describe what
your hardware really is though.
Unfortunately devicetree migration has been far from being smooth.. it
was like chewing an elephant - linux community had to attack it in
pieces..
Yes - it was unfortunately one of those cases where the driver support
was introduced long back and no binding was introduced at that time (it
was'nt mandatory then).. then we added a mandatory requirement that it
be documented in txt.. over years realized things are'nt great with
unstructured txt description of binding, now moving on converting
existing txt files to yaml and schemas to static check the dts...
evolution over the years, I guess.
I am on a fight internally as well to have all our legacy txt files
converted over to yaml.. and am having to put up a stance - see [2]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
[2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
> >
> > I think we should just drop the node and resubmit - since this is a more
> > intrusive change and I don't have your platform handy, I am going to
> > suggest you make a call :(
>
> This breaks userspace here, and we would need to carry that node on top.
>
Uggh... that sucks.. but I think that would be lower tradeoff to make
than me (as it stands now) having to drop the patch series.
> BTW, I already brought up the topic internally to get you some boards
> for testing.
Thanks.. While it might help me personally to get some on my internal
farm, it might be good to get them on kernelci as well on the longer
run.
>
> I've done that and addressed all that I could (former patch 4). We
> import those from k3, and I don't feel confident how to resolve them.
> See also v1 of this patch.
Yeah - i noticed that upstream dt-schema has gotten even more stricter
even though the dts has remained the same.. I need to spend time in
digging at it.
At this point the only big kicker is the checkpatch stuff which I cant
let through - if i do that arnd will probably kick everything from my
PR out :( - which I cant do.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 14:00 ` Nishanth Menon
@ 2021-03-11 14:14 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 14:14 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 15:00, Nishanth Menon wrote:
> On 14:44-20210311, Jan Kiszka wrote:
>> On 11.03.21 14:17, Nishanth Menon wrote:
>>> On 10:37-20210310, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>> + spidev@0 {
>>>> + compatible = "rohm,dh2228fv";
>>>> + spi-max-frequency = <20000000>;
>>>> + reg = <0>;
>>>
>>> Jan,
>>>
>>> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
>>>
>>> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
>>> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
>>> compatible = "rohm,dh2228fv";
>>>
>>> I cannot pick up nodes that are'nt documented as yaml in
>>> Documentation/devicetree
>>>
>>> I know this is irritating to find such nodes that already have previous
>>> users and the person coming last gets to deal with "new rules".. but
>>> sorry for catching this so late.
>>>
>>> Here are the options that come to mind:
>>>
>>> option 1) - drop the node and resubmit.
>>>
>>> option 2) - get the documentation into linux master tree and then submit
>>> the patches.
>>>
>>
>> As you said, I'm not setting a precedence here:
>>
>> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
>> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
>> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>>
>> Was just just never documented as binding? Or why is no one allowed to
>> use this anymore? What is to be used instead for spidev?
>
> See [1] compare the compatibles against
> Documentation/devicetree/bindings -> I think you should describe what
> your hardware really is though.
This SPI bus is routed to an Arduino connector. By default, userspace
(e.g. mraa) takes ownership and adds the desired logic for what is being
connected. We have no idea what shield or other extension the user adds,
though.
>
> Unfortunately devicetree migration has been far from being smooth.. it
> was like chewing an elephant - linux community had to attack it in
> pieces..
>
> Yes - it was unfortunately one of those cases where the driver support
> was introduced long back and no binding was introduced at that time (it
> was'nt mandatory then).. then we added a mandatory requirement that it
> be documented in txt.. over years realized things are'nt great with
> unstructured txt description of binding, now moving on converting
> existing txt files to yaml and schemas to static check the dts...
> evolution over the years, I guess.
>
> I am on a fight internally as well to have all our legacy txt files
> converted over to yaml.. and am having to put up a stance - see [2]
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
> [2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
The problem here is not simple txt->yml conversion: There is no official
binding for spidev yet, just existing users and the driver waiting for them.
>>
>>>
>>> I think we should just drop the node and resubmit - since this is a more
>>> intrusive change and I don't have your platform handy, I am going to
>>> suggest you make a call :(
>>
>> This breaks userspace here, and we would need to carry that node on top.
>>
>
> Uggh... that sucks.. but I think that would be lower tradeoff to make
> than me (as it stands now) having to drop the patch series.
>
>> BTW, I already brought up the topic internally to get you some boards
>> for testing.
>
> Thanks.. While it might help me personally to get some on my internal
> farm, it might be good to get them on kernelci as well on the longer
> run.
>
Will keep that on the radar. I definitely want to get it into the CIP
LAVA lab which is testing LTS as well.
>>
>> I've done that and addressed all that I could (former patch 4). We
>> import those from k3, and I don't feel confident how to resolve them.
>> See also v1 of this patch.
>
> Yeah - i noticed that upstream dt-schema has gotten even more stricter
> even though the dts has remained the same.. I need to spend time in
> digging at it.
>
> At this point the only big kicker is the checkpatch stuff which I cant
> let through - if i do that arnd will probably kick everything from my
> PR out :( - which I cant do.
>
Are we talking about spidev here? Then let's drop that node, but I do
need to know how to describe spidev properly
Or is it about those other warnings coming from your dtsi files, now
being surfaced? If you can tell me how to resolve them, I can write patches.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 14:14 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 14:14 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 15:00, Nishanth Menon wrote:
> On 14:44-20210311, Jan Kiszka wrote:
>> On 11.03.21 14:17, Nishanth Menon wrote:
>>> On 10:37-20210310, Jan Kiszka wrote:
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>> + spidev@0 {
>>>> + compatible = "rohm,dh2228fv";
>>>> + spi-max-frequency = <20000000>;
>>>> + reg = <0>;
>>>
>>> Jan,
>>>
>>> As part of my final sanity checks, I noticed that we missed this: is a checkpatch warning
>>>
>>> WARNING: DT compatible string "rohm,dh2228fv" appears un-documented -- check ./Documentation/devicetree/bindings/
>>> #629: FILE: arch/arm64/boot/dts/ti/k3-am65-iot2050-common.dtsi:581:
>>> compatible = "rohm,dh2228fv";
>>>
>>> I cannot pick up nodes that are'nt documented as yaml in
>>> Documentation/devicetree
>>>
>>> I know this is irritating to find such nodes that already have previous
>>> users and the person coming last gets to deal with "new rules".. but
>>> sorry for catching this so late.
>>>
>>> Here are the options that come to mind:
>>>
>>> option 1) - drop the node and resubmit.
>>>
>>> option 2) - get the documentation into linux master tree and then submit
>>> the patches.
>>>
>>
>> As you said, I'm not setting a precedence here:
>>
>> arch/arm/boot/dts/imx28-cfa10049.dts: compatible = "rohm,dh2228fv";
>> arch/arm/boot/dts/rv1108-elgin-r1.dts: compatible = "rohm,dh2228fv";
>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts: compatible = "rohm,dh2228fv";
>> drivers/spi/spidev.c: { .compatible = "rohm,dh2228fv" },
>>
>> Was just just never documented as binding? Or why is no one allowed to
>> use this anymore? What is to be used instead for spidev?
>
> See [1] compare the compatibles against
> Documentation/devicetree/bindings -> I think you should describe what
> your hardware really is though.
This SPI bus is routed to an Arduino connector. By default, userspace
(e.g. mraa) takes ownership and adds the desired logic for what is being
connected. We have no idea what shield or other extension the user adds,
though.
>
> Unfortunately devicetree migration has been far from being smooth.. it
> was like chewing an elephant - linux community had to attack it in
> pieces..
>
> Yes - it was unfortunately one of those cases where the driver support
> was introduced long back and no binding was introduced at that time (it
> was'nt mandatory then).. then we added a mandatory requirement that it
> be documented in txt.. over years realized things are'nt great with
> unstructured txt description of binding, now moving on converting
> existing txt files to yaml and schemas to static check the dts...
> evolution over the years, I guess.
>
> I am on a fight internally as well to have all our legacy txt files
> converted over to yaml.. and am having to put up a stance - see [2]
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c#n678
> [2] https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/T/#u
>
The problem here is not simple txt->yml conversion: There is no official
binding for spidev yet, just existing users and the driver waiting for them.
>>
>>>
>>> I think we should just drop the node and resubmit - since this is a more
>>> intrusive change and I don't have your platform handy, I am going to
>>> suggest you make a call :(
>>
>> This breaks userspace here, and we would need to carry that node on top.
>>
>
> Uggh... that sucks.. but I think that would be lower tradeoff to make
> than me (as it stands now) having to drop the patch series.
>
>> BTW, I already brought up the topic internally to get you some boards
>> for testing.
>
> Thanks.. While it might help me personally to get some on my internal
> farm, it might be good to get them on kernelci as well on the longer
> run.
>
Will keep that on the radar. I definitely want to get it into the CIP
LAVA lab which is testing LTS as well.
>>
>> I've done that and addressed all that I could (former patch 4). We
>> import those from k3, and I don't feel confident how to resolve them.
>> See also v1 of this patch.
>
> Yeah - i noticed that upstream dt-schema has gotten even more stricter
> even though the dts has remained the same.. I need to spend time in
> digging at it.
>
> At this point the only big kicker is the checkpatch stuff which I cant
> let through - if i do that arnd will probably kick everything from my
> PR out :( - which I cant do.
>
Are we talking about spidev here? Then let's drop that node, but I do
need to know how to describe spidev properly
Or is it about those other warnings coming from your dtsi files, now
being surfaced? If you can tell me how to resolve them, I can write patches.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 14:14 ` Jan Kiszka
@ 2021-03-11 14:21 ` Nishanth Menon
-1 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 14:21 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 15:14-20210311, Jan Kiszka wrote:
[...]
> >
> > See [1] compare the compatibles against
> > Documentation/devicetree/bindings -> I think you should describe what
> > your hardware really is though.
>
> This SPI bus is routed to an Arduino connector. By default, userspace
> (e.g. mraa) takes ownership and adds the desired logic for what is being
> connected. We have no idea what shield or other extension the user adds,
> though.
overlays look like the right approach for variable systems like these.
It is not exactly plug and play.. but it does provide a level of
flexibility that is helpful.
[..]
> The problem here is not simple txt->yml conversion: There is no official
> binding for spidev yet, just existing users and the driver waiting for them.
>
I think we should discuss in the spidev list to get it resolved.
> > Thanks.. While it might help me personally to get some on my internal
> > farm, it might be good to get them on kernelci as well on the longer
> > run.
> >
>
> Will keep that on the radar. I definitely want to get it into the CIP
> LAVA lab which is testing LTS as well.
Cool.
> Are we talking about spidev here? Then let's drop that node, but I do
> need to know how to describe spidev properly
yes - the spidev is my problem. can you drop the node and repost? i cant
locally modify and hope it works.
>
> Or is it about those other warnings coming from your dtsi files, now
> being surfaced? If you can tell me how to resolve them, I can write patches.
I will look at the warnings later today.. I dont think they are
triggered by the board dts.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 14:21 ` Nishanth Menon
0 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 14:21 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 15:14-20210311, Jan Kiszka wrote:
[...]
> >
> > See [1] compare the compatibles against
> > Documentation/devicetree/bindings -> I think you should describe what
> > your hardware really is though.
>
> This SPI bus is routed to an Arduino connector. By default, userspace
> (e.g. mraa) takes ownership and adds the desired logic for what is being
> connected. We have no idea what shield or other extension the user adds,
> though.
overlays look like the right approach for variable systems like these.
It is not exactly plug and play.. but it does provide a level of
flexibility that is helpful.
[..]
> The problem here is not simple txt->yml conversion: There is no official
> binding for spidev yet, just existing users and the driver waiting for them.
>
I think we should discuss in the spidev list to get it resolved.
> > Thanks.. While it might help me personally to get some on my internal
> > farm, it might be good to get them on kernelci as well on the longer
> > run.
> >
>
> Will keep that on the radar. I definitely want to get it into the CIP
> LAVA lab which is testing LTS as well.
Cool.
> Are we talking about spidev here? Then let's drop that node, but I do
> need to know how to describe spidev properly
yes - the spidev is my problem. can you drop the node and repost? i cant
locally modify and hope it works.
>
> Or is it about those other warnings coming from your dtsi files, now
> being surfaced? If you can tell me how to resolve them, I can write patches.
I will look at the warnings later today.. I dont think they are
triggered by the board dts.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 14:21 ` Nishanth Menon
@ 2021-03-11 14:36 ` Jan Kiszka
-1 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 14:36 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 15:21, Nishanth Menon wrote:
> On 15:14-20210311, Jan Kiszka wrote:
>
> [...]
>
>>>
>>> See [1] compare the compatibles against
>>> Documentation/devicetree/bindings -> I think you should describe what
>>> your hardware really is though.
>>
>> This SPI bus is routed to an Arduino connector. By default, userspace
>> (e.g. mraa) takes ownership and adds the desired logic for what is being
>> connected. We have no idea what shield or other extension the user adds,
>> though.
>
> overlays look like the right approach for variable systems like these.
> It is not exactly plug and play.. but it does provide a level of
> flexibility that is helpful.
Yes, that's for extensions which have kernel drivers. The default model
here is userspace, though. Will add as a separate patch to our queue for
now.
>
> [..]
>> The problem here is not simple txt->yml conversion: There is no official
>> binding for spidev yet, just existing users and the driver waiting for them.
>>
>
> I think we should discuss in the spidev list to get it resolved.
>
>>> Thanks.. While it might help me personally to get some on my internal
>>> farm, it might be good to get them on kernelci as well on the longer
>>> run.
>>>
>>
>> Will keep that on the radar. I definitely want to get it into the CIP
>> LAVA lab which is testing LTS as well.
>
> Cool.
>
>> Are we talking about spidev here? Then let's drop that node, but I do
>> need to know how to describe spidev properly
>
> yes - the spidev is my problem. can you drop the node and repost? i cant
> locally modify and hope it works.
>
Done.
>>
>> Or is it about those other warnings coming from your dtsi files, now
>> being surfaced? If you can tell me how to resolve them, I can write patches.
>
> I will look at the warnings later today.. I dont think they are
> triggered by the board dts.
>
That was also my interpretation of the results. Some are even just
copies from what you get for the EVM boards.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 14:36 ` Jan Kiszka
0 siblings, 0 replies; 22+ messages in thread
From: Jan Kiszka @ 2021-03-11 14:36 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 11.03.21 15:21, Nishanth Menon wrote:
> On 15:14-20210311, Jan Kiszka wrote:
>
> [...]
>
>>>
>>> See [1] compare the compatibles against
>>> Documentation/devicetree/bindings -> I think you should describe what
>>> your hardware really is though.
>>
>> This SPI bus is routed to an Arduino connector. By default, userspace
>> (e.g. mraa) takes ownership and adds the desired logic for what is being
>> connected. We have no idea what shield or other extension the user adds,
>> though.
>
> overlays look like the right approach for variable systems like these.
> It is not exactly plug and play.. but it does provide a level of
> flexibility that is helpful.
Yes, that's for extensions which have kernel drivers. The default model
here is userspace, though. Will add as a separate patch to our queue for
now.
>
> [..]
>> The problem here is not simple txt->yml conversion: There is no official
>> binding for spidev yet, just existing users and the driver waiting for them.
>>
>
> I think we should discuss in the spidev list to get it resolved.
>
>>> Thanks.. While it might help me personally to get some on my internal
>>> farm, it might be good to get them on kernelci as well on the longer
>>> run.
>>>
>>
>> Will keep that on the radar. I definitely want to get it into the CIP
>> LAVA lab which is testing LTS as well.
>
> Cool.
>
>> Are we talking about spidev here? Then let's drop that node, but I do
>> need to know how to describe spidev properly
>
> yes - the spidev is my problem. can you drop the node and repost? i cant
> locally modify and hope it works.
>
Done.
>>
>> Or is it about those other warnings coming from your dtsi files, now
>> being surfaced? If you can tell me how to resolve them, I can write patches.
>
> I will look at the warnings later today.. I dont think they are
> triggered by the board dts.
>
That was also my interpretation of the results. Some are even just
copies from what you get for the EVM boards.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
2021-03-11 14:36 ` Jan Kiszka
@ 2021-03-11 17:56 ` Nishanth Menon
-1 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 17:56 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 15:36-20210311, Jan Kiszka wrote:
> On 11.03.21 15:21, Nishanth Menon wrote:
> > On 15:14-20210311, Jan Kiszka wrote:
> >
> > [...]
> >
> >>>
> >>> See [1] compare the compatibles against
> >>> Documentation/devicetree/bindings -> I think you should describe what
> >>> your hardware really is though.
> >>
> >> This SPI bus is routed to an Arduino connector. By default, userspace
> >> (e.g. mraa) takes ownership and adds the desired logic for what is being
> >> connected. We have no idea what shield or other extension the user adds,
> >> though.
> >
> > overlays look like the right approach for variable systems like these.
> > It is not exactly plug and play.. but it does provide a level of
> > flexibility that is helpful.
>
> Yes, that's for extensions which have kernel drivers. The default model
> here is userspace, though. Will add as a separate patch to our queue for
> now.
My colleagues did some checkups and pulled up a few thread on spidev
of potential interests..
See:
https://patchwork.kernel.org/project/spi-devel-general/patch/1427499742-26916-1-git-send-email-broonie@kernel.org/
https://yurovsky.github.io/2016/10/07/spidev-linux-devices.html
etc...
I'd split the spidev node alone as an addendum indicate the checkpatch
warning, describe the details and loop in spidev list, Mark, et.al. to
discuss the direction. I am hoping we can get this resolved or get a
direction for .13-rc1
But that said, I see some examples such as
for i in `git grep ".compatible" drivers/spi/spidev.c|grep =|cut -d '=' -f2|cut -d ' ' -f2`; do git grep $i Documentation/devicetree/bindings/; done
Documentation/devicetree/bindings/spi/spi-mux.yaml: compatible = "lineartechnology,ltc2488";
Documentation/devicetree/bindings/misc/ge-achc.txt:- compatible : Should be "ge,achc"
Documentation/devicetree/bindings/misc/ge-achc.txt: compatible = "ge,achc";
Documentation/devicetree/bindings/misc/lwn-bk4.txt:- compatible : Should be "lwn,bk4"
Documentation/devicetree/bindings/misc/lwn-bk4.txt: compatible = "lwn,bk4";
So, the shield could be hosting one of those say
ge,achc or maybe lwn,bk4 ?- will probably be good to document the
dts is for such a configuration, though it is possible that such a
configuration might work for others?
I agree with Mark that "dt should indicate specific hardware" and we
should constraint the definition in such a scope?
[...]
> >
> >> Are we talking about spidev here? Then let's drop that node, but I do
> >> need to know how to describe spidev properly
> >
> > yes - the spidev is my problem. can you drop the node and repost? i cant
> > locally modify and hope it works.
> >
>
> Done.
Thanks, I will try and pick up the v5 later today - need to redo my
sanity checkups.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v4 3/3] arm64: dts: ti: Add support for Siemens IOT2050 boards
@ 2021-03-11 17:56 ` Nishanth Menon
0 siblings, 0 replies; 22+ messages in thread
From: Nishanth Menon @ 2021-03-11 17:56 UTC (permalink / raw)
To: Jan Kiszka
Cc: Tero Kristo, Rob Herring, linux-arm-kernel, linux-kernel,
devicetree, Le Jin, Bao Cheng Su, Vignesh Raghavendra
On 15:36-20210311, Jan Kiszka wrote:
> On 11.03.21 15:21, Nishanth Menon wrote:
> > On 15:14-20210311, Jan Kiszka wrote:
> >
> > [...]
> >
> >>>
> >>> See [1] compare the compatibles against
> >>> Documentation/devicetree/bindings -> I think you should describe what
> >>> your hardware really is though.
> >>
> >> This SPI bus is routed to an Arduino connector. By default, userspace
> >> (e.g. mraa) takes ownership and adds the desired logic for what is being
> >> connected. We have no idea what shield or other extension the user adds,
> >> though.
> >
> > overlays look like the right approach for variable systems like these.
> > It is not exactly plug and play.. but it does provide a level of
> > flexibility that is helpful.
>
> Yes, that's for extensions which have kernel drivers. The default model
> here is userspace, though. Will add as a separate patch to our queue for
> now.
My colleagues did some checkups and pulled up a few thread on spidev
of potential interests..
See:
https://patchwork.kernel.org/project/spi-devel-general/patch/1427499742-26916-1-git-send-email-broonie@kernel.org/
https://yurovsky.github.io/2016/10/07/spidev-linux-devices.html
etc...
I'd split the spidev node alone as an addendum indicate the checkpatch
warning, describe the details and loop in spidev list, Mark, et.al. to
discuss the direction. I am hoping we can get this resolved or get a
direction for .13-rc1
But that said, I see some examples such as
for i in `git grep ".compatible" drivers/spi/spidev.c|grep =|cut -d '=' -f2|cut -d ' ' -f2`; do git grep $i Documentation/devicetree/bindings/; done
Documentation/devicetree/bindings/spi/spi-mux.yaml: compatible = "lineartechnology,ltc2488";
Documentation/devicetree/bindings/misc/ge-achc.txt:- compatible : Should be "ge,achc"
Documentation/devicetree/bindings/misc/ge-achc.txt: compatible = "ge,achc";
Documentation/devicetree/bindings/misc/lwn-bk4.txt:- compatible : Should be "lwn,bk4"
Documentation/devicetree/bindings/misc/lwn-bk4.txt: compatible = "lwn,bk4";
So, the shield could be hosting one of those say
ge,achc or maybe lwn,bk4 ?- will probably be good to document the
dts is for such a configuration, though it is possible that such a
configuration might work for others?
I agree with Mark that "dt should indicate specific hardware" and we
should constraint the definition in such a scope?
[...]
> >
> >> Are we talking about spidev here? Then let's drop that node, but I do
> >> need to know how to describe spidev properly
> >
> > yes - the spidev is my problem. can you drop the node and repost? i cant
> > locally modify and hope it works.
> >
>
> Done.
Thanks, I will try and pick up the v5 later today - need to redo my
sanity checkups.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2021-03-11 17:58 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 9:37 [PATCH v4 0/3] arm64: Add TI AM65x-based IOT2050 boards Jan Kiszka
2021-03-10 9:37 ` Jan Kiszka
2021-03-10 9:37 ` [PATCH v4 1/3] dt-bindings: Add Siemens vendor prefix Jan Kiszka
2021-03-10 9:37 ` Jan Kiszka
2021-03-10 9:37 ` [PATCH v4 2/3] dt-bindings: arm: ti: Add bindings for Siemens IOT2050 boards Jan Kiszka
2021-03-10 9:37 ` Jan Kiszka
2021-03-10 9:37 ` [PATCH v4 3/3] arm64: dts: ti: Add support " Jan Kiszka
2021-03-10 9:37 ` Jan Kiszka
2021-03-11 13:17 ` Nishanth Menon
2021-03-11 13:17 ` Nishanth Menon
2021-03-11 13:44 ` Jan Kiszka
2021-03-11 13:44 ` Jan Kiszka
2021-03-11 14:00 ` Nishanth Menon
2021-03-11 14:00 ` Nishanth Menon
2021-03-11 14:14 ` Jan Kiszka
2021-03-11 14:14 ` Jan Kiszka
2021-03-11 14:21 ` Nishanth Menon
2021-03-11 14:21 ` Nishanth Menon
2021-03-11 14:36 ` Jan Kiszka
2021-03-11 14:36 ` Jan Kiszka
2021-03-11 17:56 ` Nishanth Menon
2021-03-11 17:56 ` Nishanth Menon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.