* [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb
@ 2024-01-12 17:12 Josua Mayer
2024-01-12 17:12 ` [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
` (4 more replies)
0 siblings, 5 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer, Krzysztof Kozlowski, Suman Anna,
Grygorii Strashko, MD Danish Anwar
This series adds DT bindings and dts descriptions for SolidRun AM642
based SoM and Hummingboard EVB.
Additionally a commit from downstream vendor kernel are included,
enhancing support for pru based ethernet.
I wasn't sure how to properly annotate it in commit description /
signed-off area ...:
1. add description for "Industrial Ethernet Peripherals" (IEP) to am64
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/arch/arm64/boot/dts/ti/k3-am64-main.dtsi?h=ti-linux-6.1.y-cicd&id=5afb73d82a014b59462162d960b350b8c58e5ae6
IEP is already supported in-tree by a driver, and used in
k3-am65-main.dtsi.
Unfortunately dtbs_check reported many problems, I put some remarks:
- 'mux-controller' does not match any of the regexes
The expectation seems to be that a mux-controller at minimum has an
address, something to put behind an @. However this is a gpio mux, not
sure how to name it better.
- unevaluated properties: interrupts, interrupt-parent
sensors and flash yaml are missing interrupt descriptions, but these
parts definitely have an interrupt signal in this solidrun board.
- icssg1-eth dmas is too long
It is caused by definint 12 dmas, when ti,icssg-prueth.yaml specifies a
maximum of 10. The pru ethernet on am64 mostly identical to am65 - see
e.g. arch/arm64/boot/dts/ti/k3-am654-idk.dtso which also defines 12 dma.
I cannot fix it because unsure what is the purpose of last two dmas.
- wrong names for pinctrl nodes
Other TI DTSs consistently end with *-pins-default. Should a different
naming convention be used?
- cdns,phy-type required property
inherited from k3-am64-main.dtsi
there is a PHY_NONE value in dt-bindings/phy/phy.h,
but not allowed in phy-cadence-torrent.yaml
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v2:
- reordered patchset to drop separate patch adding iep handle to som
- moved dtbs_check warnings to cover letter
- converted abracon abx80x rtc bindings to yaml
- updated dts:
- remove unnecessary status properties
- changed non-generic node names
- use color property for led descriptions,
they have no default function on evaluation board
- drop earlycon bootargs from chosen node
(reported by Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>)
- converted charger node to comment, part not assembled, has no bindings
- picked up acked-by on board bindings patch
- Link to v1: https://lore.kernel.org/r/20240103-add-am64-som-v1-0-dda1f9227aef@solid-run.com
---
Josua Mayer (4):
dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T
dt-bindings: rtc: abx80x: convert to yaml
arm64: dts: add description for solidrun am642 som and evaluation board
arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3
Suman Anna (1):
arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +
.../devicetree/bindings/rtc/abracon,abx80x.txt | 31 -
.../devicetree/bindings/rtc/abracon,abx80x.yaml | 56 ++
arch/arm64/boot/dts/ti/Makefile | 3 +
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 24 +
.../boot/dts/ti/k3-am642-hummingboard-t-pcie.dts | 31 +
.../boot/dts/ti/k3-am642-hummingboard-t-usb3.dts | 37 ++
arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts | 326 +++++++++++
arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++
9 files changed, 1122 insertions(+), 31 deletions(-)
---
base-commit: 861deac3b092f37b2c5e6871732f3e11486f7082
change-id: 20240101-add-am64-som-51a1ca47edf3
Sincerely,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply [flat|nested] 23+ messages in thread
* [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
@ 2024-01-12 17:12 ` Josua Mayer
2024-01-12 17:12 ` [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml Josua Mayer
` (3 subsequent siblings)
4 siblings, 0 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer, Krzysztof Kozlowski
Add bindings for SolidRun AM642 HummingBoard-T Board, which is the
evaluation board for SolidRun AM642 SoM.
Signed-off-by: Josua Mayer <josua@solid-run.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 03d2a0d79fb0..b9f2a8d36874 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -85,6 +85,13 @@ properties:
- const: tq,am642-tqma6442l
- const: ti,am642
+ - description: K3 AM642 SoC SolidRun SoM based boards
+ items:
+ - enum:
+ - solidrun,am642-hummingboard-t
+ - const: solidrun,am642-sr-som
+ - const: ti,am642
+
- description: K3 AM654 SoC
items:
- enum:
--
2.35.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
2024-01-12 17:12 ` [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
@ 2024-01-12 17:12 ` Josua Mayer
2024-01-12 17:18 ` Krzysztof Kozlowski
2024-01-12 17:12 ` [PATCH v2 3/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer
` (2 subsequent siblings)
4 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer
Convert the abracon abx80x rtc text bindings to dt-schema format.
Additionally added "interrupts" property which was missing from text
format, because abx80x and driver support them.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
.../devicetree/bindings/rtc/abracon,abx80x.txt | 31 ------------
.../devicetree/bindings/rtc/abracon,abx80x.yaml | 56 ++++++++++++++++++++++
2 files changed, 56 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt b/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
deleted file mode 100644
index 2405e35a1bc0..000000000000
--- a/Documentation/devicetree/bindings/rtc/abracon,abx80x.txt
+++ /dev/null
@@ -1,31 +0,0 @@
-Abracon ABX80X I2C ultra low power RTC/Alarm chip
-
-The Abracon ABX80X family consist of the ab0801, ab0803, ab0804, ab0805, ab1801,
-ab1803, ab1804 and ab1805. The ab0805 is the superset of ab080x and the ab1805
-is the superset of ab180x.
-
-Required properties:
-
- - "compatible": should one of:
- "abracon,abx80x"
- "abracon,ab0801"
- "abracon,ab0803"
- "abracon,ab0804"
- "abracon,ab0805"
- "abracon,ab1801"
- "abracon,ab1803"
- "abracon,ab1804"
- "abracon,ab1805"
- "microcrystal,rv1805"
- Using "abracon,abx80x" will enable chip autodetection.
- - "reg": I2C bus address of the device
-
-Optional properties:
-
-The abx804 and abx805 have a trickle charger that is able to charge the
-connected battery or supercap. Both the following properties have to be defined
-and valid to enable charging:
-
- - "abracon,tc-diode": should be "standard" (0.6V) or "schottky" (0.3V)
- - "abracon,tc-resistor": should be <0>, <3>, <6> or <11>. 0 disables the output
- resistor, the other values are in kOhm.
diff --git a/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
new file mode 100644
index 000000000000..c80d4a46a044
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
+
+maintainers: []
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ anyOf:
+ - description: auto-detection from id register
+ const: abracon,abx80x
+ - const: abracon,,ab0801
+ - const: abracon,,ab0803
+ - const: abracon,,ab0804
+ - const: abracon,,ab0805
+ - const: abracon,,ab1801
+ - const: abracon,,ab1803
+ - const: abracon,,ab1804
+ - const: abracon,,ab1805
+ - const: microcrystal,rv1805
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ abracon,tc-diode:
+ description:
+ Trickle-charge diode type.
+ Required to enable charging backup battery.
+ anyOf:
+ - description: standard diode with 0.6V drop
+ const: standard
+ - description: schottky diode with 0.3V drop
+ const: schottky
+
+ abracon,tc-resistor:
+ description:
+ Trickle-charge resistor value in kOhm.
+ Required to enable charging backup battery.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 3, 6, 11]
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
--
2.35.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v2 3/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
2024-01-12 17:12 ` [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
2024-01-12 17:12 ` [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml Josua Mayer
@ 2024-01-12 17:12 ` Josua Mayer
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
2024-01-12 17:12 ` [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer
4 siblings, 0 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer, Suman Anna, Grygorii Strashko,
MD Danish Anwar
From: Suman Anna <s-anna@ti.com>
The ICSSG IP on AM64x SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
derived from either of the IP instance's ICSSG_IEP_GCLK or from another
internal ICSSG CORE_CLK mux. Add both the IEP nodes for both the ICSSG
instances. The IEP clock is currently configured to be derived
indirectly from the ICSSG_ICLK running at 250 MHz.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
index 0be642bc1b86..8130ee02a3d9 100644
--- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi
@@ -1232,6 +1232,18 @@ icssg0_iepclk_mux: iepclk-mux@30 {
};
};
+ icssg0_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <&icssg0_iepclk_mux>;
+ };
+
+ icssg0_iep1: iep@2f000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2f000 0x1000>;
+ clocks = <&icssg0_iepclk_mux>;
+ };
+
icssg0_mii_rt: mii-rt@32000 {
compatible = "ti,pruss-mii", "syscon";
reg = <0x32000 0x100>;
@@ -1373,6 +1385,18 @@ icssg1_iepclk_mux: iepclk-mux@30 {
};
};
+ icssg1_iep0: iep@2e000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2e000 0x1000>;
+ clocks = <&icssg1_iepclk_mux>;
+ };
+
+ icssg1_iep1: iep@2f000 {
+ compatible = "ti,am654-icss-iep";
+ reg = <0x2f000 0x1000>;
+ clocks = <&icssg1_iepclk_mux>;
+ };
+
icssg1_mii_rt: mii-rt@32000 {
compatible = "ti,pruss-mii", "syscon";
reg = <0x32000 0x100>;
--
2.35.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
` (2 preceding siblings ...)
2024-01-12 17:12 ` [PATCH v2 3/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer
@ 2024-01-12 17:12 ` Josua Mayer
2024-01-12 17:22 ` Krzysztof Kozlowski
2024-01-12 17:50 ` Andrew Davis
2024-01-12 17:12 ` [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer
4 siblings, 2 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer
Add description for the SolidRun AM642 SoM, and HummingBoard-T
evaluation board.
The SoM features:
- 1x cpsw ethernet with phy
- 2x pru ethernet with phy
- eMMC
- spi flash (assembly option)
Additionally microSD and usb-2.0 otg are included in the SoM
description as they are supported boot sources for the SOC boot-rom.
The Carrier provides:
- 3x RJ45 connector
- 2x M.2 connector
- USB-2.0 Hub
- USB-A Connector
- LEDs
- 2x CAN transceiver
- 1x RS485 transceiver
- sensors
The M.2 connectors support either USB-3.1 or PCI-E depending on status
of a mux. By default the mux is switched off.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/ti/Makefile | 1 +
arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts | 326 +++++++++++
arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++
3 files changed, 965 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 77a347f9f47d..041c3b71155e 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
# Boards with AM64x SoC
dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts
new file mode 100644
index 000000000000..52171ff8fcb7
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for SolidRun AM642 HummingBoard-T,
+ * running on Cortex A53.
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy.h>
+
+#include "k3-am642.dtsi"
+#include "k3-am642-sr-som.dtsi"
+
+/ {
+ model = "SolidRun AM642 HummingBoard-T";
+ compatible = "solidrun,am642-hummingboard-t", "solidrun,am642-sr-som", "ti,am642";
+
+ aliases {
+ serial5 = &main_uart3;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_pins_default>;
+
+ /* D24 */
+ led1: led-1 {
+ label = "led1";
+ gpios = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ /* D25 */
+ led2: led-2 {
+ label = "led2";
+ gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ /* D26 */
+ led3: led-3 {
+ label = "led3";
+ gpios = <&main_gpio0 33 GPIO_ACTIVE_HIGH>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+ };
+
+ regulator-m2-3v3 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <®ulator_pcie_3v3_pins_default>;
+ regulator-name = "m2-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&main_gpio1 17 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ regulator-vpp-1v8 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <®ulator_vpp_1v8_pins_default>;
+ regulator-name = "vpp-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&main_gpio1 78 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ serdes_mux: mux-controller {
+ compatible = "gpio-mux";
+ pinctrl-names = "default";
+ pinctrl-0 = <&serdes_mux_pins_default>;
+ #mux-control-cells = <0>;
+ /*
+ * Mux has 2 IOs:
+ * - select: 0 = USB-3 (M2); 1 = PCIE (M1)
+ * - shutdown: 0 = active; 1 = disabled (high impedance)
+ */
+ mux-gpios = <&main_gpio1 40 GPIO_ACTIVE_HIGH>, <&main_gpio1 41 GPIO_ACTIVE_HIGH>;
+ /* default disabled */
+ idle-state = <2>;
+ };
+};
+
+&main_gpio0 {
+ m2-reset-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_LOW>;
+ output-low; /* deasserted */
+ line-name = "m2-reset";
+ };
+
+ m1-m2-w-disable1-hog {
+ gpio-hog;
+ gpios = <32 GPIO_ACTIVE_LOW>;
+ output-low; /* deasserted */
+ line-name = "m1-m2-pcie-w-disable1";
+ };
+
+ m1-m2-w_disable2-hog {
+ gpio-hog;
+ gpios = <34 GPIO_ACTIVE_LOW>;
+ output-low; /* deasserted */
+ line-name = "m1-m2-pcie-w-disable2";
+ };
+};
+
+&main_gpio1 {
+ status = "okay";
+
+ m1-pcie-clkreq0-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "m1-pcie-clkreq0";
+ };
+
+ m2-pcie-clkreq-hog {
+ gpio-hog;
+ gpios = <35 GPIO_ACTIVE_LOW>;
+ input;
+ line-name = "m2-pcie-clkreq";
+ };
+};
+
+&main_i2c0 {
+ pinctrl-0 = <&main_i2c0_pins_default>, <&main_i2c0_int_pins_default>;
+
+ humidity-sensor@41 {
+ compatible = "ti,hdc2010";
+ reg = <0x41>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <37 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ light-sensor@44 {
+ compatible = "ti,opt3001";
+ reg = <0x44>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <37 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ /* charger@6a */
+};
+
+&main_i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>;
+ status = "okay";
+
+ rtc@69 {
+ compatible = "abracon,abx80x";
+ reg = <0x69>;
+ abracon,tc-diode = "schottky";
+ abracon,tc-resistor = <3>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <44 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&main_mcan0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan0_pins_default>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <8000000>;
+ };
+};
+
+&main_mcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcan1_pins_default>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <8000000>;
+ };
+};
+
+&main_pmx0 {
+ leds_pins_default: leds-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0074, PIN_OUTPUT, 7) /* GPMC0_AD14.GPIO0_29 */
+ AM64X_IOPAD(0x0078, PIN_OUTPUT, 7) /* GPMC0_AD15.GPIO0_30 */
+ AM64X_IOPAD(0x0088, PIN_OUTPUT, 7) /* GPMC0_OEn_REn.GPIO0_33 */
+ >;
+ };
+
+ main_i2c0_int_pins_default: main-i2c0-pins-int-default {
+ pinctrl-single,pins = <
+ /* external pull-up on Carrier */
+ AM64X_IOPAD(0x0098, PIN_INPUT, 7) /* GPMC0_WAIT0.GPIO0_37 */
+ >;
+ };
+
+ main_i2c1_pins_default: main-i2c1-pins-default {
+ pinctrl-single,pins = <
+ /* external pull-up on SoM */
+ AM64X_IOPAD(0x0268, PIN_INPUT, 0) /* I2C1_SCL.I2C1_SCL */
+ AM64X_IOPAD(0x026c, PIN_INPUT, 0) /* I2C1_SDA.I2C1_SDA */
+ >;
+ };
+
+ main_i2c1_int_pins_default: main-i2c1-int-pins-default {
+ pinctrl-single,pins = <
+ /* external pull-up on Carrier */
+ AM64X_IOPAD(0x00b4, PIN_INPUT, 7) /* GPMC0_CSn3.GPIO0_44 */
+ >;
+ };
+
+ main_mcan0_pins_default: main-mcan0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0254, PIN_INPUT, 0) /* MCAN0_RX.MCAN0_RX */
+ AM64X_IOPAD(0x0250, PIN_OUTPUT, 0) /* MCAN0_TX.MCAN0_TX */
+ >;
+ };
+
+ main_mcan1_pins_default: main-mcan1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x025c, PIN_INPUT, 0) /* MCAN1_RX.MCAN1_RX */
+ AM64X_IOPAD(0x0258, PIN_OUTPUT, 0) /* MCAN1_TX.MCAN1_TX */
+ >;
+ };
+
+ main_uart3_pins_default: main-uart3-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x016c, PIN_INPUT, 10) /* PRG0_PRU0_GPO3.UART3_CTSn */
+ AM64X_IOPAD(0x0170, PIN_OUTPUT, 10) /* PRG0_PRU0_GPO4.UART3_TXD */
+ AM64X_IOPAD(0x0174, PIN_OUTPUT, 10) /* PRG0_PRU0_GPO5.UART3_RTSn */
+ AM64X_IOPAD(0x01ac, PIN_INPUT, 10) /* PRG0_PRU0_GPO19.UART3_RXD */
+ >;
+ };
+
+ pcie0_pins_default: pcie0-pins-default {
+ pinctrl-single,pins = <
+ /* connector M2 RESET */
+ AM64X_IOPAD(0x0030, PIN_OUTPUT, 7) /* OSPI0_CSn1.GPIO0_12 */
+ /* connectors M1 & M2 W_DISABLE1 */
+ AM64X_IOPAD(0x0084, PIN_OUTPUT, 7) /* GPMC0_ADVN_ALE.GPIO0_32 */
+ /* connectors M1 & M2 W_DISABLE2 */
+ AM64X_IOPAD(0x008c, PIN_OUTPUT, 7) /* GPMC0_WEN.GPIO0_34 */
+ /* connectors M1 & M2 PERST0 (PCI Reset) */
+ AM64X_IOPAD(0x019c, PIN_OUTPUT, 7) /* PRG0_PRU0_GPO15.GPIO1_15 */
+ /* connector M1 CLKREQ0 */
+ AM64X_IOPAD(0x018c, PIN_INPUT, 7) /* PRG0_PRU0_GPO11.GPIO1_11 */
+ /* connector M2 CLKREQ0 */
+ AM64X_IOPAD(0x01ec, PIN_INPUT, 7) /* PRG0_PRU1_GPO15.GPIO1_35 */
+ >;
+ };
+
+ regulator_pcie_3v3_pins_default: regulator-pcie-3v3-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01a4, PIN_OUTPUT, 7) /* PRG0_PRU0_GPO17.GPIO1_17 */
+ >;
+ };
+
+ regulator_vpp_1v8_pins_default: regulator-vpp-1v8-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x029c, PIN_OUTPUT, 7) /* MMC1_SDWP.GPIO1_78 */
+ >;
+ };
+
+ serdes_mux_pins_default: serdes-mux-pins-default {
+ pinctrl-single,pins = <
+ /* SEL, 10k pull-down on carrier, 2.2k pullup on SoM */
+ AM64X_IOPAD(0x0200, PIN_OUTPUT, 7) /* PRG0_MDIO0_MDIO.GPIO1_40 */
+ /* EN */
+ AM64X_IOPAD(0x0204, PIN_OUTPUT, 7) /* PRG0_MDIO0_MDC.GPIO1_41 */
+ >;
+ };
+};
+
+&main_uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart3_pins_default>;
+ uart-has-rtscts;
+ rs485-rts-active-low;
+ linux,rs485-enabled-at-boot-time;
+ status = "okay";
+};
+
+&pcie0_rc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie0_pins_default>;
+ reset-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
+ phys = <&serdes0_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+ mux-controls = <&serdes_mux>;
+ mux-control-names = "serdes";
+ status = "disabled";
+};
+
+&pcie0_ep {
+ phys = <&serdes0_link>;
+ phy-names = "pcie-phy";
+ num-lanes = <1>;
+ status = "disabled";
+};
+
+&serdes0 {
+ /*
+ * Serdes Signals are routed via mux to either m.2 connectors:
+ * - M1: USB-3.1
+ * - M2: PCI-E
+ */
+
+ serdes0_link: phy@0 {
+ reg = <0>;
+ cdns,num-lanes = <1>;
+ #phy-cells = <0>;
+ resets = <&serdes_wiz0 1>;
+ };
+};
+
+&usb0 {
+ dr_mode = "host";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi
new file mode 100644
index 000000000000..8560c3a6e69b
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi
@@ -0,0 +1,638 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
+ *
+ */
+
+#include <dt-bindings/net/ti-dp83869.h>
+
+/ {
+ model = "SolidRun AM642 SoM";
+ compatible = "solidrun,am642-sr-som", "ti,am642";
+
+ aliases {
+ ethernet0 = &cpsw_port1;
+ ethernet1 = &icssg1_emac0;
+ ethernet2 = &icssg1_emac1;
+ mmc0 = &sdhci0;
+ mmc1 = &sdhci1;
+ serial2 = &main_uart0;
+ };
+
+ chosen {
+ /* SoC default UART console */
+ stdout-path = "serial2:115200n8";
+ };
+
+ /* PRU Ethernet Controller */
+ icssg1_eth: icssg1-eth {
+ compatible = "ti,am642-icssg-prueth";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
+
+ sram = <&oc_sram>;
+ ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
+ firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
+ "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
+
+ ti,pruss-gp-mux-sel = <2>, /* MII mode */
+ <2>,
+ <2>,
+ <2>, /* MII mode */
+ <2>,
+ <2>;
+
+ ti,mii-g-rt = <&icssg1_mii_g_rt>;
+ ti,mii-rt = <&icssg1_mii_rt>;
+ ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
+
+ interrupt-parent = <&icssg1_intc>;
+ interrupts = <24 0 2>, <25 1 3>;
+ interrupt-names = "tx_ts0", "tx_ts1";
+
+ dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
+ <&main_pktdma 0xc201 15>, /* egress slice 0 */
+ <&main_pktdma 0xc202 15>, /* egress slice 0 */
+ <&main_pktdma 0xc203 15>, /* egress slice 0 */
+ <&main_pktdma 0xc204 15>, /* egress slice 1 */
+ <&main_pktdma 0xc205 15>, /* egress slice 1 */
+ <&main_pktdma 0xc206 15>, /* egress slice 1 */
+ <&main_pktdma 0xc207 15>, /* egress slice 1 */
+ <&main_pktdma 0x4200 15>, /* ingress slice 0 */
+ <&main_pktdma 0x4201 15>, /* ingress slice 1 */
+ <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
+ <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
+ dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
+ "tx1-0", "tx1-1", "tx1-2", "tx1-3",
+ "rx0", "rx1";
+
+ status = "okay";
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ icssg1_emac0: port@0 {
+ reg = <0>;
+ ti,syscon-rgmii-delay = <&main_conf 0x4110>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <ðernet_phy2>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+ };
+
+ icssg1_emac1: port@1 {
+ reg = <1>;
+ ti,syscon-rgmii-delay = <&main_conf 0x4114>;
+ /* Filled in by bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <ðernet_phy1>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+ };
+ };
+ };
+
+ /* DDR16SS0:
+ * - Bank 1 @ 0x080000000-0x0FFFFFFFF: max. 2GB in 32-bit address space
+ * - Bank 2 @ 0x880000000-0x9FFFFFFFF: max. 6GB in 64-bit address space
+ */
+ memory@80000000 {
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000001 0x80000000>;
+ device_type = "memory";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+
+ main_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0000000 0x00 0x100000>;
+ no-map;
+ };
+
+ main_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+
+ main_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa1000000 0x00 0x100000>;
+ no-map;
+ };
+
+ main_r5fss0_core1_memory_region: r5f-memory@a1100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa1100000 0x00 0xf00000>;
+ no-map;
+ };
+
+ main_r5fss1_core0_dma_memory_region: r5f-dma-memory@a2000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa2000000 0x00 0x100000>;
+ no-map;
+ };
+
+ main_r5fss1_core0_memory_region: r5f-memory@a2100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa2100000 0x00 0xf00000>;
+ no-map;
+ };
+
+ main_r5fss1_core1_dma_memory_region: r5f-dma-memory@a3000000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa3000000 0x00 0x100000>;
+ no-map;
+ };
+
+ main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa3100000 0x00 0xf00000>;
+ no-map;
+ };
+ };
+
+ vdd_mmc0: regulator-vdd-mmc0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd-mmc0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&cpsw3g {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>;
+ status = "okay";
+};
+
+&cpsw3g_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio0_pins_default>;
+ status = "okay";
+
+ ethernet_phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-id2000.a0f1";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet_phy0_pins_default>;
+ ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
+ ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
+ /*
+ * Disable interrupts because ISR never clears 0x0040
+ *
+ * interrupt-parent = <&main_gpio1>;
+ * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
+ */
+ /*
+ * Disable HW Reset because clock signal is daisy-chained
+ *
+ * reset-gpios = <&main_gpio0 84 GPIO_ACTIVE_LOW>;
+ * reset-assert-us = <1>;
+ * reset-deassert-us = <30>;
+ */
+ status = "okay";
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-id";
+ phy-handle = <ðernet_phy0>;
+ status = "okay";
+};
+
+&cpsw_port2 {
+ status = "disabled";
+};
+
+&icssg0_mdio {
+ status = "disabled";
+};
+
+&icssg1_mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pru1_mdio0_pins_default>;
+ status = "okay";
+
+ ethernet_phy1: ethernet-phy@3 {
+ compatible = "ethernet-phy-id2000.a0f1";
+ reg = <3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet_phy1_pins_default>;
+ ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
+ ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
+ /*
+ * Disable interrupts because ISR never clears 0x0040
+ *
+ * interrupt-parent = <&main_gpio1>;
+ * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
+ */
+ /*
+ * Disable HW Reset because clock signal is daisy-chained
+ *
+ * reset-gpios = <&main_gpio0 20 GPIO_ACTIVE_LOW>;
+ * reset-assert-us = <1>;
+ * reset-deassert-us = <30>;
+ */
+ status = "okay";
+ };
+
+ ethernet_phy2: ethernet-phy@f {
+ compatible = "ethernet-phy-id2000.a0f1";
+ reg = <0xf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet_phy2_pins_default>;
+ ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
+ /*
+ * Disable interrupts because ISR never clears 0x0040
+ *
+ * interrupt-parent = <&main_gpio1>;
+ * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
+ */
+ /*
+ * Disable HW Reset because clock signal is daisy-chained
+ *
+ * reset-gpios = <&main_gpio0 52 GPIO_ACTIVE_LOW>;
+ * reset-assert-us = <1>;
+ * reset-deassert-us = <30>;
+ */
+ status = "okay";
+ };
+};
+
+&mailbox0_cluster2 {
+ status = "okay";
+
+ mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
+ ti,mbox-rx = <0 0 2>;
+ ti,mbox-tx = <1 0 2>;
+ };
+
+ mbox_main_r5fss0_core1: mbox-main-r5fss0-core1 {
+ ti,mbox-rx = <2 0 2>;
+ ti,mbox-tx = <3 0 2>;
+ };
+};
+
+&mailbox0_cluster3 {
+ status = "disabled";
+};
+
+&mailbox0_cluster4 {
+ status = "okay";
+
+ mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
+ ti,mbox-rx = <0 0 2>;
+ ti,mbox-tx = <1 0 2>;
+ };
+
+ mbox_main_r5fss1_core1: mbox-main-r5fss1-core1 {
+ ti,mbox-rx = <2 0 2>;
+ ti,mbox-tx = <3 0 2>;
+ };
+};
+
+&mailbox0_cluster5 {
+ status = "disabled";
+};
+
+&mailbox0_cluster6 {
+ status = "disabled";
+};
+
+&mailbox0_cluster7 {
+ status = "disabled";
+};
+
+&main_gpio0 {
+ status = "okay";
+};
+
+&main_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c0_pins_default>;
+ status = "okay";
+
+ som_eeprom: eeprom@50 {
+ compatible = "atmel,24c01";
+ reg = <0x50>;
+ pagesize = <8>;
+ };
+};
+
+&main_pmx0 {
+ /* hog global functions */
+ pinctrl-names = "default";
+ pinctrl-0 = <ðernet_phy_pins_default>;
+
+ ethernet_phy_pins_default: ethernet-phy-pins-default {
+ pinctrl-single,pins = <
+ /* interrupt / power-down, external pull-up on SoM */
+ AM64X_IOPAD(0x0278, PIN_INPUT, 7) /* EXTINTn.GPIO1_70 */
+ >;
+ };
+
+ ethernet_phy0_pins_default: ethernet-phy0-pins-default {
+ pinctrl-single,pins = <
+ /* reset */
+ AM64X_IOPAD(0x0154, PIN_OUTPUT, 7) /* PRG1_PRU1_GPO19.GPIO0_84 */
+ /* reference clock */
+ AM64X_IOPAD(0x0274, PIN_OUTPUT, 5) /* EXT_REFCLK1.CLKOUT0 */
+ >;
+ };
+
+ ethernet_phy1_pins_default: ethernet-phy1-pins-default {
+ pinctrl-single,pins = <
+ /* reset */
+ AM64X_IOPAD(0x0150, PIN_OUTPUT, 7) /* PRG1_PRU1_GPO18.GPIO0_20 */
+ /* led0, external pull-down on SoM */
+ AM64X_IOPAD(0x0128, PIN_INPUT, 7) /* PRG1_PRU1_GPO8.GPIO0_73 */
+ /* led1/rxer */
+ AM64X_IOPAD(0x011c, PIN_INPUT, 7) /* PRG1_PRU1_GPO5.GPIO0_70 */
+ >;
+ };
+
+ ethernet_phy2_pins_default: ethernet-phy2-pins-default {
+ pinctrl-single,pins = <
+ /* reset */
+ AM64X_IOPAD(0x00d4, PIN_OUTPUT, 7) /* PRG1_PRU0_GPO7.GPIO0_52 */
+ /* led0, external pull-down on SoM */
+ AM64X_IOPAD(0x00d8, PIN_INPUT, 7) /* PRG1_PRU0_GPO8.GPIO0_53 */
+ /* led1/rxer */
+ AM64X_IOPAD(0x00cc, PIN_INPUT, 7) /* PRG1_PRU0_GPO5.GPIO0_50 */
+ >;
+ };
+
+ main_i2c0_pins_default: main-i2c0-pins-default {
+ pinctrl-single,pins = <
+ /* external pull-up on SoM */
+ AM64X_IOPAD(0x0260, PIN_INPUT, 0) /* I2C0_SCL.I2C0_SCL */
+ AM64X_IOPAD(0x0264, PIN_INPUT, 0) /* I2C0_SDA.I2C0_SDA */
+ >;
+ };
+
+ /*
+ * main_mmc0_pins_default: main-mmc0-pins-default
+ *
+ * MMC0_CMD: no padconfig
+ * MMC0_CLK: no padconfig, external pull-up on SoM
+ * MMC0_DAT0: no padconfig
+ * MMC0_DAT1: no padconfig
+ * MMC0_DAT2: no padconfig
+ * MMC0_DAT3: no padconfig
+ * MMC0_DAT4: no padconfig
+ * MMC0_DAT5: no padconfig
+ * MMC0_DAT6: no padconfig
+ * MMC0_DAT7: no padconfig
+ * MMC0_DS: no padconfig, external pull-down on SoM
+ */
+
+ main_mmc1_pins_default: main-mmc1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0) /* (J19) MMC1_CMD */
+ AM64X_IOPAD(0x028c, PIN_INPUT, 0) /* MMC1_CLK.MMC1_CLK */
+ AM64X_IOPAD(0x0288, PIN_INPUT_PULLUP, 0) /* MMC1_DAT0.MMC1_DAT0 */
+ AM64X_IOPAD(0x0284, PIN_INPUT_PULLUP, 0) /* MMC1_DAT1.MMC1_DAT1 */
+ AM64X_IOPAD(0x0280, PIN_INPUT_PULLUP, 0) /* MMC1_DAT2.MMC1_DAT2 */
+ AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0) /* MMC1_DAT3.MMC1_DAT3 */
+ /* external pull-down on SoM & Carrier */
+ AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0) /* MMC1_SDCD.MMC1_SDCD */
+ AM64X_IOPAD(0x0290, PIN_INPUT, 0) /* MMC1_CLKLB: clock loopback */
+ >;
+ };
+
+ main_uart0_pins_default: main-uart0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0230, PIN_INPUT, 0) /* UART0_RXD.UART0_RXD */
+ AM64X_IOPAD(0x0234, PIN_OUTPUT, 0) /* UART0_TXD.UART0_TXD */
+ >;
+ };
+
+ mdio0_pins_default: mdio0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* PRG0_PRU1_GPO19.MDIO0_MDC */
+ AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* PRG0_PRU1_GPO18.MDIO0_MDIO */
+ >;
+ };
+
+ ospi0_pins_default: ospi0-pins-default {
+ pinctrl-single,pins = <
+ /* external pull-down on SoM */
+ AM64X_IOPAD(0x0000, PIN_OUTPUT, 0) /* OSPI0_CLK.OSPI0_CLK */
+ AM64X_IOPAD(0x0008, PIN_OUTPUT, 0) /* OSPI0_DQS.OSPI0_DQS */
+ /* external pull-up on SoM */
+ AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* OSPI0_CSn0.OSPI0_CSn0 */
+ AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* OSPI0_D0.OSPI0_D0 */
+ AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* OSPI0_D1.OSPI0_D1 */
+ AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* OSPI0_D2.OSPI0_D2 */
+ AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* OSPI0_D3.OSPI0_D3 */
+ AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* OSPI0_D4.OSPI0_D4 */
+ AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* OSPI0_D5.OSPI0_D5 */
+ AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* OSPI0_D6.OSPI0_D6 */
+ AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* OSPI0_D7.OSPI0_D7 */
+ >;
+ };
+
+ ospi0_flash0_pins_default: ospi0-flash0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0034, PIN_OUTPUT, 7) /* OSPI0_CSn2.GPIO0_13 */
+ AM64X_IOPAD(0x0038, PIN_INPUT, 7) /* OSPI0_CSn3.GPIO0_14 */
+ >;
+ };
+
+ pru1_mdio0_pins_default: pru1-mdio0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* PRG1_MDIO0_MDC.PRG1_MDIO0_MDC */
+ AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* PRG1_MDIO0_MDIO.PRG1_MDIO0_MDIO */
+ >;
+ };
+
+ pru_rgmii1_pins_default: pru-rgmii1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
+ AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
+ AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
+ AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
+ AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
+ AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
+ AM64X_IOPAD(0x00e4, PIN_OUTPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
+ AM64X_IOPAD(0x00e8, PIN_OUTPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
+ AM64X_IOPAD(0x00ec, PIN_OUTPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
+ AM64X_IOPAD(0x00f0, PIN_OUTPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
+ AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
+ AM64X_IOPAD(0x00f4, PIN_OUTPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
+ >;
+ };
+
+ pru_rgmii2_pins_default: pru-rgmii2-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* PRG1_PRU1_GPO0.RGMII2_RD0 */
+ AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* PRG1_PRU1_GPO1.RGMII2_RD1 */
+ AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* PRG1_PRU1_GPO2.RGMII2_RD2 */
+ AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* PRG1_PRU1_GPO3.RGMII2_RD3 */
+ AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* PRG1_PRU1_GPO6.RGMII2_RXC */
+ AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* PRG1_PRU1_GPO4.RGMII2_RX_CTL */
+ AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO11.RGMII2_TD0 */
+ AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO12.RGMII2_TD1 */
+ AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO13.RGMII2_TD2 */
+ AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO14.RGMII2_TD3 */
+ AM64X_IOPAD(0x0148, PIN_INPUT, 2) /* PRG1_PRU1_GPO16.RGMII2_TXC */
+ AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO15.RGMII2_TX_CTL */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x01cc, PIN_INPUT, 4) /* PRG0_PRU1_GPO7.RGMII1_RD0 */
+ AM64X_IOPAD(0x01d4, PIN_INPUT, 4) /* PRG0_PRU1_GPO9.RGMII1_RD1 */
+ AM64X_IOPAD(0x01d8, PIN_INPUT, 4) /* PRG0_PRU1_GPO10.RGMII1_RD2 */
+ AM64X_IOPAD(0x01f4, PIN_INPUT, 4) /* PRG0_PRU1_GPO17.RGMII1_RD3 */
+ AM64X_IOPAD(0x0188, PIN_INPUT, 4) /* PRG0_PRU0_GPO10.RGMII1_RXC */
+ AM64X_IOPAD(0x0184, PIN_INPUT, 4) /* PRG0_PRU0_GPO9.RGMII1_RX_CTL */
+ AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO7.RGMII1_TD0 */
+ AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO9.RGMII1_TD1 */
+ AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO10.RGMII1_TD2 */
+ AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO17.RGMII1_TD3 */
+ AM64X_IOPAD(0x00e0, PIN_INPUT, 4) /* PRG1_PRU0_GPO10.RGMII1_TXC */
+ AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* PRG1_PRU0_GPO9.RGMII1_TX_CTL */
+ >;
+ };
+
+ usb0_pins_default: usb0-pins-default {
+ pinctrl-single,pins = <
+ AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* USB0_DRVVBUS.USB0_DRVVBUS */
+ >;
+ };
+};
+
+&main_r5fss0_core0 {
+ mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
+ memory-region = <&main_r5fss0_core0_dma_memory_region>,
+ <&main_r5fss0_core0_memory_region>;
+ status = "okay";
+};
+
+&main_r5fss0_core1 {
+ mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
+ memory-region = <&main_r5fss0_core1_dma_memory_region>,
+ <&main_r5fss0_core1_memory_region>;
+ status = "okay";
+};
+
+&main_r5fss1_core0 {
+ mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
+ memory-region = <&main_r5fss1_core0_dma_memory_region>,
+ <&main_r5fss1_core0_memory_region>;
+ status = "okay";
+};
+
+&main_r5fss1_core1 {
+ mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
+ memory-region = <&main_r5fss1_core1_dma_memory_region>,
+ <&main_r5fss1_core1_memory_region>;
+ status = "okay";
+};
+
+/* SoC default UART console */
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ status = "okay";
+};
+
+&ospi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ospi0_pins_default>;
+ num-cs = <1>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ospi0_flash0_pins_default>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <200000000>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ cdns,read-delay = <0>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&main_gpio0 13 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+};
+
+&sdhci0 {
+ /* mmc0 pins have no padconfig */
+ bus-width = <8>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+ non-removable;
+ cap-mmc-hw-reset;
+ no-sd;
+ /*
+ * MMC controller supports switching between 1.8V and 3.3V signalling.
+ * However MMC0 (unlike MMC1) does not integrate an LDO.
+ * Explicitly link a regulator node for indicating to the driver which
+ * voltages are actually usable.
+ */
+ vqmmc-supply = <&vdd_mmc0>;
+ status = "okay";
+};
+
+/*
+ * microSD is on carrier - however since SoC can boot from it,
+ * configure it just in case.
+ */
+&sdhci1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ bus-width = <4>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+ status = "okay";
+};
+
+&tscadc0 {
+ status = "disabled";
+};
+
+/*
+ * USB settings are a carrier choice - however since SoC can boot from it,
+ * configure as USB-2.0 OTG here, keeping USB-3 serdes disabled.
+ */
+&usb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_pins_default>;
+ dr_mode = "otg";
+ maximum-speed = "high-speed";
+ status = "okay";
+};
+
+&usbss0 {
+ ti,vbus-divider;
+ ti,usb2-only;
+ status = "okay";
+};
--
2.35.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
` (3 preceding siblings ...)
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
@ 2024-01-12 17:12 ` Josua Mayer
2024-01-12 17:58 ` Andrew Davis
4 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-12 17:12 UTC (permalink / raw
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc, Josua Mayer
HummingBoard-T features two M.2 connectors labeled "M1" and "M2".
The single SerDes lane of the SoC can be routed to either M1 pci-e
signals, or M2 usb-3 signals by a gpio-controlled mux.
Add dedicated dts for each configuration.
- k3-am642-hummingboard-t.dts enables neither configuration
- k3-am642-hummingboard-t-pcie.dts (new)
configures serdes mux and pci-e controller for M1
- k3-am642-hummingboard-t-usb3.dts (new)
configures serdes mux and usb-3 controller for M2
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/ti/Makefile | 2 ++
.../boot/dts/ti/k3-am642-hummingboard-t-pcie.dts | 31 ++++++++++++++++++
.../boot/dts/ti/k3-am642-hummingboard-t-usb3.dts | 37 ++++++++++++++++++++++
3 files changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 041c3b71155e..0e408555edf1 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -33,6 +33,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
# Boards with AM64x SoC
dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t-pcie.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t-usb3.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
new file mode 100644
index 000000000000..5ba0029fcfb9
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for SolidRun AM642 HummingBoard-T,
+ * running on Cortex A53, with PCI-E.
+ *
+ */
+
+#include "k3-am642-hummingboard-t.dts"
+#include "k3-serdes.h"
+
+/ {
+ model = "SolidRun AM642 HummingBoard-T with PCI-E";
+};
+
+&pcie0_rc {
+ status = "okay";
+};
+
+&serdes0_link {
+ cdns,phy-type = <PHY_TYPE_PCIE>;
+};
+
+&serdes_ln_ctrl {
+ idle-states = <AM64_SERDES0_LANE0_PCIE0>;
+};
+
+&serdes_mux {
+ idle-state = <1>;
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts
new file mode 100644
index 000000000000..12b0fedcd2bc
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
+ *
+ * DTS for SolidRun AM642 HummingBoard-T,
+ * running on Cortex A53, with USB-3.1 Gen 1.
+ *
+ */
+
+#include "k3-am642-hummingboard-t.dts"
+#include "k3-serdes.h"
+
+/ {
+ model = "SolidRun AM642 HummingBoard-T with USB-3.1 Gen 1";
+};
+
+&serdes0_link {
+ cdns,phy-type = <PHY_TYPE_USB3>;
+};
+
+&serdes_ln_ctrl {
+ idle-states = <AM64_SERDES0_LANE0_USB>;
+};
+
+&serdes_mux {
+ idle-state = <0>;
+};
+
+&usbss0 {
+ /delete-property/ ti,usb2-only;
+};
+
+&usb0 {
+ maximum-speed = "super-speed";
+ phys = <&serdes0_link>;
+ phy-names = "cdns3,usb3-phy";
+};
--
2.35.3
^ permalink raw reply related [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-12 17:12 ` [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml Josua Mayer
@ 2024-01-12 17:18 ` Krzysztof Kozlowski
2024-01-14 15:56 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-12 17:18 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc
On 12/01/2024 18:12, Josua Mayer wrote:
> Convert the abracon abx80x rtc text bindings to dt-schema format.
>
> Additionally added "interrupts" property which was missing from text
> format, because abx80x and driver support them.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
> +
> +maintainers: []
You need a name here. If there is no driver maintainer or anyone
interested, put devicetree list.
> +
> +allOf:
> + - $ref: rtc.yaml#
> +
> +properties:
> + compatible:
> + anyOf:
Please do not invent your own solutions, but use existing code as
template. Just open example-schema or any other recent RTC binding.
> + - description: auto-detection from id register
> + const: abracon,abx80x
> + - const: abracon,,ab0801
> + - const: abracon,,ab0803
> + - const: abracon,,ab0804
> + - const: abracon,,ab0805
> + - const: abracon,,ab1801
> + - const: abracon,,ab1803
> + - const: abracon,,ab1804
> + - const: abracon,,ab1805
> + - const: microcrystal,rv1805
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + abracon,tc-diode:
Missing type - string.
> + description:
> + Trickle-charge diode type.
> + Required to enable charging backup battery.
> + anyOf:
Use enum and explain the meanings of the values in descruption.
> + - description: standard diode with 0.6V drop
> + const: standard
> + - description: schottky diode with 0.3V drop
> + const: schottky
> +
> + abracon,tc-resistor:
> + description:
> + Trickle-charge resistor value in kOhm.
> + Required to enable charging backup battery.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 3, 6, 11]
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
Provide example.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
@ 2024-01-12 17:22 ` Krzysztof Kozlowski
2024-01-14 14:16 ` Josua Mayer
2024-01-12 17:50 ` Andrew Davis
1 sibling, 1 reply; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-12 17:22 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc
On 12/01/2024 18:12, Josua Mayer wrote:
> Add description for the SolidRun AM642 SoM, and HummingBoard-T
> evaluation board.
>
...
> +&main_gpio0 {
> + m2-reset-hog {
> + gpio-hog;
> + gpios = <12 GPIO_ACTIVE_LOW>;
> + output-low; /* deasserted */
> + line-name = "m2-reset";
> + };
> +
> + m1-m2-w-disable1-hog {
> + gpio-hog;
> + gpios = <32 GPIO_ACTIVE_LOW>;
> + output-low; /* deasserted */
> + line-name = "m1-m2-pcie-w-disable1";
> + };
> +
> + m1-m2-w_disable2-hog {
No, underscores are not allowed.
...
> +
> +#include <dt-bindings/net/ti-dp83869.h>
> +
> +/ {
> + model = "SolidRun AM642 SoM";
> + compatible = "solidrun,am642-sr-som", "ti,am642";
> +
> + aliases {
> + ethernet0 = &cpsw_port1;
> + ethernet1 = &icssg1_emac0;
> + ethernet2 = &icssg1_emac1;
> + mmc0 = &sdhci0;
> + mmc1 = &sdhci1;
> + serial2 = &main_uart0;
> + };
> +
> + chosen {
> + /* SoC default UART console */
> + stdout-path = "serial2:115200n8";
> + };
> +
> + /* PRU Ethernet Controller */
> + icssg1_eth: icssg1-eth {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + compatible = "ti,am642-icssg-prueth";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
> +
> + sram = <&oc_sram>;
> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
> +
> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
> + <2>,
> + <2>,
> + <2>, /* MII mode */
> + <2>,
> + <2>;
> +
> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
> + ti,mii-rt = <&icssg1_mii_rt>;
> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
> +
> + interrupt-parent = <&icssg1_intc>;
> + interrupts = <24 0 2>, <25 1 3>;
None of these are typical interrupt constants/flags?
> + interrupt-names = "tx_ts0", "tx_ts1";
> +
> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
> + "rx0", "rx1";
> +
> + status = "okay";
Drop. Didn't you get such comments before?
> +
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + icssg1_emac0: port@0 {
> + reg = <0>;
> + ti,syscon-rgmii-delay = <&main_conf 0x4110>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + phy-handle = <ðernet_phy2>;
> + phy-mode = "rgmii-id";
> + status = "okay";
?
> + };
> +
> + icssg1_emac1: port@1 {
> + reg = <1>;
> + ti,syscon-rgmii-delay = <&main_conf 0x4114>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + phy-handle = <ðernet_phy1>;
> + phy-mode = "rgmii-id";
> + status = "okay";
?
....
> + ethernet_phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id2000.a0f1";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet_phy0_pins_default>;
> + ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
> + ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
> + /*
> + * Disable interrupts because ISR never clears 0x0040
> + *
> + * interrupt-parent = <&main_gpio1>;
> + * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
> + */
> + /*
> + * Disable HW Reset because clock signal is daisy-chained
> + *
> + * reset-gpios = <&main_gpio0 84 GPIO_ACTIVE_LOW>;
> + * reset-assert-us = <1>;
> + * reset-deassert-us = <30>;
> + */
> + status = "okay";
Drop, this applies everywhere where not needed. You have this in
multiple places...
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
2024-01-12 17:22 ` Krzysztof Kozlowski
@ 2024-01-12 17:50 ` Andrew Davis
2024-01-14 15:14 ` Josua Mayer
1 sibling, 1 reply; 23+ messages in thread
From: Andrew Davis @ 2024-01-12 17:50 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc
On 1/12/24 11:12 AM, Josua Mayer wrote:
> Add description for the SolidRun AM642 SoM, and HummingBoard-T
> evaluation board.
>
> The SoM features:
> - 1x cpsw ethernet with phy
> - 2x pru ethernet with phy
> - eMMC
> - spi flash (assembly option)
>
> Additionally microSD and usb-2.0 otg are included in the SoM
> description as they are supported boot sources for the SOC boot-rom.
>
> The Carrier provides:
> - 3x RJ45 connector
> - 2x M.2 connector
> - USB-2.0 Hub
> - USB-A Connector
> - LEDs
> - 2x CAN transceiver
> - 1x RS485 transceiver
> - sensors
>
> The M.2 connectors support either USB-3.1 or PCI-E depending on status
> of a mux. By default the mux is switched off.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> arch/arm64/boot/dts/ti/Makefile | 1 +
> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts | 326 +++++++++++
> arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++
> 3 files changed, 965 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 77a347f9f47d..041c3b71155e 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
>
> # Boards with AM64x SoC
> dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts
> new file mode 100644
> index 000000000000..52171ff8fcb7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts
> @@ -0,0 +1,326 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
> + *
> + * DTS for SolidRun AM642 HummingBoard-T,
> + * running on Cortex A53.
> + *
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/phy/phy.h>
> +
> +#include "k3-am642.dtsi"
> +#include "k3-am642-sr-som.dtsi"
> +
> +/ {
> + model = "SolidRun AM642 HummingBoard-T";
> + compatible = "solidrun,am642-hummingboard-t", "solidrun,am642-sr-som", "ti,am642";
> +
> + aliases {
> + serial5 = &main_uart3;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + /* D24 */
> + led1: led-1 {
> + label = "led1";
> + gpios = <&main_gpio0 29 GPIO_ACTIVE_HIGH>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + /* D25 */
> + led2: led-2 {
> + label = "led2";
> + gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> +
> + /* D26 */
> + led3: led-3 {
> + label = "led3";
> + gpios = <&main_gpio0 33 GPIO_ACTIVE_HIGH>;
> + color = <LED_COLOR_ID_GREEN>;
> + };
> + };
> +
> + regulator-m2-3v3 {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <®ulator_pcie_3v3_pins_default>;
> + regulator-name = "m2-3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&main_gpio1 17 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
> + };
> +
> + regulator-vpp-1v8 {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <®ulator_vpp_1v8_pins_default>;
> + regulator-name = "vpp-1v8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + gpio = <&main_gpio1 78 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + serdes_mux: mux-controller {
> + compatible = "gpio-mux";
> + pinctrl-names = "default";
> + pinctrl-0 = <&serdes_mux_pins_default>;
> + #mux-control-cells = <0>;
> + /*
> + * Mux has 2 IOs:
> + * - select: 0 = USB-3 (M2); 1 = PCIE (M1)
> + * - shutdown: 0 = active; 1 = disabled (high impedance)
> + */
> + mux-gpios = <&main_gpio1 40 GPIO_ACTIVE_HIGH>, <&main_gpio1 41 GPIO_ACTIVE_HIGH>;
> + /* default disabled */
> + idle-state = <2>;
> + };
> +};
> +
> +&main_gpio0 {
> + m2-reset-hog {
> + gpio-hog;
> + gpios = <12 GPIO_ACTIVE_LOW>;
> + output-low; /* deasserted */
> + line-name = "m2-reset";
> + };
> +
> + m1-m2-w-disable1-hog {
> + gpio-hog;
> + gpios = <32 GPIO_ACTIVE_LOW>;
> + output-low; /* deasserted */
> + line-name = "m1-m2-pcie-w-disable1";
> + };
> +
> + m1-m2-w_disable2-hog {
> + gpio-hog;
> + gpios = <34 GPIO_ACTIVE_LOW>;
> + output-low; /* deasserted */
> + line-name = "m1-m2-pcie-w-disable2";
> + };
> +};
> +
> +&main_gpio1 {
> + status = "okay";
> +
> + m1-pcie-clkreq0-hog {
> + gpio-hog;
> + gpios = <11 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "m1-pcie-clkreq0";
> + };
> +
> + m2-pcie-clkreq-hog {
> + gpio-hog;
> + gpios = <35 GPIO_ACTIVE_LOW>;
> + input;
> + line-name = "m2-pcie-clkreq";
> + };
> +};
> +
> +&main_i2c0 {
> + pinctrl-0 = <&main_i2c0_pins_default>, <&main_i2c0_int_pins_default>;
> +
> + humidity-sensor@41 {
> + compatible = "ti,hdc2010";
> + reg = <0x41>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <37 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> + light-sensor@44 {
> + compatible = "ti,opt3001";
> + reg = <0x44>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <37 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> + /* charger@6a */
?
> +};
> +
> +&main_i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>;
The interrupt pin belongs to the rtc@69 and should be in the node below.
> + status = "okay";
> +
> + rtc@69 {
> + compatible = "abracon,abx80x";
> + reg = <0x69>;
> + abracon,tc-diode = "schottky";
> + abracon,tc-resistor = <3>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <44 IRQ_TYPE_EDGE_FALLING>;
> + };
> +};
> +
> +&main_mcan0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan0_pins_default>;
> + status = "okay";
> +
> + can-transceiver {
> + max-bitrate = <8000000>;
> + };
> +};
> +
> +&main_mcan1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan1_pins_default>;
> + status = "okay";
> +
> + can-transceiver {
> + max-bitrate = <8000000>;
> + };
> +};
> +
> +&main_pmx0 {
> + leds_pins_default: leds-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0074, PIN_OUTPUT, 7) /* GPMC0_AD14.GPIO0_29 */
> + AM64X_IOPAD(0x0078, PIN_OUTPUT, 7) /* GPMC0_AD15.GPIO0_30 */
> + AM64X_IOPAD(0x0088, PIN_OUTPUT, 7) /* GPMC0_OEn_REn.GPIO0_33 */
> + >;
> + };
> +
> + main_i2c0_int_pins_default: main-i2c0-pins-int-default {
> + pinctrl-single,pins = <
> + /* external pull-up on Carrier */
> + AM64X_IOPAD(0x0098, PIN_INPUT, 7) /* GPMC0_WAIT0.GPIO0_37 */
> + >;
> + };
> +
> + main_i2c1_pins_default: main-i2c1-pins-default {
> + pinctrl-single,pins = <
> + /* external pull-up on SoM */
> + AM64X_IOPAD(0x0268, PIN_INPUT, 0) /* I2C1_SCL.I2C1_SCL */
> + AM64X_IOPAD(0x026c, PIN_INPUT, 0) /* I2C1_SDA.I2C1_SDA */
> + >;
> + };
> +
> + main_i2c1_int_pins_default: main-i2c1-int-pins-default {
> + pinctrl-single,pins = <
> + /* external pull-up on Carrier */
> + AM64X_IOPAD(0x00b4, PIN_INPUT, 7) /* GPMC0_CSn3.GPIO0_44 */
> + >;
> + };
> +
> + main_mcan0_pins_default: main-mcan0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0254, PIN_INPUT, 0) /* MCAN0_RX.MCAN0_RX */
> + AM64X_IOPAD(0x0250, PIN_OUTPUT, 0) /* MCAN0_TX.MCAN0_TX */
> + >;
> + };
> +
> + main_mcan1_pins_default: main-mcan1-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x025c, PIN_INPUT, 0) /* MCAN1_RX.MCAN1_RX */
> + AM64X_IOPAD(0x0258, PIN_OUTPUT, 0) /* MCAN1_TX.MCAN1_TX */
> + >;
> + };
> +
> + main_uart3_pins_default: main-uart3-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x016c, PIN_INPUT, 10) /* PRG0_PRU0_GPO3.UART3_CTSn */
> + AM64X_IOPAD(0x0170, PIN_OUTPUT, 10) /* PRG0_PRU0_GPO4.UART3_TXD */
> + AM64X_IOPAD(0x0174, PIN_OUTPUT, 10) /* PRG0_PRU0_GPO5.UART3_RTSn */
> + AM64X_IOPAD(0x01ac, PIN_INPUT, 10) /* PRG0_PRU0_GPO19.UART3_RXD */
> + >;
> + };
> +
> + pcie0_pins_default: pcie0-pins-default {
> + pinctrl-single,pins = <
> + /* connector M2 RESET */
> + AM64X_IOPAD(0x0030, PIN_OUTPUT, 7) /* OSPI0_CSn1.GPIO0_12 */
> + /* connectors M1 & M2 W_DISABLE1 */
> + AM64X_IOPAD(0x0084, PIN_OUTPUT, 7) /* GPMC0_ADVN_ALE.GPIO0_32 */
> + /* connectors M1 & M2 W_DISABLE2 */
> + AM64X_IOPAD(0x008c, PIN_OUTPUT, 7) /* GPMC0_WEN.GPIO0_34 */
> + /* connectors M1 & M2 PERST0 (PCI Reset) */
> + AM64X_IOPAD(0x019c, PIN_OUTPUT, 7) /* PRG0_PRU0_GPO15.GPIO1_15 */
> + /* connector M1 CLKREQ0 */
> + AM64X_IOPAD(0x018c, PIN_INPUT, 7) /* PRG0_PRU0_GPO11.GPIO1_11 */
> + /* connector M2 CLKREQ0 */
> + AM64X_IOPAD(0x01ec, PIN_INPUT, 7) /* PRG0_PRU1_GPO15.GPIO1_35 */
> + >;
> + };
> +
> + regulator_pcie_3v3_pins_default: regulator-pcie-3v3-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x01a4, PIN_OUTPUT, 7) /* PRG0_PRU0_GPO17.GPIO1_17 */
> + >;
> + };
> +
> + regulator_vpp_1v8_pins_default: regulator-vpp-1v8-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x029c, PIN_OUTPUT, 7) /* MMC1_SDWP.GPIO1_78 */
> + >;
> + };
> +
> + serdes_mux_pins_default: serdes-mux-pins-default {
> + pinctrl-single,pins = <
> + /* SEL, 10k pull-down on carrier, 2.2k pullup on SoM */
> + AM64X_IOPAD(0x0200, PIN_OUTPUT, 7) /* PRG0_MDIO0_MDIO.GPIO1_40 */
> + /* EN */
> + AM64X_IOPAD(0x0204, PIN_OUTPUT, 7) /* PRG0_MDIO0_MDC.GPIO1_41 */
> + >;
> + };
> +};
> +
> +&main_uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_uart3_pins_default>;
> + uart-has-rtscts;
> + rs485-rts-active-low;
> + linux,rs485-enabled-at-boot-time;
> + status = "okay";
> +};
> +
> +&pcie0_rc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie0_pins_default>;
> + reset-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
> + phys = <&serdes0_link>;
> + phy-names = "pcie-phy";
> + num-lanes = <1>;
> + mux-controls = <&serdes_mux>;
> + mux-control-names = "serdes";
> + status = "disabled";
This node is already default disabled in the parent .dtsi and
has been for more than a year now, you might need to go recheck
if these disables are needed. I see several below that also
are not needed.
> +};
> +
> +&pcie0_ep {
> + phys = <&serdes0_link>;
> + phy-names = "pcie-phy";
> + num-lanes = <1>;
> + status = "disabled";
> +};
Delete this node, added it back if/when you plan to use it
and only in the dt file that adds the rest of the needed
properties.
> +
> +&serdes0 {
> + /*
> + * Serdes Signals are routed via mux to either m.2 connectors:
> + * - M1: USB-3.1
> + * - M2: PCI-E
> + */
> +
> + serdes0_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + resets = <&serdes_wiz0 1>;
> + };
> +};
> +
> +&usb0 {
> + dr_mode = "host";
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi
> new file mode 100644
> index 000000000000..8560c3a6e69b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi
> @@ -0,0 +1,638 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
> + *
> + */
> +
> +#include <dt-bindings/net/ti-dp83869.h>
> +
> +/ {
> + model = "SolidRun AM642 SoM";
> + compatible = "solidrun,am642-sr-som", "ti,am642";
> +
> + aliases {
> + ethernet0 = &cpsw_port1;
> + ethernet1 = &icssg1_emac0;
> + ethernet2 = &icssg1_emac1;
> + mmc0 = &sdhci0;
> + mmc1 = &sdhci1;
> + serial2 = &main_uart0;
> + };
> +
> + chosen {
> + /* SoC default UART console */
> + stdout-path = "serial2:115200n8";
> + };
> +
> + /* PRU Ethernet Controller */
> + icssg1_eth: icssg1-eth {
> + compatible = "ti,am642-icssg-prueth";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
> +
> + sram = <&oc_sram>;
> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
> +
> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
> + <2>,
> + <2>,
> + <2>, /* MII mode */
> + <2>,
> + <2>;
> +
> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
> + ti,mii-rt = <&icssg1_mii_rt>;
> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
> +
> + interrupt-parent = <&icssg1_intc>;
> + interrupts = <24 0 2>, <25 1 3>;
> + interrupt-names = "tx_ts0", "tx_ts1";
> +
> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
> + "rx0", "rx1";
> +
> + status = "okay";
> +
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + icssg1_emac0: port@0 {
> + reg = <0>;
> + ti,syscon-rgmii-delay = <&main_conf 0x4110>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + phy-handle = <ðernet_phy2>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> + };
> +
> + icssg1_emac1: port@1 {
> + reg = <1>;
> + ti,syscon-rgmii-delay = <&main_conf 0x4114>;
> + /* Filled in by bootloader */
> + local-mac-address = [00 00 00 00 00 00];
> + phy-handle = <ðernet_phy1>;
> + phy-mode = "rgmii-id";
> + status = "okay";
> + };
> + };
> + };
> +
> + /* DDR16SS0:
> + * - Bank 1 @ 0x080000000-0x0FFFFFFFF: max. 2GB in 32-bit address space
> + * - Bank 2 @ 0x880000000-0x9FFFFFFFF: max. 6GB in 64-bit address space
> + */
> + memory@80000000 {
> + reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> + <0x00000008 0x80000000 0x00000001 0x80000000>;
> + device_type = "memory";
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + secure_ddr: optee@9e800000 {
> + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
> + alignment = <0x1000>;
Alignment not needed for no-map nodes.
Andrew
> + no-map;
> + };
> +
> + main_r5fss0_core0_dma_memory_region: r5f-dma-memory@a0000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + main_r5fss0_core0_memory_region: r5f-memory@a0100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0100000 0x00 0xf00000>;
> + no-map;
> + };
> +
> + main_r5fss0_core1_dma_memory_region: r5f-dma-memory@a1000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa1000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + main_r5fss0_core1_memory_region: r5f-memory@a1100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa1100000 0x00 0xf00000>;
> + no-map;
> + };
> +
> + main_r5fss1_core0_dma_memory_region: r5f-dma-memory@a2000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa2000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + main_r5fss1_core0_memory_region: r5f-memory@a2100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa2100000 0x00 0xf00000>;
> + no-map;
> + };
> +
> + main_r5fss1_core1_dma_memory_region: r5f-dma-memory@a3000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa3000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + main_r5fss1_core1_memory_region: r5f-memory@a3100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa3100000 0x00 0xf00000>;
> + no-map;
> + };
> + };
> +
> + vdd_mmc0: regulator-vdd-mmc0 {
> + compatible = "regulator-fixed";
> + regulator-name = "vdd-mmc0";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +};
> +
> +&cpsw3g {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii1_pins_default>;
> + status = "okay";
> +};
> +
> +&cpsw3g_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio0_pins_default>;
> + status = "okay";
> +
> + ethernet_phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-id2000.a0f1";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet_phy0_pins_default>;
> + ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
> + ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
> + /*
> + * Disable interrupts because ISR never clears 0x0040
> + *
> + * interrupt-parent = <&main_gpio1>;
> + * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
> + */
> + /*
> + * Disable HW Reset because clock signal is daisy-chained
> + *
> + * reset-gpios = <&main_gpio0 84 GPIO_ACTIVE_LOW>;
> + * reset-assert-us = <1>;
> + * reset-deassert-us = <30>;
> + */
> + status = "okay";
> + };
> +};
> +
> +&cpsw_port1 {
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy0>;
> + status = "okay";
> +};
> +
> +&cpsw_port2 {
> + status = "disabled";
> +};
> +
> +&icssg0_mdio {
> + status = "disabled";
> +};
> +
> +&icssg1_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pru1_mdio0_pins_default>;
> + status = "okay";
> +
> + ethernet_phy1: ethernet-phy@3 {
> + compatible = "ethernet-phy-id2000.a0f1";
> + reg = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet_phy1_pins_default>;
> + ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
> + ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
> + /*
> + * Disable interrupts because ISR never clears 0x0040
> + *
> + * interrupt-parent = <&main_gpio1>;
> + * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
> + */
> + /*
> + * Disable HW Reset because clock signal is daisy-chained
> + *
> + * reset-gpios = <&main_gpio0 20 GPIO_ACTIVE_LOW>;
> + * reset-assert-us = <1>;
> + * reset-deassert-us = <30>;
> + */
> + status = "okay";
> + };
> +
> + ethernet_phy2: ethernet-phy@f {
> + compatible = "ethernet-phy-id2000.a0f1";
> + reg = <0xf>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet_phy2_pins_default>;
> + ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
> + /*
> + * Disable interrupts because ISR never clears 0x0040
> + *
> + * interrupt-parent = <&main_gpio1>;
> + * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
> + */
> + /*
> + * Disable HW Reset because clock signal is daisy-chained
> + *
> + * reset-gpios = <&main_gpio0 52 GPIO_ACTIVE_LOW>;
> + * reset-assert-us = <1>;
> + * reset-deassert-us = <30>;
> + */
> + status = "okay";
> + };
> +};
> +
> +&mailbox0_cluster2 {
> + status = "okay";
> +
> + mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
> + ti,mbox-rx = <0 0 2>;
> + ti,mbox-tx = <1 0 2>;
> + };
> +
> + mbox_main_r5fss0_core1: mbox-main-r5fss0-core1 {
> + ti,mbox-rx = <2 0 2>;
> + ti,mbox-tx = <3 0 2>;
> + };
> +};
> +
> +&mailbox0_cluster3 {
> + status = "disabled";
> +};
> +
> +&mailbox0_cluster4 {
> + status = "okay";
> +
> + mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
> + ti,mbox-rx = <0 0 2>;
> + ti,mbox-tx = <1 0 2>;
> + };
> +
> + mbox_main_r5fss1_core1: mbox-main-r5fss1-core1 {
> + ti,mbox-rx = <2 0 2>;
> + ti,mbox-tx = <3 0 2>;
> + };
> +};
> +
> +&mailbox0_cluster5 {
> + status = "disabled";
> +};
> +
> +&mailbox0_cluster6 {
> + status = "disabled";
> +};
> +
> +&mailbox0_cluster7 {
> + status = "disabled";
> +};
> +
> +&main_gpio0 {
> + status = "okay";
> +};
> +
> +&main_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c0_pins_default>;
> + status = "okay";
> +
> + som_eeprom: eeprom@50 {
> + compatible = "atmel,24c01";
> + reg = <0x50>;
> + pagesize = <8>;
> + };
> +};
> +
> +&main_pmx0 {
> + /* hog global functions */
> + pinctrl-names = "default";
> + pinctrl-0 = <ðernet_phy_pins_default>;
> +
> + ethernet_phy_pins_default: ethernet-phy-pins-default {
> + pinctrl-single,pins = <
> + /* interrupt / power-down, external pull-up on SoM */
> + AM64X_IOPAD(0x0278, PIN_INPUT, 7) /* EXTINTn.GPIO1_70 */
> + >;
> + };
> +
> + ethernet_phy0_pins_default: ethernet-phy0-pins-default {
> + pinctrl-single,pins = <
> + /* reset */
> + AM64X_IOPAD(0x0154, PIN_OUTPUT, 7) /* PRG1_PRU1_GPO19.GPIO0_84 */
> + /* reference clock */
> + AM64X_IOPAD(0x0274, PIN_OUTPUT, 5) /* EXT_REFCLK1.CLKOUT0 */
> + >;
> + };
> +
> + ethernet_phy1_pins_default: ethernet-phy1-pins-default {
> + pinctrl-single,pins = <
> + /* reset */
> + AM64X_IOPAD(0x0150, PIN_OUTPUT, 7) /* PRG1_PRU1_GPO18.GPIO0_20 */
> + /* led0, external pull-down on SoM */
> + AM64X_IOPAD(0x0128, PIN_INPUT, 7) /* PRG1_PRU1_GPO8.GPIO0_73 */
> + /* led1/rxer */
> + AM64X_IOPAD(0x011c, PIN_INPUT, 7) /* PRG1_PRU1_GPO5.GPIO0_70 */
> + >;
> + };
> +
> + ethernet_phy2_pins_default: ethernet-phy2-pins-default {
> + pinctrl-single,pins = <
> + /* reset */
> + AM64X_IOPAD(0x00d4, PIN_OUTPUT, 7) /* PRG1_PRU0_GPO7.GPIO0_52 */
> + /* led0, external pull-down on SoM */
> + AM64X_IOPAD(0x00d8, PIN_INPUT, 7) /* PRG1_PRU0_GPO8.GPIO0_53 */
> + /* led1/rxer */
> + AM64X_IOPAD(0x00cc, PIN_INPUT, 7) /* PRG1_PRU0_GPO5.GPIO0_50 */
> + >;
> + };
> +
> + main_i2c0_pins_default: main-i2c0-pins-default {
> + pinctrl-single,pins = <
> + /* external pull-up on SoM */
> + AM64X_IOPAD(0x0260, PIN_INPUT, 0) /* I2C0_SCL.I2C0_SCL */
> + AM64X_IOPAD(0x0264, PIN_INPUT, 0) /* I2C0_SDA.I2C0_SDA */
> + >;
> + };
> +
> + /*
> + * main_mmc0_pins_default: main-mmc0-pins-default
> + *
> + * MMC0_CMD: no padconfig
> + * MMC0_CLK: no padconfig, external pull-up on SoM
> + * MMC0_DAT0: no padconfig
> + * MMC0_DAT1: no padconfig
> + * MMC0_DAT2: no padconfig
> + * MMC0_DAT3: no padconfig
> + * MMC0_DAT4: no padconfig
> + * MMC0_DAT5: no padconfig
> + * MMC0_DAT6: no padconfig
> + * MMC0_DAT7: no padconfig
> + * MMC0_DS: no padconfig, external pull-down on SoM
> + */
> +
> + main_mmc1_pins_default: main-mmc1-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0294, PIN_INPUT_PULLUP, 0) /* (J19) MMC1_CMD */
> + AM64X_IOPAD(0x028c, PIN_INPUT, 0) /* MMC1_CLK.MMC1_CLK */
> + AM64X_IOPAD(0x0288, PIN_INPUT_PULLUP, 0) /* MMC1_DAT0.MMC1_DAT0 */
> + AM64X_IOPAD(0x0284, PIN_INPUT_PULLUP, 0) /* MMC1_DAT1.MMC1_DAT1 */
> + AM64X_IOPAD(0x0280, PIN_INPUT_PULLUP, 0) /* MMC1_DAT2.MMC1_DAT2 */
> + AM64X_IOPAD(0x027c, PIN_INPUT_PULLUP, 0) /* MMC1_DAT3.MMC1_DAT3 */
> + /* external pull-down on SoM & Carrier */
> + AM64X_IOPAD(0x0298, PIN_INPUT_PULLUP, 0) /* MMC1_SDCD.MMC1_SDCD */
> + AM64X_IOPAD(0x0290, PIN_INPUT, 0) /* MMC1_CLKLB: clock loopback */
> + >;
> + };
> +
> + main_uart0_pins_default: main-uart0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0230, PIN_INPUT, 0) /* UART0_RXD.UART0_RXD */
> + AM64X_IOPAD(0x0234, PIN_OUTPUT, 0) /* UART0_TXD.UART0_TXD */
> + >;
> + };
> +
> + mdio0_pins_default: mdio0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x01fc, PIN_OUTPUT, 4) /* PRG0_PRU1_GPO19.MDIO0_MDC */
> + AM64X_IOPAD(0x01f8, PIN_INPUT, 4) /* PRG0_PRU1_GPO18.MDIO0_MDIO */
> + >;
> + };
> +
> + ospi0_pins_default: ospi0-pins-default {
> + pinctrl-single,pins = <
> + /* external pull-down on SoM */
> + AM64X_IOPAD(0x0000, PIN_OUTPUT, 0) /* OSPI0_CLK.OSPI0_CLK */
> + AM64X_IOPAD(0x0008, PIN_OUTPUT, 0) /* OSPI0_DQS.OSPI0_DQS */
> + /* external pull-up on SoM */
> + AM64X_IOPAD(0x002c, PIN_OUTPUT, 0) /* OSPI0_CSn0.OSPI0_CSn0 */
> + AM64X_IOPAD(0x000c, PIN_INPUT, 0) /* OSPI0_D0.OSPI0_D0 */
> + AM64X_IOPAD(0x0010, PIN_INPUT, 0) /* OSPI0_D1.OSPI0_D1 */
> + AM64X_IOPAD(0x0014, PIN_INPUT, 0) /* OSPI0_D2.OSPI0_D2 */
> + AM64X_IOPAD(0x0018, PIN_INPUT, 0) /* OSPI0_D3.OSPI0_D3 */
> + AM64X_IOPAD(0x001c, PIN_INPUT, 0) /* OSPI0_D4.OSPI0_D4 */
> + AM64X_IOPAD(0x0020, PIN_INPUT, 0) /* OSPI0_D5.OSPI0_D5 */
> + AM64X_IOPAD(0x0024, PIN_INPUT, 0) /* OSPI0_D6.OSPI0_D6 */
> + AM64X_IOPAD(0x0028, PIN_INPUT, 0) /* OSPI0_D7.OSPI0_D7 */
> + >;
> + };
> +
> + ospi0_flash0_pins_default: ospi0-flash0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0034, PIN_OUTPUT, 7) /* OSPI0_CSn2.GPIO0_13 */
> + AM64X_IOPAD(0x0038, PIN_INPUT, 7) /* OSPI0_CSn3.GPIO0_14 */
> + >;
> + };
> +
> + pru1_mdio0_pins_default: pru1-mdio0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x015c, PIN_OUTPUT, 0) /* PRG1_MDIO0_MDC.PRG1_MDIO0_MDC */
> + AM64X_IOPAD(0x0158, PIN_INPUT, 0) /* PRG1_MDIO0_MDIO.PRG1_MDIO0_MDIO */
> + >;
> + };
> +
> + pru_rgmii1_pins_default: pru-rgmii1-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x00b8, PIN_INPUT, 2) /* (Y7) PRG1_PRU0_GPO0.PRG1_RGMII1_RD0 */
> + AM64X_IOPAD(0x00bc, PIN_INPUT, 2) /* (U8) PRG1_PRU0_GPO1.PRG1_RGMII1_RD1 */
> + AM64X_IOPAD(0x00c0, PIN_INPUT, 2) /* (W8) PRG1_PRU0_GPO2.PRG1_RGMII1_RD2 */
> + AM64X_IOPAD(0x00c4, PIN_INPUT, 2) /* (V8) PRG1_PRU0_GPO3.PRG1_RGMII1_RD3 */
> + AM64X_IOPAD(0x00d0, PIN_INPUT, 2) /* (AA7) PRG1_PRU0_GPO6.PRG1_RGMII1_RXC */
> + AM64X_IOPAD(0x00c8, PIN_INPUT, 2) /* (Y8) PRG1_PRU0_GPO4.PRG1_RGMII1_RX_CTL */
> + AM64X_IOPAD(0x00e4, PIN_OUTPUT, 2) /* (AA8) PRG1_PRU0_GPO11.PRG1_RGMII1_TD0 */
> + AM64X_IOPAD(0x00e8, PIN_OUTPUT, 2) /* (U9) PRG1_PRU0_GPO12.PRG1_RGMII1_TD1 */
> + AM64X_IOPAD(0x00ec, PIN_OUTPUT, 2) /* (W9) PRG1_PRU0_GPO13.PRG1_RGMII1_TD2 */
> + AM64X_IOPAD(0x00f0, PIN_OUTPUT, 2) /* (AA9) PRG1_PRU0_GPO14.PRG1_RGMII1_TD3 */
> + AM64X_IOPAD(0x00f8, PIN_INPUT, 2) /* (V9) PRG1_PRU0_GPO16.PRG1_RGMII1_TXC */
> + AM64X_IOPAD(0x00f4, PIN_OUTPUT, 2) /* (Y9) PRG1_PRU0_GPO15.PRG1_RGMII1_TX_CTL */
> + >;
> + };
> +
> + pru_rgmii2_pins_default: pru-rgmii2-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0108, PIN_INPUT, 2) /* PRG1_PRU1_GPO0.RGMII2_RD0 */
> + AM64X_IOPAD(0x010c, PIN_INPUT, 2) /* PRG1_PRU1_GPO1.RGMII2_RD1 */
> + AM64X_IOPAD(0x0110, PIN_INPUT, 2) /* PRG1_PRU1_GPO2.RGMII2_RD2 */
> + AM64X_IOPAD(0x0114, PIN_INPUT, 2) /* PRG1_PRU1_GPO3.RGMII2_RD3 */
> + AM64X_IOPAD(0x0120, PIN_INPUT, 2) /* PRG1_PRU1_GPO6.RGMII2_RXC */
> + AM64X_IOPAD(0x0118, PIN_INPUT, 2) /* PRG1_PRU1_GPO4.RGMII2_RX_CTL */
> + AM64X_IOPAD(0x0134, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO11.RGMII2_TD0 */
> + AM64X_IOPAD(0x0138, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO12.RGMII2_TD1 */
> + AM64X_IOPAD(0x013c, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO13.RGMII2_TD2 */
> + AM64X_IOPAD(0x0140, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO14.RGMII2_TD3 */
> + AM64X_IOPAD(0x0148, PIN_INPUT, 2) /* PRG1_PRU1_GPO16.RGMII2_TXC */
> + AM64X_IOPAD(0x0144, PIN_OUTPUT, 2) /* PRG1_PRU1_GPO15.RGMII2_TX_CTL */
> + >;
> + };
> +
> + rgmii1_pins_default: rgmii1-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x01cc, PIN_INPUT, 4) /* PRG0_PRU1_GPO7.RGMII1_RD0 */
> + AM64X_IOPAD(0x01d4, PIN_INPUT, 4) /* PRG0_PRU1_GPO9.RGMII1_RD1 */
> + AM64X_IOPAD(0x01d8, PIN_INPUT, 4) /* PRG0_PRU1_GPO10.RGMII1_RD2 */
> + AM64X_IOPAD(0x01f4, PIN_INPUT, 4) /* PRG0_PRU1_GPO17.RGMII1_RD3 */
> + AM64X_IOPAD(0x0188, PIN_INPUT, 4) /* PRG0_PRU0_GPO10.RGMII1_RXC */
> + AM64X_IOPAD(0x0184, PIN_INPUT, 4) /* PRG0_PRU0_GPO9.RGMII1_RX_CTL */
> + AM64X_IOPAD(0x0124, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO7.RGMII1_TD0 */
> + AM64X_IOPAD(0x012c, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO9.RGMII1_TD1 */
> + AM64X_IOPAD(0x0130, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO10.RGMII1_TD2 */
> + AM64X_IOPAD(0x014c, PIN_OUTPUT, 4) /* PRG1_PRU1_GPO17.RGMII1_TD3 */
> + AM64X_IOPAD(0x00e0, PIN_INPUT, 4) /* PRG1_PRU0_GPO10.RGMII1_TXC */
> + AM64X_IOPAD(0x00dc, PIN_OUTPUT, 4) /* PRG1_PRU0_GPO9.RGMII1_TX_CTL */
> + >;
> + };
> +
> + usb0_pins_default: usb0-pins-default {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* USB0_DRVVBUS.USB0_DRVVBUS */
> + >;
> + };
> +};
> +
> +&main_r5fss0_core0 {
> + mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
> + memory-region = <&main_r5fss0_core0_dma_memory_region>,
> + <&main_r5fss0_core0_memory_region>;
> + status = "okay";
> +};
> +
> +&main_r5fss0_core1 {
> + mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core1>;
> + memory-region = <&main_r5fss0_core1_dma_memory_region>,
> + <&main_r5fss0_core1_memory_region>;
> + status = "okay";
> +};
> +
> +&main_r5fss1_core0 {
> + mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core0>;
> + memory-region = <&main_r5fss1_core0_dma_memory_region>,
> + <&main_r5fss1_core0_memory_region>;
> + status = "okay";
> +};
> +
> +&main_r5fss1_core1 {
> + mboxes = <&mailbox0_cluster4 &mbox_main_r5fss1_core1>;
> + memory-region = <&main_r5fss1_core1_dma_memory_region>,
> + <&main_r5fss1_core1_memory_region>;
> + status = "okay";
> +};
> +
> +/* SoC default UART console */
> +&main_uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_uart0_pins_default>;
> + status = "okay";
> +};
> +
> +&ospi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ospi0_pins_default>;
> + num-cs = <1>;
> + status = "okay";
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&ospi0_flash0_pins_default>;
> + spi-tx-bus-width = <8>;
> + spi-rx-bus-width = <8>;
> + spi-max-frequency = <200000000>;
> + cdns,tshsl-ns = <50>;
> + cdns,tsd2d-ns = <50>;
> + cdns,tchsh-ns = <4>;
> + cdns,tslch-ns = <4>;
> + cdns,read-delay = <0>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <14 IRQ_TYPE_LEVEL_LOW>;
> + reset-gpios = <&main_gpio0 13 GPIO_ACTIVE_LOW>;
> + status = "okay";
> + };
> +};
> +
> +&sdhci0 {
> + /* mmc0 pins have no padconfig */
> + bus-width = <8>;
> + ti,driver-strength-ohm = <50>;
> + disable-wp;
> + non-removable;
> + cap-mmc-hw-reset;
> + no-sd;
> + /*
> + * MMC controller supports switching between 1.8V and 3.3V signalling.
> + * However MMC0 (unlike MMC1) does not integrate an LDO.
> + * Explicitly link a regulator node for indicating to the driver which
> + * voltages are actually usable.
> + */
> + vqmmc-supply = <&vdd_mmc0>;
> + status = "okay";
> +};
> +
> +/*
> + * microSD is on carrier - however since SoC can boot from it,
> + * configure it just in case.
> + */
> +&sdhci1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mmc1_pins_default>;
> + bus-width = <4>;
> + ti,driver-strength-ohm = <50>;
> + disable-wp;
> + status = "okay";
> +};
> +
> +&tscadc0 {
> + status = "disabled";
> +};
> +
> +/*
> + * USB settings are a carrier choice - however since SoC can boot from it,
> + * configure as USB-2.0 OTG here, keeping USB-3 serdes disabled.
> + */
> +&usb0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb0_pins_default>;
> + dr_mode = "otg";
> + maximum-speed = "high-speed";
> + status = "okay";
> +};
> +
> +&usbss0 {
> + ti,vbus-divider;
> + ti,usb2-only;
> + status = "okay";
> +};
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3
2024-01-12 17:12 ` [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer
@ 2024-01-12 17:58 ` Andrew Davis
2024-01-14 15:25 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Andrew Davis @ 2024-01-12 17:58 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel, devicetree, linux-kernel,
linux-rtc
On 1/12/24 11:12 AM, Josua Mayer wrote:
> HummingBoard-T features two M.2 connectors labeled "M1" and "M2".
> The single SerDes lane of the SoC can be routed to either M1 pci-e
> signals, or M2 usb-3 signals by a gpio-controlled mux.
>
> Add dedicated dts for each configuration.
> - k3-am642-hummingboard-t.dts enables neither configuration
> - k3-am642-hummingboard-t-pcie.dts (new)
> configures serdes mux and pci-e controller for M1
> - k3-am642-hummingboard-t-usb3.dts (new)
> configures serdes mux and usb-3 controller for M2
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> arch/arm64/boot/dts/ti/Makefile | 2 ++
> .../boot/dts/ti/k3-am642-hummingboard-t-pcie.dts | 31 ++++++++++++++++++
> .../boot/dts/ti/k3-am642-hummingboard-t-usb3.dts | 37 ++++++++++++++++++++++
> 3 files changed, 70 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 041c3b71155e..0e408555edf1 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -33,6 +33,8 @@ dtb-$(CONFIG_ARCH_K3) += k3-am62p5-sk.dtb
> # Boards with AM64x SoC
> dtb-$(CONFIG_ARCH_K3) += k3-am642-evm.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t-pcie.dtb
> +dtb-$(CONFIG_ARCH_K3) += k3-am642-hummingboard-t-usb3.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-phyboard-electra-rdk.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-sk.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am642-tqma64xxl-mbax4xxl.dtb
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
> new file mode 100644
> index 000000000000..5ba0029fcfb9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
> @@ -0,0 +1,31 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
> + *
> + * DTS for SolidRun AM642 HummingBoard-T,
> + * running on Cortex A53, with PCI-E.
> + *
> + */
> +
> +#include "k3-am642-hummingboard-t.dts"
Avoid including .dts files, if this file is for an option that
can be chosen (PCIe vs USB3), then it should be a DT overlay.
> +#include "k3-serdes.h"
> +
> +/ {
> + model = "SolidRun AM642 HummingBoard-T with PCI-E";
> +};
> +
> +&pcie0_rc {
> + status = "okay";
If PCIe is only available here when using this add-on then
all of the node data should be in this add-on file.
Andrew
> +};
> +
> +&serdes0_link {
> + cdns,phy-type = <PHY_TYPE_PCIE>;
> +};
> +
> +&serdes_ln_ctrl {
> + idle-states = <AM64_SERDES0_LANE0_PCIE0>;
> +};
> +
> +&serdes_mux {
> + idle-state = <1>;
> +};
> diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts
> new file mode 100644
> index 000000000000..12b0fedcd2bc
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-usb3.dts
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
> + *
> + * DTS for SolidRun AM642 HummingBoard-T,
> + * running on Cortex A53, with USB-3.1 Gen 1.
> + *
> + */
> +
> +#include "k3-am642-hummingboard-t.dts"
> +#include "k3-serdes.h"
> +
> +/ {
> + model = "SolidRun AM642 HummingBoard-T with USB-3.1 Gen 1";
> +};
> +
> +&serdes0_link {
> + cdns,phy-type = <PHY_TYPE_USB3>;
> +};
> +
> +&serdes_ln_ctrl {
> + idle-states = <AM64_SERDES0_LANE0_USB>;
> +};
> +
> +&serdes_mux {
> + idle-state = <0>;
> +};
> +
> +&usbss0 {
> + /delete-property/ ti,usb2-only;
> +};
> +
> +&usb0 {
> + maximum-speed = "super-speed";
> + phys = <&serdes0_link>;
> + phy-names = "cdns3,usb3-phy";
> +};
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-12 17:22 ` Krzysztof Kozlowski
@ 2024-01-14 14:16 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-14 14:16 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>> + /* PRU Ethernet Controller */
>> + icssg1_eth: icssg1-eth {
> Node names should be generic.
This name intentionally includes the name of the ip block within am64 soc providing software-defined ethernet controller through coprocessors TI call "pru".
> See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>
>
>> + compatible = "ti,am642-icssg-prueth";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>> +
>> + sram = <&oc_sram>;
>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>> +
>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>> + <2>,
>> + <2>,
>> + <2>, /* MII mode */
>> + <2>,
>> + <2>;
>> +
>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>> + ti,mii-rt = <&icssg1_mii_rt>;
>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>> +
>> + interrupt-parent = <&icssg1_intc>;
>> + interrupts = <24 0 2>, <25 1 3>;
> None of these are typical interrupt constants/flags?
>
>> + interrupt-names = "tx_ts0", "tx_ts1";
>> +
>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>> + "rx0", "rx1";
>> +
>> + status = "okay";
> Drop. Didn't you get such comments before?
Yes, but again I can point to an in-tree example of the same structure.
I see no reason for describing the same thing differently in different places.
Please see arch/arm64/boot/dts/ti/k3-am654-idk.dtso
There are only small differences for this feature between am65 and am64.
It's inclusion in the tree was very recent, clearly it was good enough right?
See also my cover letter dtbs_check remark on dmas property.
>
>> +
>> + ethernet-ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + icssg1_emac0: port@0 {
>> + reg = <0>;
>> + ti,syscon-rgmii-delay = <&main_conf 0x4110>;
>> + /* Filled in by bootloader */
>> + local-mac-address = [00 00 00 00 00 00];
>> + phy-handle = <ðernet_phy2>;
>> + phy-mode = "rgmii-id";
>> + status = "okay";
> ?
>
>> + };
>> +
>> + icssg1_emac1: port@1 {
>> + reg = <1>;
>> + ti,syscon-rgmii-delay = <&main_conf 0x4114>;
>> + /* Filled in by bootloader */
>> + local-mac-address = [00 00 00 00 00 00];
>> + phy-handle = <ðernet_phy1>;
>> + phy-mode = "rgmii-id";
>> + status = "okay";
> ?
good point, removed all the status from icssg1-eth node.
>
>
> ....
>
>> + ethernet_phy0: ethernet-phy@0 {
>> + compatible = "ethernet-phy-id2000.a0f1";
>> + reg = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <ðernet_phy0_pins_default>;
>> + ti,clk-output-sel = <DP83869_CLK_O_SEL_REF_CLK>;
>> + ti,op-mode = <DP83869_RGMII_COPPER_ETHERNET>;
>> + /*
>> + * Disable interrupts because ISR never clears 0x0040
>> + *
>> + * interrupt-parent = <&main_gpio1>;
>> + * interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
>> + */
>> + /*
>> + * Disable HW Reset because clock signal is daisy-chained
>> + *
>> + * reset-gpios = <&main_gpio0 84 GPIO_ACTIVE_LOW>;
>> + * reset-assert-us = <1>;
>> + * reset-deassert-us = <30>;
>> + */
>> + status = "okay";
> Drop, this applies everywhere where not needed. You have this in
> multiple places...
Is this about status, or commented interrupt and reset definitions?
Thank you for the review!
Sincerely
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-12 17:50 ` Andrew Davis
@ 2024-01-14 15:14 ` Josua Mayer
0 siblings, 0 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-14 15:14 UTC (permalink / raw
To: Andrew Davis, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 12.01.24 um 18:50 schrieb Andrew Davis:
> On 1/12/24 11:12 AM, Josua Mayer wrote:
>> +
>> + /* charger@6a */
>
> ?
The particular chip bq25713 has no mainline support, no dt bindings, and I do not understand it well enough for defining reasonable bindings myself.
Since it is assembly option and not currently available I added just a marker.
Drop it instead?
>
>> +};
>> +
>> +&main_i2c1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>;
>
> The interrupt pin belongs to the rtc@69 and should be in the node below.
Ack.
I will rename the interrupt pinctrl node rtc_int_pins_default, accordingly.
>
>> +
>> +
>> +&pcie0_rc {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pcie0_pins_default>;
>> + reset-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
>> + phys = <&serdes0_link>;
>> + phy-names = "pcie-phy";
>> + num-lanes = <1>;
>> + mux-controls = <&serdes_mux>;
>> + mux-control-names = "serdes";
mux-controls was a downstream workaround to ensure setting the mux before pci probe (downstream patch on linux 5.10 pci driver).
I shall remove it until confirming whether it makes sense / is required upstream.
>> + status = "disabled";
>
> This node is already default disabled in the parent .dtsi and
> has been for more than a year now, you might need to go recheck
> if these disables are needed. I see several below that also
> are not needed.
Ack.
Turns out very many nodes are without status in k3-am64-main.dtsi.
I went through all of them in som and carrier dts, left with explicit status are:
- cpsw3g_mdio
- cpsw_port2
- icssg1_mdio
- mailbox0_cluster2
- mailbox0_cluster4
- main_i2c0
- main_i2c1
- main_mcan0
- main_mcan1
- main_uart0
- main_uart3
- ospi0
>
>> +};
>> +
>> +&pcie0_ep {
>> + phys = <&serdes0_link>;
>> + phy-names = "pcie-phy";
>> + num-lanes = <1>;
>> + status = "disabled";
>> +};
>
> Delete this node, added it back if/when you plan to use it
> and only in the dt file that adds the rest of the needed
> properties.
Ack.
>> +
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + secure_ddr: optee@9e800000 {
>> + reg = <0x00 0x9e800000 0x00 0x01800000>; /* for OP-TEE */
>> + alignment = <0x1000>;
>
> Alignment not needed for no-map nodes.
Ack.
Thanks! sincerely,
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3
2024-01-12 17:58 ` Andrew Davis
@ 2024-01-14 15:25 ` Josua Mayer
0 siblings, 0 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-14 15:25 UTC (permalink / raw
To: Andrew Davis, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 12.01.24 um 18:58 schrieb Andrew Davis:
> On 1/12/24 11:12 AM, Josua Mayer wrote:
>> diff --git a/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
>> new file mode 100644
>> index 000000000000..5ba0029fcfb9
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dts
>> @@ -0,0 +1,31 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2023 Josua Mayer <josua@solid-run.com>
>> + *
>> + * DTS for SolidRun AM642 HummingBoard-T,
>> + * running on Cortex A53, with PCI-E.
>> + *
>> + */
>> +
>> +#include "k3-am642-hummingboard-t.dts"
>
> Avoid including .dts files, if this file is for an option that
> can be chosen (PCIe vs USB3), then it should be a DT overlay.
>
>> +#include "k3-serdes.h"
>> +
>> +/ {
>> + model = "SolidRun AM642 HummingBoard-T with PCI-E";
>> +};
>> +
>> +&pcie0_rc {
>> + status = "okay";
>
> If PCIe is only available here when using this add-on then
> all of the node data should be in this add-on file.
That is correct, add-on file seems appropriate.
It is the same hardware, merely a different choice for signal routing.
Thanks! - sincerely
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-12 17:18 ` Krzysztof Kozlowski
@ 2024-01-14 15:56 ` Josua Mayer
2024-01-14 16:26 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-14 15:56 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 12.01.24 um 18:18 schrieb Krzysztof Kozlowski:
> On 12/01/2024 18:12, Josua Mayer wrote:
>> +++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
>> @@ -0,0 +1,56 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
>> +
>> +maintainers: []
> You need a name here. If there is no driver maintainer or anyone
> interested, put devicetree list.
Ack.
>> +
>> +allOf:
>> + - $ref: rtc.yaml#
>> +
>> +properties:
>> + compatible:
>> + anyOf:
> Please do not invent your own solutions, but use existing code as
> template. Just open example-schema or any other recent RTC binding.
This was inspired by jsonschema / stackoverflow.
Will change it as requested.
>> + - description: auto-detection from id register
>> + const: abracon,abx80x
>> + - const: abracon,,ab0801
>> + - const: abracon,,ab0803
>> + - const: abracon,,ab0804
>> + - const: abracon,,ab0805
>> + - const: abracon,,ab1801
>> + - const: abracon,,ab1803
>> + - const: abracon,,ab1804
>> + - const: abracon,,ab1805
>> + - const: microcrystal,rv1805
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + abracon,tc-diode:
> Missing type - string.
$ref: /schemas/types.yaml#/definitions/string ?
If so - ack.
>> + description:
>> + Trickle-charge diode type.
>> + Required to enable charging backup battery.
>> + anyOf:
> Use enum and explain the meanings of the values in descruption.
>
>> + - description: standard diode with 0.6V drop
>> + const: standard
>> + - description: schottky diode with 0.3V drop
>> + const: schottky
Here was the real motivation for different solution.
Will change it as requested.
>> +
>> + abracon,tc-resistor:
>> + description:
>> + Trickle-charge resistor value in kOhm.
>> + Required to enable charging backup battery.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + enum: [0, 3, 6, 11]
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +unevaluatedProperties: false
> Provide example.
Okay.
Thanks. sincerely,
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-14 15:56 ` Josua Mayer
@ 2024-01-14 16:26 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-14 16:26 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 14.01.24 um 16:56 schrieb Josua Mayer:
> Am 12.01.24 um 18:18 schrieb Krzysztof Kozlowski:
>> On 12/01/2024 18:12, Josua Mayer wrote:
>>> +++ b/Documentation/devicetree/bindings/rtc/abracon,abx80x.yaml
>>> @@ -0,0 +1,56 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/rtc/abracon,abx80x.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Abracon ABX80X I2C ultra low power RTC/Alarm chip
>>> +
>>> +maintainers: []
>> You need a name here. If there is no driver maintainer or anyone
>> interested, put devicetree list.
> Ack.
>>> +
>>> +allOf:
>>> + - $ref: rtc.yaml#
+ $ref: /schemas/interrupts.yaml#
Is it acceptable to reference generic interrupts schema?:
I see no rtc yaml doing that, and only some describe interrupts property explicitly. But Importing the schema would also cover -parent and -names.
>>> +
>>> + interrupts:
>>> + maxItems: 1
sincerely
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-14 14:16 ` Josua Mayer
@ 2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:05 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-15 7:29 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
On 14/01/2024 15:16, Josua Mayer wrote:
> Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>
>>> + /* PRU Ethernet Controller */
>>> + icssg1_eth: icssg1-eth {
>> Node names should be generic.
> This name intentionally includes the name of the ip block within am64 soc providing software-defined ethernet controller through coprocessors TI call "pru".
Why? This intentionally should not include specific name.
Also, wrap your emails at proper length so they will be manageable...
>> See also an explanation and list of
>> examples (not exhaustive) in DT specification:
>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>
>>
>>> + compatible = "ti,am642-icssg-prueth";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>>> +
>>> + sram = <&oc_sram>;
>>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>> +
>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>> + <2>,
>>> + <2>,
>>> + <2>, /* MII mode */
>>> + <2>,
>>> + <2>;
>>> +
>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>> +
>>> + interrupt-parent = <&icssg1_intc>;
>>> + interrupts = <24 0 2>, <25 1 3>;
>> None of these are typical interrupt constants/flags?
>>
>>> + interrupt-names = "tx_ts0", "tx_ts1";
>>> +
>>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
>>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>>> + "rx0", "rx1";
>>> +
>>> + status = "okay";
>> Drop. Didn't you get such comments before?
>
> Yes, but again I can point to an in-tree example of the same structure.
> I see no reason for describing the same thing differently in different places.
So if there is a bug, you are going to duplicate it.
Please provide real argument why this is needed, not "I saw it
somewhere", or drop it. Otherwise it's a NAK from me.
>
> Please see arch/arm64/boot/dts/ti/k3-am654-idk.dtso
> There are only small differences for this feature between am65 and am64.
> It's inclusion in the tree was very recent, clearly it was good enough right?
> See also my cover letter dtbs_check remark on dmas property.
How does dmas matter? What are you talking about?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-14 16:26 ` Josua Mayer
@ 2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:17 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-15 7:29 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
On 14/01/2024 17:26, Josua Mayer wrote:
>>>> +maintainers: []
>>> You need a name here. If there is no driver maintainer or anyone
>>> interested, put devicetree list.
>> Ack.
>>>> +
>>>> +allOf:
>>>> + - $ref: rtc.yaml#
>
> + $ref: /schemas/interrupts.yaml#
>
> Is it acceptable to reference generic interrupts schema?:
Why? No.
>
> I see no rtc yaml doing that, and only some describe interrupts property explicitly. But Importing the schema would also cover -parent and -names.
No, it wouldn't. It does not matter. I don't understand what are you
trying to solve.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-15 7:29 ` Krzysztof Kozlowski
@ 2024-01-15 10:05 ` Josua Mayer
2024-01-15 10:21 ` Krzysztof Kozlowski
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-15 10:05 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
> On 14/01/2024 15:16, Josua Mayer wrote:
>> Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>>
>>>> + /* PRU Ethernet Controller */
>>>> + icssg1_eth: icssg1-eth {
>>> Node names should be generic.
>> This name intentionally includes the name of the ip block within am64 soc
>> providing software-defined ethernet controller through coprocessors TI call "pru".
> Why? This intentionally should not include specific name.
I understand. Which is why I imagined in the other reference had intentionally
diverged from that rule.
>
> Also, wrap your emails at proper length so they will be manageable...
>
>>> See also an explanation and list of
>>> examples (not exhaustive) in DT specification:
>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>>
>>>
>>>> + compatible = "ti,am642-icssg-prueth";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>>>> +
>>>> + sram = <&oc_sram>;
>>>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>>> +
>>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>>> + <2>,
>>>> + <2>,
>>>> + <2>, /* MII mode */
>>>> + <2>,
>>>> + <2>;
>>>> +
>>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>>> +
>>>> + interrupt-parent = <&icssg1_intc>;
>>>> + interrupts = <24 0 2>, <25 1 3>;
>>> None of these are typical interrupt constants/flags?
>>>
>>>> + interrupt-names = "tx_ts0", "tx_ts1";
>>>> +
>>>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>>>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>>>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>>>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>>>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>>>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>>>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>>>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>>>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>>>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>>>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>>>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
>>>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>>>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>>>> + "rx0", "rx1";
>>>> +
>>>> + status = "okay";
>>> Drop. Didn't you get such comments before?
>> Yes, but again I can point to an in-tree example of the same structure.
>> I see no reason for describing the same thing differently in different places.
> So if there is a bug, you are going to duplicate it.
I was torn between making my own solution, and using recently
added and topical (to my submission) code as template.
>
> Please provide real argument why this is needed, not "I saw it
> somewhere", or drop it. Otherwise it's a NAK from me.
I will attempt to improve the magic numbers in this whole node,
and reconsider the node name. Thanks.
>
>> Please see arch/arm64/boot/dts/ti/k3-am654-idk.dtso
>> There are only small differences for this feature between am65 and am64.
>> It's inclusion in the tree was very recent, clearly it was good enough right?
>> See also my cover letter dtbs_check remark on dmas property.
> How does dmas matter? What are you talking about?
I am trying to establish whether I can use that as example or not.
Clearly it is a bad example, and I should try describing it better.
>
>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-15 7:29 ` Krzysztof Kozlowski
@ 2024-01-15 10:17 ` Josua Mayer
2024-01-15 10:20 ` Krzysztof Kozlowski
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-15 10:17 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
> On 14/01/2024 17:26, Josua Mayer wrote:
>>>>> +maintainers: []
>>>> You need a name here. If there is no driver maintainer or anyone
>>>> interested, put devicetree list.
>>> Ack.
>>>>> +
>>>>> +allOf:
>>>>> + - $ref: rtc.yaml#
>> + $ref: /schemas/interrupts.yaml#
>>
>> Is it acceptable to reference generic interrupts schema?:
> Why? No.
>
>> I see no rtc yaml doing that, and only some describe interrupts property explicitly. But Importing the schema would also cover -parent and -names.
> No, it wouldn't. It does not matter. I don't understand what are you
> trying to solve.
dtbs_check is complaining about interrupt-parent property,
because I added both interrrupts and interrupt-parent to my rtc node.
Also wondering whether interrupts property should be included in
the example.
I found this idea in yaml files outside rtc.
But no existing rtc yaml references that schema, so I asked.
sincerely
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml
2024-01-15 10:17 ` Josua Mayer
@ 2024-01-15 10:20 ` Krzysztof Kozlowski
0 siblings, 0 replies; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-15 10:20 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
On 15/01/2024 11:17, Josua Mayer wrote:
> Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
>
>> On 14/01/2024 17:26, Josua Mayer wrote:
>>>>>> +maintainers: []
>>>>> You need a name here. If there is no driver maintainer or anyone
>>>>> interested, put devicetree list.
>>>> Ack.
>>>>>> +
>>>>>> +allOf:
>>>>>> + - $ref: rtc.yaml#
>>> + $ref: /schemas/interrupts.yaml#
>>>
>>> Is it acceptable to reference generic interrupts schema?:
>> Why? No.
>>
>>> I see no rtc yaml doing that, and only some describe interrupts property explicitly. But Importing the schema would also cover -parent and -names.
>> No, it wouldn't. It does not matter. I don't understand what are you
>> trying to solve.
> dtbs_check is complaining about interrupt-parent property,
> because I added both interrrupts and interrupt-parent to my rtc node.
Difficult to say. You did not include example in your schema which
prevents parts of tests.
>
> Also wondering whether interrupts property should be included in
> the example.
Yes, your example should be complete... but there is no example in the
first place :/
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-15 10:05 ` Josua Mayer
@ 2024-01-15 10:21 ` Krzysztof Kozlowski
2024-01-15 10:32 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Krzysztof Kozlowski @ 2024-01-15 10:21 UTC (permalink / raw
To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Alessandro Zummo,
Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
On 15/01/2024 11:05, Josua Mayer wrote:
> Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
>
>> On 14/01/2024 15:16, Josua Mayer wrote:
>>> Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>>>
>>>>> + /* PRU Ethernet Controller */
>>>>> + icssg1_eth: icssg1-eth {
>>>> Node names should be generic.
>>> This name intentionally includes the name of the ip block within am64 soc
>>> providing software-defined ethernet controller through coprocessors TI call "pru".
>> Why? This intentionally should not include specific name.
> I understand. Which is why I imagined in the other reference had intentionally
> diverged from that rule.
>>
>> Also, wrap your emails at proper length so they will be manageable...
>>
>>>> See also an explanation and list of
>>>> examples (not exhaustive) in DT specification:
>>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>>>
>>>>
>>>>> + compatible = "ti,am642-icssg-prueth";
>>>>> + pinctrl-names = "default";
>>>>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>>>>> +
>>>>> + sram = <&oc_sram>;
>>>>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>>>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>>>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>>>> +
>>>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>>>> + <2>,
>>>>> + <2>,
>>>>> + <2>, /* MII mode */
>>>>> + <2>,
>>>>> + <2>;
>>>>> +
>>>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>>>> +
>>>>> + interrupt-parent = <&icssg1_intc>;
>>>>> + interrupts = <24 0 2>, <25 1 3>;
>>>> None of these are typical interrupt constants/flags?
>>>>
>>>>> + interrupt-names = "tx_ts0", "tx_ts1";
>>>>> +
>>>>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>>>>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>>>>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>>>>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>>>>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>>>>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
>>>>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>>>>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>>>>> + "rx0", "rx1";
>>>>> +
>>>>> + status = "okay";
>>>> Drop. Didn't you get such comments before?
>>> Yes, but again I can point to an in-tree example of the same structure.
>>> I see no reason for describing the same thing differently in different places.
>> So if there is a bug, you are going to duplicate it.
> I was torn between making my own solution, and using recently
> added and topical (to my submission) code as template.
>>
>> Please provide real argument why this is needed, not "I saw it
>> somewhere", or drop it. Otherwise it's a NAK from me.
> I will attempt to improve the magic numbers in this whole node,
> and reconsider the node name. Thanks.
What magic numbers? My comment was under one specific line. There are no
numbers in status.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-15 10:21 ` Krzysztof Kozlowski
@ 2024-01-15 10:32 ` Josua Mayer
2024-01-16 13:29 ` Josua Mayer
0 siblings, 1 reply; 23+ messages in thread
From: Josua Mayer @ 2024-01-15 10:32 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 15.01.24 um 11:21 schrieb Krzysztof Kozlowski:
> On 15/01/2024 11:05, Josua Mayer wrote:
>> Am 15.01.24 um 08:29 schrieb Krzysztof Kozlowski:
>>
>>> On 14/01/2024 15:16, Josua Mayer wrote:
>>>> Am 12.01.24 um 18:22 schrieb Krzysztof Kozlowski:
>>>>
>>>>>> + /* PRU Ethernet Controller */
>>>>>> + icssg1_eth: icssg1-eth {
>>>>> Node names should be generic.
>>>> This name intentionally includes the name of the ip block within am64 soc
>>>> providing software-defined ethernet controller through coprocessors TI call "pru".
>>> Why? This intentionally should not include specific name.
>> I understand. Which is why I imagined in the other reference had intentionally
>> diverged from that rule.
>>> Also, wrap your emails at proper length so they will be manageable...
>>>
>>>>> See also an explanation and list of
>>>>> examples (not exhaustive) in DT specification:
>>>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>>>>
>>>>>
>>>>>> + compatible = "ti,am642-icssg-prueth";
>>>>>> + pinctrl-names = "default";
>>>>>> + pinctrl-0 = <&pru_rgmii1_pins_default>, <&pru_rgmii2_pins_default>;
>>>>>> +
>>>>>> + sram = <&oc_sram>;
>>>>>> + ti,prus = <&pru1_0>, <&rtu1_0>, <&tx_pru1_0>, <&pru1_1>, <&rtu1_1>, <&tx_pru1_1>;
>>>>>> + firmware-name = "ti-pruss/am65x-sr2-pru0-prueth-fw.elf",
>>>>>> + "ti-pruss/am65x-sr2-rtu0-prueth-fw.elf",
>>>>>> + "ti-pruss/am65x-sr2-txpru0-prueth-fw.elf",
>>>>>> + "ti-pruss/am65x-sr2-pru1-prueth-fw.elf",
>>>>>> + "ti-pruss/am65x-sr2-rtu1-prueth-fw.elf",
>>>>>> + "ti-pruss/am65x-sr2-txpru1-prueth-fw.elf";
>>>>>> +
>>>>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>>>>> + <2>,
>>>>>> + <2>,
>>>>>> + <2>, /* MII mode */
>>>>>> + <2>,
>>>>>> + <2>;
>>>>>> +
>>>>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>>>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>>>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>>>>> +
>>>>>> + interrupt-parent = <&icssg1_intc>;
>>>>>> + interrupts = <24 0 2>, <25 1 3>;
>>>>> None of these are typical interrupt constants/flags?
These are the magic numbers
>>>>>
>>>>>> + interrupt-names = "tx_ts0", "tx_ts1";
>>>>>> +
>>>>>> + dmas = <&main_pktdma 0xc200 15>, /* egress slice 0 */
>>>>>> + <&main_pktdma 0xc201 15>, /* egress slice 0 */
>>>>>> + <&main_pktdma 0xc202 15>, /* egress slice 0 */
>>>>>> + <&main_pktdma 0xc203 15>, /* egress slice 0 */
>>>>>> + <&main_pktdma 0xc204 15>, /* egress slice 1 */
>>>>>> + <&main_pktdma 0xc205 15>, /* egress slice 1 */
>>>>>> + <&main_pktdma 0xc206 15>, /* egress slice 1 */
>>>>>> + <&main_pktdma 0xc207 15>, /* egress slice 1 */
>>>>>> + <&main_pktdma 0x4200 15>, /* ingress slice 0 */
>>>>>> + <&main_pktdma 0x4201 15>, /* ingress slice 1 */
>>>>>> + <&main_pktdma 0x4202 0>, /* mgmnt rsp slice 0 */
>>>>>> + <&main_pktdma 0x4203 0>; /* mgmnt rsp slice 1 */
These are maybe magic numbers
>>>>>> + dma-names = "tx0-0", "tx0-1", "tx0-2", "tx0-3",
>>>>>> + "tx1-0", "tx1-1", "tx1-2", "tx1-3",
>>>>>> + "rx0", "rx1";
two names missing here
>>>>>> +
>>>>>> + status = "okay";
>>>>> Drop. Didn't you get such comments before?
>>>> Yes, but again I can point to an in-tree example of the same structure.
>>>> I see no reason for describing the same thing differently in different places.
>>> So if there is a bug, you are going to duplicate it.
>> I was torn between making my own solution, and using recently
>> added and topical (to my submission) code as template.
>>> Please provide real argument why this is needed, not "I saw it
>>> somewhere", or drop it. Otherwise it's a NAK from me.
>> I will attempt to improve the magic numbers in this whole node,
>> and reconsider the node name. Thanks.
> What magic numbers? My comment was under one specific line. There are no
> numbers in status.
Sorry it wasn't clear, status: acked, my mistake, I made it too many times
maybe I will learn eventually ... hopefully :(
interrupt numbers, dma-names, node name: I will rework.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board
2024-01-15 10:32 ` Josua Mayer
@ 2024-01-16 13:29 ` Josua Mayer
0 siblings, 0 replies; 23+ messages in thread
From: Josua Mayer @ 2024-01-16 13:29 UTC (permalink / raw
To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alessandro Zummo, Alexandre Belloni
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rtc@vger.kernel.org
Am 15.01.24 um 11:32 schrieb Josua Mayer:
> Am 15.01.24 um 11:21 schrieb Krzysztof Kozlowski:
>> On 15/01/2024 11:05, Josua Mayer wrote:
>>> +
>>> + ti,pruss-gp-mux-sel = <2>, /* MII mode */
>>> + <2>,
>>> + <2>,
>>> + <2>, /* MII mode */
>>> + <2>,
>>> + <2>;
This property is described in remoteproc/ti,pru-consumer.yaml
without explanation what each numeric value means.|
SoC TRM provides these names: "GP", "EnDAT", "MII", "SD".
Is it okay to keep number here, or are named constants needed?
Additionally, this array better to do in single line?:
/* configurei nternal mux for mii mode */
ti,pruss-gp-mux-sel = <2>, <2>, <2>, <2>, <2>, <2>;
>>> +
>>> + ti,mii-g-rt = <&icssg1_mii_g_rt>;
>>> + ti,mii-rt = <&icssg1_mii_rt>;
>>> + ti,iep = <&icssg1_iep0>, <&icssg1_iep1>;
>>> +
>>> + interrupt-parent = <&icssg1_intc>;
>>> + interrupts = <24 0 2>, <25 1 3>;
>>>>>> None of these are typical interrupt constants/flags?
"pruss-intc" interrupt controller driver has a special xlate function,
taking 3 integer arguments: event, channel, host.
I came up with the below description:
/*
* icssg subsystem interrupt controller can be programmed
* for routing any of 64 predefined subsytem-internal events
* (documented in TRM) to one of 20 host interrupts.
* Some host interrupts are device-wide, others special
* purpose.
* Mapping is done via one of 20 channels - channel number
* decides processing priority (0 = highest).
*
*
* Map pru-internal interrupt #8 (24) via channel 0 to
* host-side pru interrupt #0 (2) (gic 246 / "host_intr0");
* and pru-internal interrupt #9 via channel 0 to
* host-side pru interrupt #1 (3) (gic 247 / "host_intr1").
*/
I feel it is a bit long to put in dts, perhaps I can put just second paragraph?
However this paragraph is still a bit confusing -
I should make it more readable, especially how 24 translates to 8 and 2 to 0, etc..
First paragraph is not needed, because bindings doc for this
interrupt controller has a good description for #interrupt-cells:
interrupt-controller/ti,pruss-intc.yaml
The 64 events, and 20 hosts have names in the TRM. Some of them
are particular, others are generic, e.g. INTR_REQ[0:15].
Creating a header with named constants seems doable.
Is it worth doing this?
Sincerely
Josua Mayer
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2024-01-16 13:29 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-12 17:12 [PATCH v2 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer
2024-01-12 17:12 ` [PATCH v2 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
2024-01-12 17:12 ` [PATCH v2 2/5] dt-bindings: rtc: abx80x: convert to yaml Josua Mayer
2024-01-12 17:18 ` Krzysztof Kozlowski
2024-01-14 15:56 ` Josua Mayer
2024-01-14 16:26 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:17 ` Josua Mayer
2024-01-15 10:20 ` Krzysztof Kozlowski
2024-01-12 17:12 ` [PATCH v2 3/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer
2024-01-12 17:12 ` [PATCH v2 4/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer
2024-01-12 17:22 ` Krzysztof Kozlowski
2024-01-14 14:16 ` Josua Mayer
2024-01-15 7:29 ` Krzysztof Kozlowski
2024-01-15 10:05 ` Josua Mayer
2024-01-15 10:21 ` Krzysztof Kozlowski
2024-01-15 10:32 ` Josua Mayer
2024-01-16 13:29 ` Josua Mayer
2024-01-12 17:50 ` Andrew Davis
2024-01-14 15:14 ` Josua Mayer
2024-01-12 17:12 ` [PATCH v2 5/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer
2024-01-12 17:58 ` Andrew Davis
2024-01-14 15:25 ` Josua Mayer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).