* [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb
@ 2024-01-03 11:27 Josua Mayer
2024-01-03 11:27 ` [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer
` (4 more replies)
0 siblings, 5 replies; 13+ messages in thread
From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Josua Mayer,
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 them up as rfc in
the commit description of patch #2.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Josua Mayer (4):
dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T
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
arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports
Suman Anna (1):
arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +
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 | 333 +++++++++++
arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 639 +++++++++++++++++++++
7 files changed, 1074 insertions(+)
---
base-commit: b85ea95d086471afb4ad062012a4d73cd328fa86
change-id: 20240101-add-am64-som-51a1ca47edf3
Sincerely,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer @ 2024-01-03 11:27 ` Josua Mayer 2024-01-04 7:50 ` Krzysztof Kozlowski 2024-01-03 11:27 ` [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer ` (3 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel, Josua Mayer 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> --- 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] 13+ messages in thread
* Re: [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T 2024-01-03 11:27 ` [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer @ 2024-01-04 7:50 ` Krzysztof Kozlowski 0 siblings, 0 replies; 13+ messages in thread From: Krzysztof Kozlowski @ 2024-01-04 7:50 UTC (permalink / raw) To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel On 03/01/2024 12:27, Josua Mayer wrote: > 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> Best regards, Krzysztof ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer 2024-01-03 11:27 ` [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer @ 2024-01-03 11:27 ` Josua Mayer 2024-01-04 7:54 ` Krzysztof Kozlowski 2024-01-03 11:27 ` [PATCH 3/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer ` (2 subsequent siblings) 4 siblings, 1 reply; 13+ messages in thread From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel, 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. RFC: dtbs_check reports: - error in pru ethernet: arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: dmas: [[12, 49664, 15], [12, 49665, 15], [12, 49666, 15], [12, 49667, 15], [12, 49668, 15], [12, 49669, 15], [12, 49670, 15], [12, 49671, 15], [12, 16896, 15], [12, 16897, 15], [12, 16898, 0], [12, 16899, 0]] is too long from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: Unevaluated properties are not allowed ('dmas' was unexpected) from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# 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. At least for this revision I am skipping fixing the bindings, because aside from raising the maximum to 12, dma-names also has just 10 entries - and don't know which names would be correct to add. - undocumented compatible ti,bq25713 (battery charger) arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20000000/battery-charger@6a: failed to match any schema with compatible: ['ti,bq25713'] This specific charger has no linux support yet, I am not sure where (or whether) to document the new compatible. The reference could also be dropped completely, since the charger is not assebled by default. - undocumented compatible for rtc: "abracon,abx80x" arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20010000/am1805aq@69: failed to match any schema with compatible: ['abracon,abx80x'] It is actually documented in text format: Documentation/devicetree/bindings/rtc/abracon,abx80x.txt - phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: serdes@f000000: phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 from schema $id: http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml# I used value 0 here on purpose (phy.h: #define PHY_NONE 0), however maybe better to choose a specific protocol? Or better to update binding and allow 0? - interrupt properties not allowed for spi flash arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: flash@0: Unevaluated properties are not allowed ('interrupt-parent', 'interrupts' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/jedec,spi-nor.yaml# The assembled flash memory "sh28hs512t" definitely has an interrupt pin wired to a cpu gpio. Should interrupts be added to spi flash binding? - wrong names for pinctrl nodes arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: pinctrl@f4000: 'ethernet-phy-pins-default', 'ethernet-phy0-pins-default', 'ethernet-phy1-pins-default', 'ethernet-phy2-pins-default', 'leds-pins-default', 'main-i2c0-pins-default', 'main-i2c0-pins-int-default', 'main-i2c1-int-pins-default', 'main-i2c1-pins-default', 'main-mcan0-pins-default', 'main-mcan1-pins-default', 'main-mmc1-pins-default', 'main-uart0-pins-default', 'main-uart3-pins-default', 'mdio0-pins-default', 'ospi0-flash0-pins-default', 'ospi0-pins-default', 'pcie0-pins-default', 'pru-rgmii1-pins-default', 'pru-rgmii2-pins-default', 'pru1-mdio0-pins-default', 'regulator-pcie-3v3-pins-default', 'regulator-vpp-1v8-pins-default', 'rgmii1-pins-default', 'serdes-mux-pins-default', 'usb0-pins-default' do not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+' Other TI DTSs consistently end with *-pins-default. Should a different naming convention be used? 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 | 333 +++++++++++ arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++ 3 files changed, 972 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..f7b48ada8ef3 --- /dev/null +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts @@ -0,0 +1,333 @@ +// 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/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>; + status = "okay"; + + /* D24 */ + led1: led-1 { + label = "led1:green"; + gpios = <&main_gpio0 29 GPIO_ACTIVE_HIGH>; + }; + + /* D25 */ + led2: led-2 { + label = "led2:green"; + gpios = <&main_gpio0 30 GPIO_ACTIVE_HIGH>; + }; + + /* D26 */ + led3: led-3 { + label = "led3:green"; + gpios = <&main_gpio0 33 GPIO_ACTIVE_HIGH>; + }; + }; + + 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>; + status = "okay"; + }; + + light-sensor@44 { + compatible = "ti,opt3001"; + reg = <0x44>; + interrupt-parent = <&main_gpio0>; + interrupts = <37 IRQ_TYPE_EDGE_FALLING>; + status = "okay"; + }; + + battery-charger@6a { + compatible = "ti,bq25713"; + reg = <0x6a>; + status = "okay"; + }; +}; + +&main_i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>; + status = "okay"; + + rtc: am1805aq@69 { + compatible = "abracon,abx80x"; + reg = <0x69>; + abracon,tc-diode = "schottky"; + abracon,tc-resistor = <3>; + interrupt-parent = <&main_gpio0>; + interrupts = <44 IRQ_TYPE_EDGE_FALLING>; + status = "okay"; + }; +}; + +&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 + */ + status = "okay"; + + serdes0_link: phy@0 { + reg = <0>; + cdns,num-lanes = <1>; + #phy-cells = <0>; + cdns,phy-type = <PHY_NONE>; + resets = <&serdes_wiz0 1>; + status = "okay"; + }; +}; + +&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..952a262d6874 --- /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"; + bootargs = "earlycon=ns16550a,mmio32,0x02800000"; + }; + + /* 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>; + + 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] 13+ messages in thread
* Re: [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board 2024-01-03 11:27 ` [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer @ 2024-01-04 7:54 ` Krzysztof Kozlowski 2024-01-04 11:01 ` Josua Mayer 0 siblings, 1 reply; 13+ messages in thread From: Krzysztof Kozlowski @ 2024-01-04 7:54 UTC (permalink / raw) To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel On 03/01/2024 12:27, 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. > > RFC: dtbs_check reports: > > - error in pru ethernet: > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: dmas: [[12, 49664, 15], [12, 49665, 15], [12, 49666, 15], [12, 49667, 15], [12, 49668, 15], [12, 49669, 15], [12, 49670, 15], [12, 49671, 15], [12, 16896, 15], [12, 16897, 15], [12, 16898, 0], [12, 16899, 0]] is too long > from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: Unevaluated properties are not allowed ('dmas' was unexpected) > from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# > > 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. > > At least for this revision I am skipping fixing the bindings, because > aside from raising the maximum to 12, dma-names also has just 10 entries > - and don't know which names would be correct to add. > > - undocumented compatible ti,bq25713 (battery charger) > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20000000/battery-charger@6a: failed to match any schema with compatible: ['ti,bq25713'] > > This specific charger has no linux support yet, I am not sure where > (or whether) to document the new compatible. > The reference could also be dropped completely, since the charger is > not assebled by default. > > - undocumented compatible for rtc: "abracon,abx80x" > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20010000/am1805aq@69: failed to match any schema with compatible: ['abracon,abx80x'] > > It is actually documented in text format: > Documentation/devicetree/bindings/rtc/abracon,abx80x.txt > > - phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: serdes@f000000: phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 > from schema $id: http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml# > > I used value 0 here on purpose (phy.h: #define PHY_NONE 0), however > maybe better to choose a specific protocol? > Or better to update binding and allow 0? > > - interrupt properties not allowed for spi flash > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: flash@0: Unevaluated properties are not allowed ('interrupt-parent', 'interrupts' were unexpected) > from schema $id: http://devicetree.org/schemas/mtd/jedec,spi-nor.yaml# > > The assembled flash memory "sh28hs512t" definitely has an interrupt > pin wired to a cpu gpio. Should interrupts be added to spi flash > binding? > > - wrong names for pinctrl nodes > > arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: pinctrl@f4000: 'ethernet-phy-pins-default', 'ethernet-phy0-pins-default', 'ethernet-phy1-pins-default', 'ethernet-phy2-pins-default', 'leds-pins-default', 'main-i2c0-pins-default', 'main-i2c0-pins-int-default', 'main-i2c1-int-pins-default', 'main-i2c1-pins-default', 'main-mcan0-pins-default', 'main-mcan1-pins-default', 'main-mmc1-pins-default', 'main-uart0-pins-default', 'main-uart3-pins-default', 'mdio0-pins-default', 'ospi0-flash0-pins-default', 'ospi0-pins-default', 'pcie0-pins-default', 'pru-rgmii1-pins-default', 'pru-rgmii2-pins-default', 'pru1-mdio0-pins-default', 'regulator-pcie-3v3-pins-default', 'regulator-vpp-1v8-pins-default', 'rgmii1-pins-default', 'serdes-mux-pins-default', 'usb0-pins-default' do not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+' > > Other TI DTSs consistently end with *-pins-default. Should a different > naming convention be used? > > 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 | 333 +++++++++++ > arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++ > 3 files changed, 972 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..f7b48ada8ef3 > --- /dev/null > +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts > @@ -0,0 +1,333 @@ > +// 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/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>; > + status = "okay"; Where was it disabled? > + > + /* D24 */ > + led1: led-1 { > + label = "led1:green"; Use function and color instead. > + gpios = <&main_gpio0 29 GPIO_ACTIVE_HIGH>; > + }; > + ... > + > +&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>; > + status = "okay"; Where was it disabled? > + }; > + > + light-sensor@44 { > + compatible = "ti,opt3001"; > + reg = <0x44>; > + interrupt-parent = <&main_gpio0>; > + interrupts = <37 IRQ_TYPE_EDGE_FALLING>; > + status = "okay"; Where was it disabled? > + }; > + > + battery-charger@6a { charger@ > + compatible = "ti,bq25713"; > + reg = <0x6a>; > + status = "okay"; Where was it disabled? > + }; > +}; > + > +&main_i2c1 { > + pinctrl-names = "default"; > + pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>; > + status = "okay"; > + > + rtc: am1805aq@69 { 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 = "abracon,abx80x"; > + reg = <0x69>; > + abracon,tc-diode = "schottky"; > + abracon,tc-resistor = <3>; > + interrupt-parent = <&main_gpio0>; > + interrupts = <44 IRQ_TYPE_EDGE_FALLING>; > + status = "okay"; Where was it disabled? > + }; > +}; > + ... > + > +&serdes0 { > + /* > + * Serdes Signals are routed via mux to either m.2 connectors: > + * - M1: USB-3.1 > + * - M2: PCI-E > + */ > + status = "okay"; > + > + serdes0_link: phy@0 { > + reg = <0>; > + cdns,num-lanes = <1>; > + #phy-cells = <0>; > + cdns,phy-type = <PHY_NONE>; > + resets = <&serdes_wiz0 1>; > + status = "okay"; Where was it disabled? > + }; > +}; > + > +&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..952a262d6874 > --- /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"; > + bootargs = "earlycon=ns16550a,mmio32,0x02800000"; Drop bootargs. earlycon is for debugging. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board 2024-01-04 7:54 ` Krzysztof Kozlowski @ 2024-01-04 11:01 ` Josua Mayer 2024-01-04 11:22 ` Krzysztof Kozlowski 0 siblings, 1 reply; 13+ messages in thread From: Josua Mayer @ 2024-01-04 11:01 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org resend because HTML :( sorry ... Am 04.01.24 um 08:54 schrieb Krzysztof Kozlowski: > On 03/01/2024 12:27, 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. >> >> RFC: dtbs_check reports: >> >> - error in pru ethernet: >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: dmas: [[12, 49664, 15], [12, 49665, 15], [12, 49666, 15], [12, 49667, 15], [12, 49668, 15], [12, 49669, 15], [12, 49670, 15], [12, 49671, 15], [12, 16896, 15], [12, 16897, 15], [12, 16898, 0], [12, 16899, 0]] is too long >> from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: icssg1-eth: Unevaluated properties are not allowed ('dmas' was unexpected) >> from schema $id: http://devicetree.org/schemas/net/ti,icssg-prueth.yaml# >> >> 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. >> >> At least for this revision I am skipping fixing the bindings, because >> aside from raising the maximum to 12, dma-names also has just 10 entries >> - and don't know which names would be correct to add. >> >> - undocumented compatible ti,bq25713 (battery charger) >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20000000/battery-charger@6a: failed to match any schema with compatible: ['ti,bq25713'] >> >> This specific charger has no linux support yet, I am not sure where >> (or whether) to document the new compatible. >> The reference could also be dropped completely, since the charger is >> not assebled by default. >> >> - undocumented compatible for rtc: "abracon,abx80x" >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t-pcie.dtb: /bus@f4000/i2c@20010000/am1805aq@69: failed to match any schema with compatible: ['abracon,abx80x'] >> >> It is actually documented in text format: >> Documentation/devicetree/bindings/rtc/abracon,abx80x.txt >> >> - phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: serdes@f000000: phy@0:cdns,phy-type:0:0: 0 is less than the minimum of 1 >> from schema $id: http://devicetree.org/schemas/phy/phy-cadence-torrent.yaml# >> >> I used value 0 here on purpose (phy.h: #define PHY_NONE 0), however >> maybe better to choose a specific protocol? >> Or better to update binding and allow 0? >> >> - interrupt properties not allowed for spi flash >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: flash@0: Unevaluated properties are not allowed ('interrupt-parent', 'interrupts' were unexpected) >> from schema $id: http://devicetree.org/schemas/mtd/jedec,spi-nor.yaml# >> >> The assembled flash memory "sh28hs512t" definitely has an interrupt >> pin wired to a cpu gpio. Should interrupts be added to spi flash >> binding? >> >> - wrong names for pinctrl nodes >> >> arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dtb: pinctrl@f4000: 'ethernet-phy-pins-default', 'ethernet-phy0-pins-default', 'ethernet-phy1-pins-default', 'ethernet-phy2-pins-default', 'leds-pins-default', 'main-i2c0-pins-default', 'main-i2c0-pins-int-default', 'main-i2c1-int-pins-default', 'main-i2c1-pins-default', 'main-mcan0-pins-default', 'main-mcan1-pins-default', 'main-mmc1-pins-default', 'main-uart0-pins-default', 'main-uart3-pins-default', 'mdio0-pins-default', 'ospi0-flash0-pins-default', 'ospi0-pins-default', 'pcie0-pins-default', 'pru-rgmii1-pins-default', 'pru-rgmii2-pins-default', 'pru1-mdio0-pins-default', 'regulator-pcie-3v3-pins-default', 'regulator-vpp-1v8-pins-default', 'rgmii1-pins-default', 'serdes-mux-pins-default', 'usb0-pins-default' do not match any of the regexes: '-pins(-[0-9]+)?$|-pin$', 'pinctrl-[0-9]+' >> >> Other TI DTSs consistently end with *-pins-default. Should a different >> naming convention be used? >> >> 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 | 333 +++++++++++ >> arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 638 +++++++++++++++++++++ >> 3 files changed, 972 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..f7b48ada8ef3 >> --- /dev/null >> +++ b/arch/arm64/boot/dts/ti/k3-am642-hummingboard-t.dts >> @@ -0,0 +1,333 @@ >> +// 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/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>; >> + status = "okay"; > Where was it disabled? Nowhere. Better to omit status on new nodes added by new dts file? >> + >> + /* D24 */ >> + led1: led-1 { >> + label = "led1:green"; > Use function This board has no default function defined by labels or enclosure. Not sure what to pick for "function" property. Can I omit it and set only color? If so - should I drop label completely - or keep the "led1" part? > and color instead. Ack >> + gpios = <&main_gpio0 29 GPIO_ACTIVE_HIGH>; >> + }; >> + > ... > >> + >> +&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>; >> + status = "okay"; > Where was it disabled? Nowhere. >> + }; >> + >> + light-sensor@44 { >> + compatible = "ti,opt3001"; >> + reg = <0x44>; >> + interrupt-parent = <&main_gpio0>; >> + interrupts = <37 IRQ_TYPE_EDGE_FALLING>; >> + status = "okay"; > Where was it disabled? Nowhere. >> + }; >> + >> + battery-charger@6a { > charger@ > >> + compatible = "ti,bq25713"; >> + reg = <0x6a>; >> + status = "okay"; > Where was it disabled? Nowhere. >> + }; >> +}; >> + >> +&main_i2c1 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&main_i2c1_pins_default>, <&main_i2c1_int_pins_default>; >> + status = "okay"; >> + >> + rtc: am1805aq@69 { > 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 Ack. >> + compatible = "abracon,abx80x"; >> + reg = <0x69>; >> + abracon,tc-diode = "schottky"; >> + abracon,tc-resistor = <3>; >> + interrupt-parent = <&main_gpio0>; >> + interrupts = <44 IRQ_TYPE_EDGE_FALLING>; >> + status = "okay"; > Where was it disabled? Nowhere. >> + }; >> +}; >> + > ... > >> + >> +&serdes0 { >> + /* >> + * Serdes Signals are routed via mux to either m.2 connectors: >> + * - M1: USB-3.1 >> + * - M2: PCI-E >> + */ >> + status = "okay"; I set status here because I expect nodes inherited from other dtsi to be maybe disabled. In this instance, k3-am64-main.dtsi however sets no status for "serdes0: serdes@f000000" node. >> + >> + serdes0_link: phy@0 { >> + reg = <0>; >> + cdns,num-lanes = <1>; >> + #phy-cells = <0>; >> + cdns,phy-type = <PHY_NONE>; >> + resets = <&serdes_wiz0 1>; >> + status = "okay"; > Where was it disabled? Nowhere. >> + }; >> +}; >> + >> +&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..952a262d6874 >> --- /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"; >> + bootargs = "earlycon=ns16550a,mmio32,0x02800000"; > Drop bootargs. earlycon is for debugging. Ack. Sincerely Josua Mayer ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board 2024-01-04 11:01 ` Josua Mayer @ 2024-01-04 11:22 ` Krzysztof Kozlowski 2024-01-04 11:25 ` Josua Mayer 0 siblings, 1 reply; 13+ messages in thread From: Krzysztof Kozlowski @ 2024-01-04 11:22 UTC (permalink / raw) To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org On 04/01/2024 12:01, Josua Mayer wrote: >>> + >>> + leds { >>> + compatible = "gpio-leds"; >>> + pinctrl-names = "default"; >>> + pinctrl-0 = <&leds_pins_default>; >>> + status = "okay"; >> Where was it disabled? > Nowhere. Better to omit status on new nodes added by new dts file? Yes, you should not have any redundant status properties. okay is by default. >>> + >>> + /* D24 */ >>> + led1: led-1 { >>> + label = "led1:green"; >> Use function > This board has no default function defined by labels or enclosure. > Not sure what to pick for "function" property. Can I omit it and set only color? > > If so - should I drop label completely - or keep the "led1" part? Then keep label. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board 2024-01-04 11:22 ` Krzysztof Kozlowski @ 2024-01-04 11:25 ` Josua Mayer 0 siblings, 0 replies; 13+ messages in thread From: Josua Mayer @ 2024-01-04 11:25 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Am 04.01.24 um 12:22 schrieb Krzysztof Kozlowski: > On 04/01/2024 12:01, Josua Mayer wrote: > > >>>> + >>>> + leds { >>>> + compatible = "gpio-leds"; >>>> + pinctrl-names = "default"; >>>> + pinctrl-0 = <&leds_pins_default>; >>>> + status = "okay"; >>> Where was it disabled? >> Nowhere. Better to omit status on new nodes added by new dts file? > Yes, you should not have any redundant status properties. okay is by > default. Okay, thanks. > >>>> + >>>> + /* D24 */ >>>> + led1: led-1 { >>>> + label = "led1:green"; >>> Use function >> This board has no default function defined by labels or enclosure. >> Not sure what to pick for "function" property. Can I omit it and set only color? >> >> If so - should I drop label completely - or keep the "led1" part? > Then keep label. Just to be clear, which is correct?: a) label = "led1:green"; b) label = "led1"; color = <LED_COLOR_ID_GREEN>; > > > > Best regards, > Krzysztof > ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 3/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer 2024-01-03 11:27 ` [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer 2024-01-03 11:27 ` [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer @ 2024-01-03 11:27 ` Josua Mayer 2024-01-03 11:27 ` [PATCH 4/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer 2024-01-03 11:27 ` [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports Josua Mayer 4 siblings, 0 replies; 13+ messages in thread From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel, 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] 13+ messages in thread
* [PATCH 4/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer ` (2 preceding siblings ...) 2024-01-03 11:27 ` [PATCH 3/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer @ 2024-01-03 11:27 ` Josua Mayer 2024-01-03 11:27 ` [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports Josua Mayer 4 siblings, 0 replies; 13+ messages in thread From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel, 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] 13+ messages in thread
* [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer ` (3 preceding siblings ...) 2024-01-03 11:27 ` [PATCH 4/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer @ 2024-01-03 11:27 ` Josua Mayer 2024-01-04 7:55 ` Krzysztof Kozlowski 4 siblings, 1 reply; 13+ messages in thread From: Josua Mayer @ 2024-01-03 11:27 UTC (permalink / raw) To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel, Josua Mayer AM64 SoCs have "Industrial Ethernet Peripherals" (IEP). Link them to the icssg pru ethernet on solidrun am64s som. Signed-off-by: Josua Mayer <josua@solid-run.com> --- arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi index 952a262d6874..92f60ae7dc8d 100644 --- a/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am642-sr-som.dtsi @@ -49,6 +49,7 @@ icssg1_eth: icssg1-eth { 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>; -- 2.35.3 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports 2024-01-03 11:27 ` [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports Josua Mayer @ 2024-01-04 7:55 ` Krzysztof Kozlowski 2024-01-04 9:57 ` Josua Mayer 0 siblings, 1 reply; 13+ messages in thread From: Krzysztof Kozlowski @ 2024-01-04 7:55 UTC (permalink / raw) To: Josua Mayer, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel, devicetree, linux-kernel On 03/01/2024 12:27, Josua Mayer wrote: > AM64 SoCs have "Industrial Ethernet Peripherals" (IEP). Link them to the > icssg pru ethernet on solidrun am64s som. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- Why this is not part of original submission? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports 2024-01-04 7:55 ` Krzysztof Kozlowski @ 2024-01-04 9:57 ` Josua Mayer 0 siblings, 0 replies; 13+ messages in thread From: Josua Mayer @ 2024-01-04 9:57 UTC (permalink / raw) To: Krzysztof Kozlowski, Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Am 04.01.24 um 08:55 schrieb Krzysztof Kozlowski: > On 03/01/2024 12:27, Josua Mayer wrote: >> AM64 SoCs have "Industrial Ethernet Peripherals" (IEP). Link them to the >> icssg pru ethernet on solidrun am64s som. >> >> Signed-off-by: Josua Mayer <josua@solid-run.com> >> --- > Why this is not part of original submission? It depends on patch #4 which isn't mine. If I were to reorder the series it could be part of #2. sincerely Josua Mayer ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2024-01-04 11:25 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-01-03 11:27 [PATCH 0/5] arm64: dts: add description for solidrun am642 som and hummingboard evb Josua Mayer 2024-01-03 11:27 ` [PATCH 1/5] dt-bindings: arm: ti: Add bindings for SolidRun AM642 HummingBoard-T Josua Mayer 2024-01-04 7:50 ` Krzysztof Kozlowski 2024-01-03 11:27 ` [PATCH 2/5] arm64: dts: add description for solidrun am642 som and evaluation board Josua Mayer 2024-01-04 7:54 ` Krzysztof Kozlowski 2024-01-04 11:01 ` Josua Mayer 2024-01-04 11:22 ` Krzysztof Kozlowski 2024-01-04 11:25 ` Josua Mayer 2024-01-03 11:27 ` [PATCH 3/5] arm64: dts: ti: hummingboard-t: add descriptions for m.2 pci-e and usb-3 Josua Mayer 2024-01-03 11:27 ` [PATCH 4/5] arm64: dts: ti: k3-am64-main: Add ICSSG IEP nodes Josua Mayer 2024-01-03 11:27 ` [PATCH 5/5] arm64: dts: ti: am642-sr-som: enable iep for pru ethernet ports Josua Mayer 2024-01-04 7:55 ` Krzysztof Kozlowski 2024-01-04 9:57 ` 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 NNTP newsgroup(s).