* [PATCH v2 0/5] arm64: dts: freescale: add support for the GOcontroll Moduline IV/Mini
@ 2025-10-22 7:22 ` Maud Spierings via B4 Relay
0 siblings, 0 replies; 34+ messages in thread
From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings,
Conor Dooley
Add initial support for the Moduline IV and Moduline Mini embedded
controllers.
These systems are powered by the Ka-Ro Electronics tx8m-1610 COM, which
features an imx8mm SoC.
Signed-off-by: Maud Spierings <maudspierings@gocontroll.com>
---
Changes in v2:
- Fix allignment issue in imx8mm-tx8m-1610.dtsi (fec1)
- Move phy-reset into fec (works better in barebox)
- Make the gpio-line-names groups of four on every line
- Link to v1: https://lore.kernel.org/r/20251009-mini_iv-v1-0-f3889c492457@gocontroll.com
---
Maud Spierings (5):
dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini
arm64: dts: imx8mm: Add pinctrl config definitions
arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM
arm64: dts: freescale: Add the GOcontroll Moduline IV
arm64: dts: freescale: Add the GOcontroll Moduline Mini
Documentation/devicetree/bindings/arm/fsl.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 3 +
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 33 +
.../imx8mm-tx8m-1610-moduline-iv-306-d.dts | 801 +++++++++++++++++++++
.../imx8mm-tx8m-1610-moduline-mini-111.dts | 691 ++++++++++++++++++
.../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++
6 files changed, 1969 insertions(+)
---
base-commit: 7c3ba4249a3604477ea9c077e10089ba7ddcaa03
change-id: 20251009-mini_iv-a05e5c2c1223
Best regards,
--
Maud Spierings <maudspierings@gocontroll.com>
^ permalink raw reply [flat|nested] 34+ messages in thread* [PATCH v2 0/5] arm64: dts: freescale: add support for the GOcontroll Moduline IV/Mini @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings, Conor Dooley Add initial support for the Moduline IV and Moduline Mini embedded controllers. These systems are powered by the Ka-Ro Electronics tx8m-1610 COM, which features an imx8mm SoC. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- Changes in v2: - Fix allignment issue in imx8mm-tx8m-1610.dtsi (fec1) - Move phy-reset into fec (works better in barebox) - Make the gpio-line-names groups of four on every line - Link to v1: https://lore.kernel.org/r/20251009-mini_iv-v1-0-f3889c492457@gocontroll.com --- Maud Spierings (5): dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini arm64: dts: imx8mm: Add pinctrl config definitions arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM arm64: dts: freescale: Add the GOcontroll Moduline IV arm64: dts: freescale: Add the GOcontroll Moduline Mini Documentation/devicetree/bindings/arm/fsl.yaml | 2 + arch/arm64/boot/dts/freescale/Makefile | 3 + arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 33 + .../imx8mm-tx8m-1610-moduline-iv-306-d.dts | 801 +++++++++++++++++++++ .../imx8mm-tx8m-1610-moduline-mini-111.dts | 691 ++++++++++++++++++ .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++ 6 files changed, 1969 insertions(+) --- base-commit: 7c3ba4249a3604477ea9c077e10089ba7ddcaa03 change-id: 20251009-mini_iv-a05e5c2c1223 Best regards, -- Maud Spierings <maudspierings@gocontroll.com> ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 1/5] dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini 2025-10-22 7:22 ` Maud Spierings via B4 Relay @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings, Conor Dooley Document the compatible strings for the Moduline IV and Mini. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 00cdf490b0620..41eb19e3530da 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -963,6 +963,8 @@ properties: - fsl,imx8mm-evkb # i.MX8MM EVKB Board - gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board - gateworks,imx8mm-gw7904 + - gocontroll,moduline-iv + - gocontroll,moduline-mini - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 1/5] dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings, Conor Dooley From: Maud Spierings <maudspierings@gocontroll.com> Document the compatible strings for the Moduline IV and Mini. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- Documentation/devicetree/bindings/arm/fsl.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 00cdf490b0620..41eb19e3530da 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -963,6 +963,8 @@ properties: - fsl,imx8mm-evkb # i.MX8MM EVKB Board - gateworks,imx8mm-gw75xx-0x # i.MX8MM Gateworks Board - gateworks,imx8mm-gw7904 + - gocontroll,moduline-iv + - gocontroll,moduline-mini - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw72xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 2/5] arm64: dts: imx8mm: Add pinctrl config definitions 2025-10-22 7:22 ` Maud Spierings via B4 Relay @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this register is written in the dts, these values are not obvious. Add defines which describe the fields of this register which can be or-ed together to produce readable settings. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 33 ++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h index b1f11098d248e..31557b7b9ccc1 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h +++ b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h @@ -6,6 +6,39 @@ #ifndef __DTS_IMX8MM_PINFUNC_H #define __DTS_IMX8MM_PINFUNC_H +/* Drive Strength */ +#define MX8MM_DSE_X1 0x0 +#define MX8MM_DSE_X2 0x4 +#define MX8MM_DSE_X4 0x2 +#define MX8MM_DSE_X6 0x6 + +/* Slew Rate */ +#define MX8MM_FSEL_FAST 0x10 +#define MX8MM_FSEL_SLOW 0x0 + +/* Open Drain */ +#define MX8MM_ODE_ENABLE 0x20 +#define MX8MM_ODE_DISABLE 0x0 + +#define MX8MM_PULL_DOWN 0x0 +#define MX8MM_PULL_UP 0x40 + +/* Hysteresis */ +#define MX8MM_HYS_CMOS 0x0 +#define MX8MM_HYS_SCHMITT 0x80 + +#define MX8MM_PULL_ENABLE 0x100 +#define MX8MM_PULL_DISABLE 0x0 + +/* SION force input mode */ +#define MX8MM_SION 0x40000000 + +/* long defaults */ +#define MX8MM_USDHC_DATA_DEFAULT (MX8MM_FSEL_FAST | MX8MM_PULL_UP | \ + MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) +#define MX8MM_I2C_DEFAULT (MX8MM_DSE_X6 | MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | \ + MX8MM_PULL_ENABLE | MX8MM_SION) + /* * The pin function ID is a tuple of * <mux_reg conf_reg input_reg mux_mode input_val> -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 2/5] arm64: dts: imx8mm: Add pinctrl config definitions @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings From: Maud Spierings <maudspierings@gocontroll.com> Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this register is written in the dts, these values are not obvious. Add defines which describe the fields of this register which can be or-ed together to produce readable settings. Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h | 33 ++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h index b1f11098d248e..31557b7b9ccc1 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h +++ b/arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h @@ -6,6 +6,39 @@ #ifndef __DTS_IMX8MM_PINFUNC_H #define __DTS_IMX8MM_PINFUNC_H +/* Drive Strength */ +#define MX8MM_DSE_X1 0x0 +#define MX8MM_DSE_X2 0x4 +#define MX8MM_DSE_X4 0x2 +#define MX8MM_DSE_X6 0x6 + +/* Slew Rate */ +#define MX8MM_FSEL_FAST 0x10 +#define MX8MM_FSEL_SLOW 0x0 + +/* Open Drain */ +#define MX8MM_ODE_ENABLE 0x20 +#define MX8MM_ODE_DISABLE 0x0 + +#define MX8MM_PULL_DOWN 0x0 +#define MX8MM_PULL_UP 0x40 + +/* Hysteresis */ +#define MX8MM_HYS_CMOS 0x0 +#define MX8MM_HYS_SCHMITT 0x80 + +#define MX8MM_PULL_ENABLE 0x100 +#define MX8MM_PULL_DISABLE 0x0 + +/* SION force input mode */ +#define MX8MM_SION 0x40000000 + +/* long defaults */ +#define MX8MM_USDHC_DATA_DEFAULT (MX8MM_FSEL_FAST | MX8MM_PULL_UP | \ + MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) +#define MX8MM_I2C_DEFAULT (MX8MM_DSE_X6 | MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | \ + MX8MM_PULL_ENABLE | MX8MM_SION) + /* * The pin function ID is a tuple of * <mux_reg conf_reg input_reg mux_mode input_val> -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-22 7:22 ` Maud Spierings via B4 Relay @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has 1 GB of ram and 4 GB of eMMC storage on board. Add it to enable boards based on this module Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++++++++++++ 1 file changed, 439 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi new file mode 100644 index 0000000000000..46d3ad80942cc --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi @@ -0,0 +1,439 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2021 Lothar Waßmann <LW@KARO-electronics.de> + * 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +#include "imx8mm.dtsi" + +/ { + reg_3v3_etn: regulator-3v3-etn { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_3v3_etn>; + pinctrl-names = "default"; + regulator-boot-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3-etn"; + }; +}; + +&A53_0 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_1 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_2 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_3 { + cpu-supply = <®_vdd_arm>; +}; + +&ddrc { + operating-points-v2 = <&ddrc_opp_table>; + + ddrc_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + }; + }; +}; + +&fec1 { + assigned-clocks = <&clk IMX8MM_CLK_ENET_AXI>, + <&clk IMX8MM_CLK_ENET_TIMER>, + <&clk IMX8MM_CLK_ENET_REF>, + <&clk IMX8MM_CLK_ENET_REF>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_266M>, + <&clk IMX8MM_SYS_PLL2_100M>, + <&clk IMX8MM_SYS_PLL2_50M>, + <&clk IMX8MM_SYS_PLL2_50M>; + assigned-clock-rates = <0>, <100000000>, <50000000>, <50000000>; + clocks = <&clk IMX8MM_CLK_ENET1_ROOT>, + <&clk IMX8MM_CLK_ENET1_ROOT>, + <&clk IMX8MM_CLK_ENET_TIMER>, + <&clk IMX8MM_CLK_ENET_REF>; + phy-handle = <ðphy0>; + phy-mode = "rmii"; + phy-reset-duration = <25>; + phy-reset-gpios = <&gpio1 29 GPIO_ACTIVE_LOW>; + phy-reset-post-delay = <1>; + phy-supply = <®_3v3_etn>; + pinctrl-0 = <&pinctrl_fec1>, <&pinctrl_ethphy_rst>; + pinctrl-names = "default"; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + reg = <0>; + clocks = <&clk IMX8MM_CLK_ENET_REF>; + smsc,disable-energy-detect; + }; + }; +}; + +&gpio1 { + gpio-line-names = "SODIMM_152", "SODIMM_42", "SODIMM_153", "PMIC_IRQ_B", + "SODIMM_154", "SODIMM_155", "SODIMM_156", "SODIMM_157", + "SODIMM_158", "SODIMM_159", "SODIMM_161", "SODIMM_162", + "SODIMM_34", "SODIMM_36", "SODIMM_27", "SODIMM_28", + "", "", "", "", + "", "", "", "ENET_POWER", + "", "", "", "", + "ENET_nINT", "ENET_nRST", "", ""; +}; + +&gpio2 { + gpio-line-names = "", "", "", "", + "", "", "", "", + "", "", "", "", + "SODIMM_51", "SODIMM_57", "SODIMM_56", "SODIMM_52", + "SODIMM_53", "SODIMM_54", "SODIMM_55", "SODIMM_15", + "SODIMM_45", "", "", "", + "", "", "", "", + "", "", "", ""; +}; + +&gpio3 { + gpio-line-names = "SODIMM_103", "SODIMM_104", "SODIMM_105", "SODIMM_106", + "SODIMM_107", "SODIMM_112", "SODIMM_108", "SODIMM_109", + "SODIMM_95", "SODIMM_110", "SODIMM_96", "SODIMM_97", + "SODIMM_98", "SODIMM_99", "SODIMM_113", "SODIMM_114", + "SODIMM_115", "SODIMM_101", "SODIMM_100", "SODIMM_77", + "SODIMM_72", "SODIMM_73", "SODIMM_74", "SODIMM_75", + "SODIMM_76", "SODIMM_43", "", "", + "", "", "", ""; +}; + +&gpio4 { + gpio-line-names = "SODIMM_178", "SODIMM_180", "SODIMM_184", "SODIMM_185", + "SODIMM_186", "SODIMM_187", "SODIMM_188", "SODIMM_189", + "SODIMM_190", "SODIMM_191", "SODIMM_179", "SODIMM_181", + "SODIMM_192", "SODIMM_193", "SODIMM_194", "SODIMM_195", + "SODIMM_196", "SODIMM_197", "SODIMM_198", "SODIMM_199", + "SODIMM_182", "SODIMM_79", "SODIMM_78", "SODIMM_84", + "SODIMM_87", "SODIMM_86", "SODIMM_85", "SODIMM_83", + "SODIMM_81", "SODIMM_80", "SODIMM_90", "SODIMM_93"; +}; + +&gpio5 { + gpio-line-names = "SODIMM_92", "SODIMM_91", "SODIMM_89", "SODIMM_144", + "SODIMM_143", "SODIMM_146", "SODIMM_68", "SODIMM_67", + "SODIMM_70", "SODIMM_69", "SODIMM_48", "SODIMM_46", + "SODIMM_47", "SODIMM_44", "PMIC_SCL", "PMIC_SDA", + "SODIMM_41", "SODIMM_40", "SODIMM_148", "SODIMM_149", + "SODIMM_150", "SODIMM_151", "SODIMM_60", "SODIMM_59", + "SODIMM_64", "SODIMM_63", "SODIMM_62", "SODIMM_61", + "SODIMM_66", "SODIMM_65", "", ""; +}; + +&i2c1 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c1>; + pinctrl-1 = <&pinctrl_i2c1_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + pmic: pmic@4b { + compatible = "rohm,bd71847"; + reg = <0x4b>; + interrupt-parent = <&gpio1>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_pmic>; + pinctrl-names = "default"; + rohm,reset-snvs-powered; + + regulators { + reg_vdd_soc: BUCK1 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <780000>; + regulator-name = "buck1"; + regulator-ramp-delay = <1250>; + }; + + reg_vdd_arm: BUCK2 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <950000>; + regulator-min-microvolt = <805000>; + regulator-name = "buck2"; + regulator-ramp-delay = <1250>; + rohm,dvs-run-voltage = <950000>; + rohm,dvs-idle-voltage = <810000>; + }; + + reg_vdd_dram: BUCK3 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <805000>; + regulator-name = "buck3"; + }; + + reg_vdd_3v3: BUCK4 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "buck4"; + }; + + reg_vdd_1v8: BUCK5 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1950000>; + regulator-min-microvolt = <1700000>; + regulator-name = "buck5"; + }; + + BUCK6 { + regulator-always-on; + regulator-boot-on; + /* + * The default output voltage is 1.1V, bumped + * to 1.35V in HW by a 499R/2.2K voltage divider in the + * feedback path. + */ + regulator-max-microvolt = <1100000>; + regulator-min-microvolt = <1100000>; + regulator-name = "buck6"; + }; + + reg_snvs_1v8: LDO1 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1980000>; + regulator-min-microvolt = <1620000>; + regulator-name = "ldo1"; + }; + + reg_snvs_0v8: LDO2 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <760000>; + regulator-name = "ldo2"; + }; + + reg_vdda_1v8: LDO3 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1890000>; + regulator-min-microvolt = <1710000>; + regulator-name = "ldo3"; + }; + + reg_vdd_phy_0v9: LDO4 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1000000>; + regulator-min-microvolt = <855000>; + regulator-name = "ldo4"; + }; + + ldo5_reg: LDO5 { + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <1800000>; + regulator-name = "ldo5"; + }; + + reg_vdd_phy_1v2: LDO6 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1260000>; + regulator-min-microvolt = <1140000>; + regulator-name = "ldo6"; + }; + }; + }; +}; + +&iomuxc { + pinctrl_ethphy_int: etnphy-intgrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_ethphy_rst: etnphy-rstgrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_fec1: fec1grp { + fsl,pins = < + MX8MM_IOMUXC_ENET_MDC_ENET1_MDC + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_ENET_TD2_ENET1_TX_CLK + (MX8MM_FSEL_FAST | MX8MM_SION) + MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ENET_RXC_ENET1_RX_ER + MX8MM_FSEL_FAST + MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL + MX8MM_FSEL_FAST + MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + >; + }; + + pinctrl_i2c1: i2c1grp { + fsl,pins = < + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c1_gpio: i2c1-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C1_SCL_GPIO5_IO14 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C1_SDA_GPIO5_IO15 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_pmic: pmicgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_reg_3v3_etn: reg-3v3-etngrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23 + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1: usdhc1grp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; +}; + +&usdhc1 { + assigned-clocks = <&clk IMX8MM_CLK_USDHC1>; + assigned-clock-rates = <400000000>; + bus-width = <8>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc1>; + pinctrl-1 = <&pinctrl_usdhc1_100mhz>; + pinctrl-2 = <&pinctrl_usdhc1_200mhz>; + pinctrl-names = "default", "state_100mhz", "state_200mhz"; + vmmc-supply = <®_vdd_3v3>; + vqmmc-supply = <®_vdd_1v8>; + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings From: Maud Spierings <maudspierings@gocontroll.com> The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has 1 GB of ram and 4 GB of eMMC storage on board. Add it to enable boards based on this module Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++++++++++++ 1 file changed, 439 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi new file mode 100644 index 0000000000000..46d3ad80942cc --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi @@ -0,0 +1,439 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2021 Lothar Waßmann <LW@KARO-electronics.de> + * 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +#include "imx8mm.dtsi" + +/ { + reg_3v3_etn: regulator-3v3-etn { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 23 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_3v3_etn>; + pinctrl-names = "default"; + regulator-boot-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3-etn"; + }; +}; + +&A53_0 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_1 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_2 { + cpu-supply = <®_vdd_arm>; +}; + +&A53_3 { + cpu-supply = <®_vdd_arm>; +}; + +&ddrc { + operating-points-v2 = <&ddrc_opp_table>; + + ddrc_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + }; + }; +}; + +&fec1 { + assigned-clocks = <&clk IMX8MM_CLK_ENET_AXI>, + <&clk IMX8MM_CLK_ENET_TIMER>, + <&clk IMX8MM_CLK_ENET_REF>, + <&clk IMX8MM_CLK_ENET_REF>; + assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_266M>, + <&clk IMX8MM_SYS_PLL2_100M>, + <&clk IMX8MM_SYS_PLL2_50M>, + <&clk IMX8MM_SYS_PLL2_50M>; + assigned-clock-rates = <0>, <100000000>, <50000000>, <50000000>; + clocks = <&clk IMX8MM_CLK_ENET1_ROOT>, + <&clk IMX8MM_CLK_ENET1_ROOT>, + <&clk IMX8MM_CLK_ENET_TIMER>, + <&clk IMX8MM_CLK_ENET_REF>; + phy-handle = <ðphy0>; + phy-mode = "rmii"; + phy-reset-duration = <25>; + phy-reset-gpios = <&gpio1 29 GPIO_ACTIVE_LOW>; + phy-reset-post-delay = <1>; + phy-supply = <®_3v3_etn>; + pinctrl-0 = <&pinctrl_fec1>, <&pinctrl_ethphy_rst>; + pinctrl-names = "default"; + status = "okay"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + reg = <0>; + clocks = <&clk IMX8MM_CLK_ENET_REF>; + smsc,disable-energy-detect; + }; + }; +}; + +&gpio1 { + gpio-line-names = "SODIMM_152", "SODIMM_42", "SODIMM_153", "PMIC_IRQ_B", + "SODIMM_154", "SODIMM_155", "SODIMM_156", "SODIMM_157", + "SODIMM_158", "SODIMM_159", "SODIMM_161", "SODIMM_162", + "SODIMM_34", "SODIMM_36", "SODIMM_27", "SODIMM_28", + "", "", "", "", + "", "", "", "ENET_POWER", + "", "", "", "", + "ENET_nINT", "ENET_nRST", "", ""; +}; + +&gpio2 { + gpio-line-names = "", "", "", "", + "", "", "", "", + "", "", "", "", + "SODIMM_51", "SODIMM_57", "SODIMM_56", "SODIMM_52", + "SODIMM_53", "SODIMM_54", "SODIMM_55", "SODIMM_15", + "SODIMM_45", "", "", "", + "", "", "", "", + "", "", "", ""; +}; + +&gpio3 { + gpio-line-names = "SODIMM_103", "SODIMM_104", "SODIMM_105", "SODIMM_106", + "SODIMM_107", "SODIMM_112", "SODIMM_108", "SODIMM_109", + "SODIMM_95", "SODIMM_110", "SODIMM_96", "SODIMM_97", + "SODIMM_98", "SODIMM_99", "SODIMM_113", "SODIMM_114", + "SODIMM_115", "SODIMM_101", "SODIMM_100", "SODIMM_77", + "SODIMM_72", "SODIMM_73", "SODIMM_74", "SODIMM_75", + "SODIMM_76", "SODIMM_43", "", "", + "", "", "", ""; +}; + +&gpio4 { + gpio-line-names = "SODIMM_178", "SODIMM_180", "SODIMM_184", "SODIMM_185", + "SODIMM_186", "SODIMM_187", "SODIMM_188", "SODIMM_189", + "SODIMM_190", "SODIMM_191", "SODIMM_179", "SODIMM_181", + "SODIMM_192", "SODIMM_193", "SODIMM_194", "SODIMM_195", + "SODIMM_196", "SODIMM_197", "SODIMM_198", "SODIMM_199", + "SODIMM_182", "SODIMM_79", "SODIMM_78", "SODIMM_84", + "SODIMM_87", "SODIMM_86", "SODIMM_85", "SODIMM_83", + "SODIMM_81", "SODIMM_80", "SODIMM_90", "SODIMM_93"; +}; + +&gpio5 { + gpio-line-names = "SODIMM_92", "SODIMM_91", "SODIMM_89", "SODIMM_144", + "SODIMM_143", "SODIMM_146", "SODIMM_68", "SODIMM_67", + "SODIMM_70", "SODIMM_69", "SODIMM_48", "SODIMM_46", + "SODIMM_47", "SODIMM_44", "PMIC_SCL", "PMIC_SDA", + "SODIMM_41", "SODIMM_40", "SODIMM_148", "SODIMM_149", + "SODIMM_150", "SODIMM_151", "SODIMM_60", "SODIMM_59", + "SODIMM_64", "SODIMM_63", "SODIMM_62", "SODIMM_61", + "SODIMM_66", "SODIMM_65", "", ""; +}; + +&i2c1 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c1>; + pinctrl-1 = <&pinctrl_i2c1_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + pmic: pmic@4b { + compatible = "rohm,bd71847"; + reg = <0x4b>; + interrupt-parent = <&gpio1>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_pmic>; + pinctrl-names = "default"; + rohm,reset-snvs-powered; + + regulators { + reg_vdd_soc: BUCK1 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <780000>; + regulator-name = "buck1"; + regulator-ramp-delay = <1250>; + }; + + reg_vdd_arm: BUCK2 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <950000>; + regulator-min-microvolt = <805000>; + regulator-name = "buck2"; + regulator-ramp-delay = <1250>; + rohm,dvs-run-voltage = <950000>; + rohm,dvs-idle-voltage = <810000>; + }; + + reg_vdd_dram: BUCK3 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <805000>; + regulator-name = "buck3"; + }; + + reg_vdd_3v3: BUCK4 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "buck4"; + }; + + reg_vdd_1v8: BUCK5 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1950000>; + regulator-min-microvolt = <1700000>; + regulator-name = "buck5"; + }; + + BUCK6 { + regulator-always-on; + regulator-boot-on; + /* + * The default output voltage is 1.1V, bumped + * to 1.35V in HW by a 499R/2.2K voltage divider in the + * feedback path. + */ + regulator-max-microvolt = <1100000>; + regulator-min-microvolt = <1100000>; + regulator-name = "buck6"; + }; + + reg_snvs_1v8: LDO1 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1980000>; + regulator-min-microvolt = <1620000>; + regulator-name = "ldo1"; + }; + + reg_snvs_0v8: LDO2 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <900000>; + regulator-min-microvolt = <760000>; + regulator-name = "ldo2"; + }; + + reg_vdda_1v8: LDO3 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1890000>; + regulator-min-microvolt = <1710000>; + regulator-name = "ldo3"; + }; + + reg_vdd_phy_0v9: LDO4 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1000000>; + regulator-min-microvolt = <855000>; + regulator-name = "ldo4"; + }; + + ldo5_reg: LDO5 { + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <1800000>; + regulator-name = "ldo5"; + }; + + reg_vdd_phy_1v2: LDO6 { + regulator-always-on; + regulator-boot-on; + regulator-max-microvolt = <1260000>; + regulator-min-microvolt = <1140000>; + regulator-name = "ldo6"; + }; + }; + }; +}; + +&iomuxc { + pinctrl_ethphy_int: etnphy-intgrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_ethphy_rst: etnphy-rstgrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_fec1: fec1grp { + fsl,pins = < + MX8MM_IOMUXC_ENET_MDC_ENET1_MDC + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_ENET_TD2_ENET1_TX_CLK + (MX8MM_FSEL_FAST | MX8MM_SION) + MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ENET_RXC_ENET1_RX_ER + MX8MM_FSEL_FAST + MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL + MX8MM_FSEL_FAST + MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST) + >; + }; + + pinctrl_i2c1: i2c1grp { + fsl,pins = < + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c1_gpio: i2c1-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C1_SCL_GPIO5_IO14 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C1_SDA_GPIO5_IO15 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_pmic: pmicgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_reg_3v3_etn: reg-3v3-etngrp { + fsl,pins = < + MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23 + (MX8MM_DSE_X4 | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1: usdhc1grp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + MX8MM_USDHC_DATA_DEFAULT + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp { + fsl,pins = < + MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 + (MX8MM_DSE_X6 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD1_STROBE_USDHC1_STROBE + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B + (MX8MM_DSE_X6 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; +}; + +&usdhc1 { + assigned-clocks = <&clk IMX8MM_CLK_USDHC1>; + assigned-clock-rates = <400000000>; + bus-width = <8>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc1>; + pinctrl-1 = <&pinctrl_usdhc1_100mhz>; + pinctrl-2 = <&pinctrl_usdhc1_200mhz>; + pinctrl-names = "default", "state_100mhz", "state_200mhz"; + vmmc-supply = <®_vdd_3v3>; + vqmmc-supply = <®_vdd_1v8>; + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-22 7:22 ` Maud Spierings via B4 Relay (?) @ 2025-10-28 12:15 ` Matti Vaittinen 2025-10-28 12:42 ` Maud Spierings -1 siblings, 1 reply; 34+ messages in thread From: Matti Vaittinen @ 2025-10-28 12:15 UTC (permalink / raw) To: maudspierings, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel Hi Maud, Thanks for the upstreaming work! :) On 22/10/2025 10:22, Maud Spierings via B4 Relay wrote: > From: Maud Spierings <maudspierings@gocontroll.com> > > The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has > 1 GB of ram and 4 GB of eMMC storage on board. > > Add it to enable boards based on this module > > Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> > --- > .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++++++++++++ > 1 file changed, 439 insertions(+) > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi > new file mode 100644 > index 0000000000000..46d3ad80942cc > --- /dev/null > +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi > @@ -0,0 +1,439 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* > + * Copyright (C) 2021 Lothar Waßmann <LW@KARO-electronics.de> > + * 2025 Maud Spierings <maudspierings@gocontroll.com> > + */ > + > +#include "imx8mm.dtsi" > + // snip > + pmic: pmic@4b { > + compatible = "rohm,bd71847"; > + reg = <0x4b>; > + interrupt-parent = <&gpio1>; > + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; > + pinctrl-0 = <&pinctrl_pmic>; > + pinctrl-names = "default"; > + rohm,reset-snvs-powered; > + > + regulators { > + reg_vdd_soc: BUCK1 { > + regulator-always-on; > + regulator-boot-on; > + regulator-max-microvolt = <900000>; > + regulator-min-microvolt = <780000>; > + regulator-name = "buck1"; > + regulator-ramp-delay = <1250>; > + }; > + > + reg_vdd_arm: BUCK2 { > + regulator-always-on; > + regulator-boot-on; > + regulator-max-microvolt = <950000>; > + regulator-min-microvolt = <805000>; > + regulator-name = "buck2"; > + regulator-ramp-delay = <1250>; > + rohm,dvs-run-voltage = <950000>; > + rohm,dvs-idle-voltage = <810000>; > + }; > + > + reg_vdd_dram: BUCK3 { > + regulator-always-on; > + regulator-boot-on; > + regulator-max-microvolt = <900000>; > + regulator-min-microvolt = <805000>; > + regulator-name = "buck3"; > + }; > + > + reg_vdd_3v3: BUCK4 { > + regulator-always-on; > + regulator-boot-on; > + regulator-max-microvolt = <3300000>; > + regulator-min-microvolt = <3300000>; > + regulator-name = "buck4"; > + }; > + > + reg_vdd_1v8: BUCK5 { > + regulator-always-on; > + regulator-boot-on; > + regulator-max-microvolt = <1950000>; > + regulator-min-microvolt = <1700000>; > + regulator-name = "buck5"; > + }; > + > + BUCK6 { > + regulator-always-on; > + regulator-boot-on; > + /* > + * The default output voltage is 1.1V, bumped > + * to 1.35V in HW by a 499R/2.2K voltage divider in the > + * feedback path. > + */ Could/Should this be described using the: 'rohm,feedback-pull-up-r1-ohms' and 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment correctly, that might allow the driver to be able to use correctly scaled voltages. https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > + regulator-max-microvolt = <1100000>; > + regulator-min-microvolt = <1100000>; > + regulator-name = "buck6"; > + }; Yours, -- Matti ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-28 12:15 ` Matti Vaittinen @ 2025-10-28 12:42 ` Maud Spierings 2025-10-28 13:10 ` Maud Spierings 0 siblings, 1 reply; 34+ messages in thread From: Maud Spierings @ 2025-10-28 12:42 UTC (permalink / raw) To: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel On 10/28/25 13:15, Matti Vaittinen wrote: > Hi Maud, > > Thanks for the upstreaming work! :) > > On 22/10/2025 10:22, Maud Spierings via B4 Relay wrote: >> From: Maud Spierings <maudspierings@gocontroll.com> >> >> The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has >> 1 GB of ram and 4 GB of eMMC storage on board. >> >> Add it to enable boards based on this module >> >> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> >> --- >> .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 +++++++++++ >> ++++++++++ >> 1 file changed, 439 insertions(+) >> >> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi b/ >> arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi >> new file mode 100644 >> index 0000000000000..46d3ad80942cc >> --- /dev/null >> +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi >> @@ -0,0 +1,439 @@ >> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >> +/* >> + * Copyright (C) 2021 Lothar Waßmann <LW@KARO-electronics.de> >> + * 2025 Maud Spierings <maudspierings@gocontroll.com> >> + */ >> + >> +#include "imx8mm.dtsi" >> + > > // snip > >> + pmic: pmic@4b { >> + compatible = "rohm,bd71847"; >> + reg = <0x4b>; >> + interrupt-parent = <&gpio1>; >> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; >> + pinctrl-0 = <&pinctrl_pmic>; >> + pinctrl-names = "default"; >> + rohm,reset-snvs-powered; >> + >> + regulators { >> + reg_vdd_soc: BUCK1 { >> + regulator-always-on; >> + regulator-boot-on; >> + regulator-max-microvolt = <900000>; >> + regulator-min-microvolt = <780000>; >> + regulator-name = "buck1"; >> + regulator-ramp-delay = <1250>; >> + }; >> + >> + reg_vdd_arm: BUCK2 { >> + regulator-always-on; >> + regulator-boot-on; >> + regulator-max-microvolt = <950000>; >> + regulator-min-microvolt = <805000>; >> + regulator-name = "buck2"; >> + regulator-ramp-delay = <1250>; >> + rohm,dvs-run-voltage = <950000>; >> + rohm,dvs-idle-voltage = <810000>; >> + }; >> + >> + reg_vdd_dram: BUCK3 { >> + regulator-always-on; >> + regulator-boot-on; >> + regulator-max-microvolt = <900000>; >> + regulator-min-microvolt = <805000>; >> + regulator-name = "buck3"; >> + }; >> + >> + reg_vdd_3v3: BUCK4 { >> + regulator-always-on; >> + regulator-boot-on; >> + regulator-max-microvolt = <3300000>; >> + regulator-min-microvolt = <3300000>; >> + regulator-name = "buck4"; >> + }; >> + >> + reg_vdd_1v8: BUCK5 { >> + regulator-always-on; >> + regulator-boot-on; >> + regulator-max-microvolt = <1950000>; >> + regulator-min-microvolt = <1700000>; >> + regulator-name = "buck5"; >> + }; >> + >> + BUCK6 { >> + regulator-always-on; >> + regulator-boot-on; >> + /* >> + * The default output voltage is 1.1V, bumped >> + * to 1.35V in HW by a 499R/2.2K voltage divider in the >> + * feedback path. >> + */ > > Could/Should this be described using the: > 'rohm,feedback-pull-up-r1-ohms' and > 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment correctly, > that might allow the driver to be able to use correctly scaled voltages. > > https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > Ah I didn't know those existed, should've checked the bindings in more detail, thanks for the hint! I will have to investigate this carefully, since I don't have access to the actual design of the COM, so I don't know exactly what is there. Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-28 12:42 ` Maud Spierings @ 2025-10-28 13:10 ` Maud Spierings 2025-10-29 7:11 ` Lothar Waßmann 0 siblings, 1 reply; 34+ messages in thread From: Maud Spierings @ 2025-10-28 13:10 UTC (permalink / raw) To: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, LW On 10/28/25 13:42, Maud Spierings wrote: > On 10/28/25 13:15, Matti Vaittinen wrote: >> Hi Maud, >> >> Thanks for the upstreaming work! :) >> >> On 22/10/2025 10:22, Maud Spierings via B4 Relay wrote: >>> From: Maud Spierings <maudspierings@gocontroll.com> >>> >>> The Ka-Ro Electronics tx8m-1610 is a COM based on the imx8mm SOC. It has >>> 1 GB of ram and 4 GB of eMMC storage on board. >>> >>> Add it to enable boards based on this module >>> >>> Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> >>> --- >>> .../arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi | 439 ++++++++++ >>> + ++++++++++ >>> 1 file changed, 439 insertions(+) >>> >>> diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi b/ >>> arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi >>> new file mode 100644 >>> index 0000000000000..46d3ad80942cc >>> --- /dev/null >>> +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610.dtsi >>> @@ -0,0 +1,439 @@ >>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT) >>> +/* >>> + * Copyright (C) 2021 Lothar Waßmann <LW@KARO-electronics.de> >>> + * 2025 Maud Spierings <maudspierings@gocontroll.com> >>> + */ >>> + >>> +#include "imx8mm.dtsi" >>> + >> >> // snip >> >>> + pmic: pmic@4b { >>> + compatible = "rohm,bd71847"; >>> + reg = <0x4b>; >>> + interrupt-parent = <&gpio1>; >>> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; >>> + pinctrl-0 = <&pinctrl_pmic>; >>> + pinctrl-names = "default"; >>> + rohm,reset-snvs-powered; >>> + >>> + regulators { >>> + reg_vdd_soc: BUCK1 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-max-microvolt = <900000>; >>> + regulator-min-microvolt = <780000>; >>> + regulator-name = "buck1"; >>> + regulator-ramp-delay = <1250>; >>> + }; >>> + >>> + reg_vdd_arm: BUCK2 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-max-microvolt = <950000>; >>> + regulator-min-microvolt = <805000>; >>> + regulator-name = "buck2"; >>> + regulator-ramp-delay = <1250>; >>> + rohm,dvs-run-voltage = <950000>; >>> + rohm,dvs-idle-voltage = <810000>; >>> + }; >>> + >>> + reg_vdd_dram: BUCK3 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-max-microvolt = <900000>; >>> + regulator-min-microvolt = <805000>; >>> + regulator-name = "buck3"; >>> + }; >>> + >>> + reg_vdd_3v3: BUCK4 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-max-microvolt = <3300000>; >>> + regulator-min-microvolt = <3300000>; >>> + regulator-name = "buck4"; >>> + }; >>> + >>> + reg_vdd_1v8: BUCK5 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + regulator-max-microvolt = <1950000>; >>> + regulator-min-microvolt = <1700000>; >>> + regulator-name = "buck5"; >>> + }; >>> + >>> + BUCK6 { >>> + regulator-always-on; >>> + regulator-boot-on; >>> + /* >>> + * The default output voltage is 1.1V, bumped >>> + * to 1.35V in HW by a 499R/2.2K voltage divider in the >>> + * feedback path. >>> + */ >> >> Could/Should this be described using the: >> 'rohm,feedback-pull-up-r1-ohms' and >> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >> correctly, that might allow the driver to be able to use correctly >> scaled voltages. >> >> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >> > > Ah I didn't know those existed, should've checked the bindings in more > detail, thanks for the hint! > > I will have to investigate this carefully, since I don't have access to > the actual design of the COM, so I don't know exactly what is there. > So I am not yet entirely sure if this works out, I used the calculation in the driver: /* * Setups where regulator (especially the buck8) output voltage is scaled * by adding external connection where some other regulator output is connected * to feedback-pin (over suitable resistors) is getting popular amongst users * of BD71837. (This allows for example scaling down the buck8 voltages to suit * lover GPU voltages for projects where buck8 is (ab)used to supply power * for GPU. Additionally some setups do allow DVS for buck8 but as this do * produce voltage spikes the HW must be evaluated to be able to survive this * - hence I keep the DVS disabled for non DVS bucks by default. I don't want * to help you burn your proto board) * * So we allow describing this external connection from DT and scale the * voltages accordingly. This is what the connection should look like: * * |------------| * | buck 8 |-------+----->Vout * | | | * |------------| | * | FB pin | * | | * +-------+--R2---+ * | * R1 * | * V FB-pull-up * * Here the buck output is sifted according to formula: * * Vout_o = Vo - (Vpu - Vo)*R2/R1 * Linear_step = step_orig*(R1+R2)/R1 * * where: * Vout_o is adjusted voltage output at vsel reg value 0 * Vo is original voltage output at vsel reg value 0 * Vpu is the pull-up voltage V FB-pull-up in the picture * R1 and R2 are resistor values. * * As a real world example for buck8 and a specific GPU: * VLDO = 1.6V (used as FB-pull-up) * R1 = 1000ohms * R2 = 150ohms * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV */ Because I do not know the pull up voltage, and I am not sure if it is a pull up. So: Vout_o = 1.35V Vo = 1.1V Vpu = unknown R2 = 499 Ohm R1 = 2200 Ohm Gives: Vpu = ~0V And: Vout_o = 1.35V Vo = 1.1V Vpu = unknown R2 = 2200 Ohm R1 = 499 Ohm Gives: Vpu = ~1.04V I am not quite sure which resistor is R1 and which is R2 but having there be a pull down to 0V seems the most logical answer? I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on this setup. Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-28 13:10 ` Maud Spierings @ 2025-10-29 7:11 ` Lothar Waßmann 2025-10-29 8:42 ` Matti Vaittinen 0 siblings, 1 reply; 34+ messages in thread From: Lothar Waßmann @ 2025-10-29 7:11 UTC (permalink / raw) To: Maud Spierings Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi, On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: > On 10/28/25 13:42, Maud Spierings wrote: > > On 10/28/25 13:15, Matti Vaittinen wrote: [...] > >> Could/Should this be described using the: > >> 'rohm,feedback-pull-up-r1-ohms' and > >> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment > >> correctly, that might allow the driver to be able to use correctly > >> scaled voltages. > >> > >> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > >> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > >> > > > > Ah I didn't know those existed, should've checked the bindings in more > > detail, thanks for the hint! > > > > I will have to investigate this carefully, since I don't have access to > > the actual design of the COM, so I don't know exactly what is there. > > > > So I am not yet entirely sure if this works out, I used the calculation > in the driver: > > /* > * Setups where regulator (especially the buck8) output voltage is scaled > * by adding external connection where some other regulator output is > connected > * to feedback-pin (over suitable resistors) is getting popular amongst > users > * of BD71837. (This allows for example scaling down the buck8 voltages > to suit > * lover GPU voltages for projects where buck8 is (ab)used to supply power > * for GPU. Additionally some setups do allow DVS for buck8 but as this do > * produce voltage spikes the HW must be evaluated to be able to > survive this > * - hence I keep the DVS disabled for non DVS bucks by default. I > don't want > * to help you burn your proto board) > * > * So we allow describing this external connection from DT and scale the > * voltages accordingly. This is what the connection should look like: > * > * |------------| > * | buck 8 |-------+----->Vout > * | | | > * |------------| | > * | FB pin | > * | | > * +-------+--R2---+ > * | > * R1 > * | > * V FB-pull-up > * > * Here the buck output is sifted according to formula: > * > * Vout_o = Vo - (Vpu - Vo)*R2/R1 > * Linear_step = step_orig*(R1+R2)/R1 > * > * where: > * Vout_o is adjusted voltage output at vsel reg value 0 > * Vo is original voltage output at vsel reg value 0 > * Vpu is the pull-up voltage V FB-pull-up in the picture > * R1 and R2 are resistor values. > * > * As a real world example for buck8 and a specific GPU: > * VLDO = 1.6V (used as FB-pull-up) > * R1 = 1000ohms > * R2 = 150ohms > * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V > * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV > */ > > Because I do not know the pull up voltage, and I am not sure if it is a > pull up. > > So: > Vout_o = 1.35V > Vo = 1.1V > Vpu = unknown > R2 = 499 Ohm > R1 = 2200 Ohm > Gives: > Vpu = ~0V > > And: > Vout_o = 1.35V > Vo = 1.1V > Vpu = unknown > R2 = 2200 Ohm > R1 = 499 Ohm > Gives: > Vpu = ~1.04V > > I am not quite sure which resistor is R1 and which is R2 but having > there be a pull down to 0V seems the most logical answer? > > I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on > this setup. > R2 is connected to GND, so Vpu = 0. With: regulator-min-microvolt = <1350000>; regulator-max-microvolt = <1350000>; rohm,fb-pull-up-microvolt = <0>; rohm,feedback-pull-up-r1-ohms = <2200>; rohm,feedback-pull-up-r2-ohms = <499>; the correct voltage should be produced on the BUCK8 output, but a quick test with these parameters led to: |failed to get the current voltage: -EINVAL |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register buck6 regulator |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 Apparently noone has ever tested this feature in real life. Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 7:11 ` Lothar Waßmann @ 2025-10-29 8:42 ` Matti Vaittinen 2025-10-29 9:00 ` Maud Spierings 2025-10-29 9:48 ` Lothar Waßmann 0 siblings, 2 replies; 34+ messages in thread From: Matti Vaittinen @ 2025-10-29 8:42 UTC (permalink / raw) To: Lothar Waßmann, Maud Spierings Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 29/10/2025 09:11, Lothar Waßmann wrote: > Hi, > > On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >> On 10/28/25 13:42, Maud Spierings wrote: >>> On 10/28/25 13:15, Matti Vaittinen wrote: > [...] >>>> Could/Should this be described using the: >>>> 'rohm,feedback-pull-up-r1-ohms' and >>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>> correctly, that might allow the driver to be able to use correctly >>>> scaled voltages. >>>> >>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>> >>> >>> Ah I didn't know those existed, should've checked the bindings in more >>> detail, thanks for the hint! >>> >>> I will have to investigate this carefully, since I don't have access to >>> the actual design of the COM, so I don't know exactly what is there. >>> >> >> So I am not yet entirely sure if this works out, I used the calculation >> in the driver: >> >> /* >> * Setups where regulator (especially the buck8) output voltage is scaled >> * by adding external connection where some other regulator output is >> connected >> * to feedback-pin (over suitable resistors) is getting popular amongst >> users >> * of BD71837. (This allows for example scaling down the buck8 voltages >> to suit >> * lover GPU voltages for projects where buck8 is (ab)used to supply power >> * for GPU. Additionally some setups do allow DVS for buck8 but as this do >> * produce voltage spikes the HW must be evaluated to be able to >> survive this >> * - hence I keep the DVS disabled for non DVS bucks by default. I >> don't want >> * to help you burn your proto board) >> * >> * So we allow describing this external connection from DT and scale the >> * voltages accordingly. This is what the connection should look like: >> * >> * |------------| >> * | buck 8 |-------+----->Vout >> * | | | >> * |------------| | >> * | FB pin | >> * | | >> * +-------+--R2---+ >> * | >> * R1 >> * | >> * V FB-pull-up >> * >> * Here the buck output is sifted according to formula: >> * >> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >> * Linear_step = step_orig*(R1+R2)/R1 >> * >> * where: >> * Vout_o is adjusted voltage output at vsel reg value 0 >> * Vo is original voltage output at vsel reg value 0 >> * Vpu is the pull-up voltage V FB-pull-up in the picture >> * R1 and R2 are resistor values. >> * >> * As a real world example for buck8 and a specific GPU: >> * VLDO = 1.6V (used as FB-pull-up) >> * R1 = 1000ohms >> * R2 = 150ohms >> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >> */ >> >> Because I do not know the pull up voltage, and I am not sure if it is a >> pull up. >> >> So: >> Vout_o = 1.35V >> Vo = 1.1V >> Vpu = unknown >> R2 = 499 Ohm >> R1 = 2200 Ohm >> Gives: >> Vpu = ~0V >> >> And: >> Vout_o = 1.35V >> Vo = 1.1V >> Vpu = unknown >> R2 = 2200 Ohm >> R1 = 499 Ohm >> Gives: >> Vpu = ~1.04V >> >> I am not quite sure which resistor is R1 and which is R2 but having >> there be a pull down to 0V seems the most logical answer? >> >> I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on >> this setup. >> > R2 is connected to GND, so Vpu = 0. > With: > regulator-min-microvolt = <1350000>; > regulator-max-microvolt = <1350000>; > rohm,fb-pull-up-microvolt = <0>; > rohm,feedback-pull-up-r1-ohms = <2200>; > rohm,feedback-pull-up-r2-ohms = <499>; > the correct voltage should be produced on the BUCK8 output, but a quick > test with these parameters led to: > |failed to get the current voltage: -EINVAL > |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register buck6 regulator > |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 > > Apparently noone has ever tested this feature in real life. Thanks for trying it out Lothar. I am positive this was tested - but probably the use-case has been using a pull-up. I assume having the zero pull-up voltage causes the driver to calculate some bogus values. I think fixing the computation in the driver might not be that big of a task(?) The benefit of doing it would be that the correct voltages would be calculated by the driver. If real voltages aren't matching what is calculated by the driver, then the voltages requested by regulator consumers will cause wrong voltages to be applied. Debug interfaces will also show wrong voltages, and the safety limits set in the device-tree will not be really respected. I think this would be well worth fixing. Yours, -- Matti > > > Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 8:42 ` Matti Vaittinen @ 2025-10-29 9:00 ` Maud Spierings 2025-10-29 9:33 ` Matti Vaittinen 2025-10-29 9:48 ` Lothar Waßmann 1 sibling, 1 reply; 34+ messages in thread From: Maud Spierings @ 2025-10-29 9:00 UTC (permalink / raw) To: Matti Vaittinen, Lothar Waßmann Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 10/29/25 09:42, Matti Vaittinen wrote: > On 29/10/2025 09:11, Lothar Waßmann wrote: >> Hi, >> >> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>> On 10/28/25 13:42, Maud Spierings wrote: >>>> On 10/28/25 13:15, Matti Vaittinen wrote: >> [...] >>>>> Could/Should this be described using the: >>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>> correctly, that might allow the driver to be able to use correctly >>>>> scaled voltages. >>>>> >>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>> >>>> Ah I didn't know those existed, should've checked the bindings in more >>>> detail, thanks for the hint! >>>> >>>> I will have to investigate this carefully, since I don't have access to >>>> the actual design of the COM, so I don't know exactly what is there. >>> >>> So I am not yet entirely sure if this works out, I used the calculation >>> in the driver: >>> >>> /* >>> * Setups where regulator (especially the buck8) output voltage is >>> scaled >>> * by adding external connection where some other regulator output is >>> connected >>> * to feedback-pin (over suitable resistors) is getting popular >>> amongst >>> users >>> * of BD71837. (This allows for example scaling down the buck8 >>> voltages >>> to suit >>> * lover GPU voltages for projects where buck8 is (ab)used to >>> supply power >>> * for GPU. Additionally some setups do allow DVS for buck8 but as >>> this do >>> * produce voltage spikes the HW must be evaluated to be able to >>> survive this >>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>> don't want >>> * to help you burn your proto board) >>> * >>> * So we allow describing this external connection from DT and >>> scale the >>> * voltages accordingly. This is what the connection should look like: >>> * >>> * |------------| >>> * | buck 8 |-------+----->Vout >>> * | | | >>> * |------------| | >>> * | FB pin | >>> * | | >>> * +-------+--R2---+ >>> * | >>> * R1 >>> * | >>> * V FB-pull-up >>> * >>> * Here the buck output is sifted according to formula: >>> * >>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>> * Linear_step = step_orig*(R1+R2)/R1 >>> * >>> * where: >>> * Vout_o is adjusted voltage output at vsel reg value 0 >>> * Vo is original voltage output at vsel reg value 0 >>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>> * R1 and R2 are resistor values. >>> * >>> * As a real world example for buck8 and a specific GPU: >>> * VLDO = 1.6V (used as FB-pull-up) >>> * R1 = 1000ohms >>> * R2 = 150ohms >>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>> */ >>> >>> Because I do not know the pull up voltage, and I am not sure if it is a >>> pull up. >>> >>> So: >>> Vout_o = 1.35V >>> Vo = 1.1V >>> Vpu = unknown >>> R2 = 499 Ohm >>> R1 = 2200 Ohm >>> Gives: >>> Vpu = ~0V >>> >>> And: >>> Vout_o = 1.35V >>> Vo = 1.1V >>> Vpu = unknown >>> R2 = 2200 Ohm >>> R1 = 499 Ohm >>> Gives: >>> Vpu = ~1.04V >>> >>> I am not quite sure which resistor is R1 and which is R2 but having >>> there be a pull down to 0V seems the most logical answer? >>> >>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on >>> this setup. >>> >> R2 is connected to GND, so Vpu = 0. >> With: >> regulator-min-microvolt = <1350000>; >> regulator-max-microvolt = <1350000>; >> rohm,fb-pull-up-microvolt = <0>; >> rohm,feedback-pull-up-r1-ohms = <2200>; >> rohm,feedback-pull-up-r2-ohms = <499>; >> the correct voltage should be produced on the BUCK8 output, but a quick >> test with these parameters led to: >> |failed to get the current voltage: -EINVAL >> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register >> buck6 regulator >> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >> >> Apparently noone has ever tested this feature in real life. > > Thanks for trying it out Lothar. I am positive this was tested - but > probably the use-case has been using a pull-up. I assume having the zero > pull-up voltage causes the driver to calculate some bogus values. I > think fixing the computation in the driver might not be that big of a > task(?) The benefit of doing it would be that the correct voltages would > be calculated by the driver. > > If real voltages aren't matching what is calculated by the driver, then > the voltages requested by regulator consumers will cause wrong voltages > to be applied. Debug interfaces will also show wrong voltages, and the > safety limits set in the device-tree will not be really respected. > > I think this would be well worth fixing. > Do you intend to do this Matti? Otherwise I will give it a try. Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 9:00 ` Maud Spierings @ 2025-10-29 9:33 ` Matti Vaittinen 0 siblings, 0 replies; 34+ messages in thread From: Matti Vaittinen @ 2025-10-29 9:33 UTC (permalink / raw) To: Maud Spierings, Lothar Waßmann Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 29/10/2025 11:00, Maud Spierings wrote: > > > On 10/29/25 09:42, Matti Vaittinen wrote: >> On 29/10/2025 09:11, Lothar Waßmann wrote: >>> Hi, >>> >>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>> [...] >>>>>> Could/Should this be described using the: >>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>> correctly, that might allow the driver to be able to use correctly >>>>>> scaled voltages. >>>>>> >>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>> >>>>> Ah I didn't know those existed, should've checked the bindings in more >>>>> detail, thanks for the hint! >>>>> >>>>> I will have to investigate this carefully, since I don't have >>>>> access to >>>>> the actual design of the COM, so I don't know exactly what is there. >>>> >>>> So I am not yet entirely sure if this works out, I used the calculation >>>> in the driver: >>>> >>>> /* >>>> * Setups where regulator (especially the buck8) output voltage is >>>> scaled >>>> * by adding external connection where some other regulator output is >>>> connected >>>> * to feedback-pin (over suitable resistors) is getting popular >>>> amongst >>>> users >>>> * of BD71837. (This allows for example scaling down the buck8 >>>> voltages >>>> to suit >>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>> supply power >>>> * for GPU. Additionally some setups do allow DVS for buck8 but as >>>> this do >>>> * produce voltage spikes the HW must be evaluated to be able to >>>> survive this >>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>> don't want >>>> * to help you burn your proto board) >>>> * >>>> * So we allow describing this external connection from DT and >>>> scale the >>>> * voltages accordingly. This is what the connection should look >>>> like: >>>> * >>>> * |------------| >>>> * | buck 8 |-------+----->Vout >>>> * | | | >>>> * |------------| | >>>> * | FB pin | >>>> * | | >>>> * +-------+--R2---+ >>>> * | >>>> * R1 >>>> * | >>>> * V FB-pull-up >>>> * >>>> * Here the buck output is sifted according to formula: >>>> * >>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>> * Linear_step = step_orig*(R1+R2)/R1 >>>> * >>>> * where: >>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>> * Vo is original voltage output at vsel reg value 0 >>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>> * R1 and R2 are resistor values. >>>> * >>>> * As a real world example for buck8 and a specific GPU: >>>> * VLDO = 1.6V (used as FB-pull-up) >>>> * R1 = 1000ohms >>>> * R2 = 150ohms >>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>> */ >>>> >>>> Because I do not know the pull up voltage, and I am not sure if it is a >>>> pull up. >>>> >>>> So: >>>> Vout_o = 1.35V >>>> Vo = 1.1V >>>> Vpu = unknown >>>> R2 = 499 Ohm >>>> R1 = 2200 Ohm >>>> Gives: >>>> Vpu = ~0V >>>> >>>> And: >>>> Vout_o = 1.35V >>>> Vo = 1.1V >>>> Vpu = unknown >>>> R2 = 2200 Ohm >>>> R1 = 499 Ohm >>>> Gives: >>>> Vpu = ~1.04V >>>> >>>> I am not quite sure which resistor is R1 and which is R2 but having >>>> there be a pull down to 0V seems the most logical answer? >>>> >>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on >>>> this setup. >>>> >>> R2 is connected to GND, so Vpu = 0. >>> With: >>> regulator-min-microvolt = <1350000>; >>> regulator-max-microvolt = <1350000>; >>> rohm,fb-pull-up-microvolt = <0>; >>> rohm,feedback-pull-up-r1-ohms = <2200>; >>> rohm,feedback-pull-up-r2-ohms = <499>; >>> the correct voltage should be produced on the BUCK8 output, but a quick >>> test with these parameters led to: >>> |failed to get the current voltage: -EINVAL >>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register >>> buck6 regulator >>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>> >>> Apparently noone has ever tested this feature in real life. >> >> Thanks for trying it out Lothar. I am positive this was tested - but >> probably the use-case has been using a pull-up. I assume having the >> zero pull-up voltage causes the driver to calculate some bogus values. >> I think fixing the computation in the driver might not be that big of >> a task(?) The benefit of doing it would be that the correct voltages >> would be calculated by the driver. >> >> If real voltages aren't matching what is calculated by the driver, >> then the voltages requested by regulator consumers will cause wrong >> voltages to be applied. Debug interfaces will also show wrong >> voltages, and the safety limits set in the device-tree will not be >> really respected. >> >> I think this would be well worth fixing. >> > > Do you intend to do this Matti? > > Otherwise I will give it a try. It would be great if you had the time and enthusiasm to take a look at it! Yours, -- Matti ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 8:42 ` Matti Vaittinen 2025-10-29 9:00 ` Maud Spierings @ 2025-10-29 9:48 ` Lothar Waßmann 2025-10-29 10:05 ` Matti Vaittinen 1 sibling, 1 reply; 34+ messages in thread From: Lothar Waßmann @ 2025-10-29 9:48 UTC (permalink / raw) To: Matti Vaittinen Cc: Maud Spierings, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi, On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: > On 29/10/2025 09:11, Lothar Waßmann wrote: > > Hi, > > > > On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: > >> On 10/28/25 13:42, Maud Spierings wrote: > >>> On 10/28/25 13:15, Matti Vaittinen wrote: > > [...] > >>>> Could/Should this be described using the: > >>>> 'rohm,feedback-pull-up-r1-ohms' and > >>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment > >>>> correctly, that might allow the driver to be able to use correctly > >>>> scaled voltages. > >>>> > >>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > >>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > >>>> > >>> > >>> Ah I didn't know those existed, should've checked the bindings in more > >>> detail, thanks for the hint! > >>> > >>> I will have to investigate this carefully, since I don't have access to > >>> the actual design of the COM, so I don't know exactly what is there. > >>> > >> > >> So I am not yet entirely sure if this works out, I used the calculation > >> in the driver: > >> > >> /* > >> * Setups where regulator (especially the buck8) output voltage is scaled > >> * by adding external connection where some other regulator output is > >> connected > >> * to feedback-pin (over suitable resistors) is getting popular amongst > >> users > >> * of BD71837. (This allows for example scaling down the buck8 voltages > >> to suit > >> * lover GPU voltages for projects where buck8 is (ab)used to supply power > >> * for GPU. Additionally some setups do allow DVS for buck8 but as this do > >> * produce voltage spikes the HW must be evaluated to be able to > >> survive this > >> * - hence I keep the DVS disabled for non DVS bucks by default. I > >> don't want > >> * to help you burn your proto board) > >> * > >> * So we allow describing this external connection from DT and scale the > >> * voltages accordingly. This is what the connection should look like: > >> * > >> * |------------| > >> * | buck 8 |-------+----->Vout > >> * | | | > >> * |------------| | > >> * | FB pin | > >> * | | > >> * +-------+--R2---+ > >> * | > >> * R1 > >> * | > >> * V FB-pull-up > >> * > >> * Here the buck output is sifted according to formula: > >> * > >> * Vout_o = Vo - (Vpu - Vo)*R2/R1 > >> * Linear_step = step_orig*(R1+R2)/R1 > >> * > >> * where: > >> * Vout_o is adjusted voltage output at vsel reg value 0 > >> * Vo is original voltage output at vsel reg value 0 > >> * Vpu is the pull-up voltage V FB-pull-up in the picture > >> * R1 and R2 are resistor values. > >> * > >> * As a real world example for buck8 and a specific GPU: > >> * VLDO = 1.6V (used as FB-pull-up) > >> * R1 = 1000ohms > >> * R2 = 150ohms > >> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V > >> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV > >> */ > >> > >> Because I do not know the pull up voltage, and I am not sure if it is a > >> pull up. > >> > >> So: > >> Vout_o = 1.35V > >> Vo = 1.1V > >> Vpu = unknown > >> R2 = 499 Ohm > >> R1 = 2200 Ohm > >> Gives: > >> Vpu = ~0V > >> > >> And: > >> Vout_o = 1.35V > >> Vo = 1.1V > >> Vpu = unknown > >> R2 = 2200 Ohm > >> R1 = 499 Ohm > >> Gives: > >> Vpu = ~1.04V > >> > >> I am not quite sure which resistor is R1 and which is R2 but having > >> there be a pull down to 0V seems the most logical answer? > >> > >> I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on > >> this setup. > >> > > R2 is connected to GND, so Vpu = 0. > > With: > > regulator-min-microvolt = <1350000>; > > regulator-max-microvolt = <1350000>; > > rohm,fb-pull-up-microvolt = <0>; > > rohm,feedback-pull-up-r1-ohms = <2200>; > > rohm,feedback-pull-up-r2-ohms = <499>; > > the correct voltage should be produced on the BUCK8 output, but a quick > > test with these parameters led to: > > |failed to get the current voltage: -EINVAL > > |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register buck6 regulator > > |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 > > > > Apparently noone has ever tested this feature in real life. > > Thanks for trying it out Lothar. I am positive this was tested - but > probably the use-case has been using a pull-up. I assume having the zero > pull-up voltage causes the driver to calculate some bogus values. I > think fixing the computation in the driver might not be that big of a > task(?) The benefit of doing it would be that the correct voltages would > be calculated by the driver. > > If real voltages aren't matching what is calculated by the driver, then > the voltages requested by regulator consumers will cause wrong voltages > to be applied. Debug interfaces will also show wrong voltages, and the > safety limits set in the device-tree will not be really respected. > > I think this would be well worth fixing. > Before doing the real-life test I did the same calculation that's done in the driver to be sure that it will generate the correct values: bc 1.07.1 Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. fb_uv=0 r1=2200 r2=499 min=800000 step=10000 # default voltage without divider min+30*step 1100000 min=min-(fb_uv-min)*r2/r1 step=step*(r1+r2)/r1 min 981454 step 12268 # default voltage with divider min+30*step 1349494 Probably we need to use this value rather than the nominal 135000 as the target voltage in the DTB. Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 9:48 ` Lothar Waßmann @ 2025-10-29 10:05 ` Matti Vaittinen 2025-10-29 15:35 ` Maud Spierings 0 siblings, 1 reply; 34+ messages in thread From: Matti Vaittinen @ 2025-10-29 10:05 UTC (permalink / raw) To: Lothar Waßmann Cc: Maud Spierings, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 29/10/2025 11:48, Lothar Waßmann wrote: > Hi, > > On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >> On 29/10/2025 09:11, Lothar Waßmann wrote: >>> Hi, >>> >>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>> [...] >>>>>> Could/Should this be described using the: >>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>> correctly, that might allow the driver to be able to use correctly >>>>>> scaled voltages. >>>>>> >>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>> >>>>> >>>>> Ah I didn't know those existed, should've checked the bindings in more >>>>> detail, thanks for the hint! >>>>> >>>>> I will have to investigate this carefully, since I don't have access to >>>>> the actual design of the COM, so I don't know exactly what is there. >>>>> >>>> >>>> So I am not yet entirely sure if this works out, I used the calculation >>>> in the driver: >>>> >>>> /* >>>> * Setups where regulator (especially the buck8) output voltage is scaled >>>> * by adding external connection where some other regulator output is >>>> connected >>>> * to feedback-pin (over suitable resistors) is getting popular amongst >>>> users >>>> * of BD71837. (This allows for example scaling down the buck8 voltages >>>> to suit >>>> * lover GPU voltages for projects where buck8 is (ab)used to supply power >>>> * for GPU. Additionally some setups do allow DVS for buck8 but as this do >>>> * produce voltage spikes the HW must be evaluated to be able to >>>> survive this >>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>> don't want >>>> * to help you burn your proto board) >>>> * >>>> * So we allow describing this external connection from DT and scale the >>>> * voltages accordingly. This is what the connection should look like: >>>> * >>>> * |------------| >>>> * | buck 8 |-------+----->Vout >>>> * | | | >>>> * |------------| | >>>> * | FB pin | >>>> * | | >>>> * +-------+--R2---+ >>>> * | >>>> * R1 >>>> * | >>>> * V FB-pull-up >>>> * >>>> * Here the buck output is sifted according to formula: >>>> * >>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>> * Linear_step = step_orig*(R1+R2)/R1 >>>> * >>>> * where: >>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>> * Vo is original voltage output at vsel reg value 0 >>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>> * R1 and R2 are resistor values. >>>> * >>>> * As a real world example for buck8 and a specific GPU: >>>> * VLDO = 1.6V (used as FB-pull-up) >>>> * R1 = 1000ohms >>>> * R2 = 150ohms >>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>> */ >>>> >>>> Because I do not know the pull up voltage, and I am not sure if it is a >>>> pull up. >>>> >>>> So: >>>> Vout_o = 1.35V >>>> Vo = 1.1V >>>> Vpu = unknown >>>> R2 = 499 Ohm >>>> R1 = 2200 Ohm >>>> Gives: >>>> Vpu = ~0V >>>> >>>> And: >>>> Vout_o = 1.35V >>>> Vo = 1.1V >>>> Vpu = unknown >>>> R2 = 2200 Ohm >>>> R1 = 499 Ohm >>>> Gives: >>>> Vpu = ~1.04V >>>> >>>> I am not quite sure which resistor is R1 and which is R2 but having >>>> there be a pull down to 0V seems the most logical answer? >>>> >>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some light on >>>> this setup. >>>> >>> R2 is connected to GND, so Vpu = 0. >>> With: >>> regulator-min-microvolt = <1350000>; >>> regulator-max-microvolt = <1350000>; >>> rohm,fb-pull-up-microvolt = <0>; >>> rohm,feedback-pull-up-r1-ohms = <2200>; >>> rohm,feedback-pull-up-r2-ohms = <499>; >>> the correct voltage should be produced on the BUCK8 output, but a quick >>> test with these parameters led to: >>> |failed to get the current voltage: -EINVAL >>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register buck6 regulator >>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>> >>> Apparently noone has ever tested this feature in real life. >> >> Thanks for trying it out Lothar. I am positive this was tested - but >> probably the use-case has been using a pull-up. I assume having the zero >> pull-up voltage causes the driver to calculate some bogus values. I >> think fixing the computation in the driver might not be that big of a >> task(?) The benefit of doing it would be that the correct voltages would >> be calculated by the driver. >> >> If real voltages aren't matching what is calculated by the driver, then >> the voltages requested by regulator consumers will cause wrong voltages >> to be applied. Debug interfaces will also show wrong voltages, and the >> safety limits set in the device-tree will not be really respected. >> >> I think this would be well worth fixing. >> > Before doing the real-life test I did the same calculation that's done > in the driver to be sure that it will generate the correct values: > bc 1.07.1 > Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc. > This is free software with ABSOLUTELY NO WARRANTY. > For details type `warranty'. > fb_uv=0 > r1=2200 > r2=499 > min=800000 > step=10000 > # default voltage without divider > min+30*step > 1100000 > min=min-(fb_uv-min)*r2/r1 > step=step*(r1+r2)/r1 > min > 981454 > step > 12268 > # default voltage with divider > min+30*step > 1349494 > > Probably we need to use this value rather than the nominal 135000 as > the target voltage in the DTB. Yes. When the driver calculates the voltages which match the actual voltages, then you should also use the actual voltages in the device-tree. Yours, -- Matti > > > Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 10:05 ` Matti Vaittinen @ 2025-10-29 15:35 ` Maud Spierings 2025-10-29 15:51 ` Maud Spierings 2025-10-30 8:54 ` Lothar Waßmann 0 siblings, 2 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-29 15:35 UTC (permalink / raw) To: Matti Vaittinen, Lothar Waßmann Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi Matti, On 10/29/25 11:05, Matti Vaittinen wrote: > On 29/10/2025 11:48, Lothar Waßmann wrote: >> Hi, >> >> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>> Hi, >>>> >>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>> [...] >>>>>>> Could/Should this be described using the: >>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>> scaled voltages. >>>>>>> >>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>> >>>>>> Ah I didn't know those existed, should've checked the bindings in >>>>>> more >>>>>> detail, thanks for the hint! >>>>>> >>>>>> I will have to investigate this carefully, since I don't have >>>>>> access to >>>>>> the actual design of the COM, so I don't know exactly what is there. >>>>> >>>>> So I am not yet entirely sure if this works out, I used the >>>>> calculation >>>>> in the driver: >>>>> >>>>> /* >>>>> * Setups where regulator (especially the buck8) output voltage >>>>> is scaled >>>>> * by adding external connection where some other regulator >>>>> output is >>>>> connected >>>>> * to feedback-pin (over suitable resistors) is getting popular >>>>> amongst >>>>> users >>>>> * of BD71837. (This allows for example scaling down the buck8 >>>>> voltages >>>>> to suit >>>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>>> supply power >>>>> * for GPU. Additionally some setups do allow DVS for buck8 but >>>>> as this do >>>>> * produce voltage spikes the HW must be evaluated to be able to >>>>> survive this >>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>>> don't want >>>>> * to help you burn your proto board) >>>>> * >>>>> * So we allow describing this external connection from DT and >>>>> scale the >>>>> * voltages accordingly. This is what the connection should look >>>>> like: >>>>> * >>>>> * |------------| >>>>> * | buck 8 |-------+----->Vout >>>>> * | | | >>>>> * |------------| | >>>>> * | FB pin | >>>>> * | | >>>>> * +-------+--R2---+ >>>>> * | >>>>> * R1 >>>>> * | >>>>> * V FB-pull-up >>>>> * >>>>> * Here the buck output is sifted according to formula: >>>>> * >>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>>> * Linear_step = step_orig*(R1+R2)/R1 >>>>> * >>>>> * where: >>>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>>> * Vo is original voltage output at vsel reg value 0 >>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>>> * R1 and R2 are resistor values. >>>>> * >>>>> * As a real world example for buck8 and a specific GPU: >>>>> * VLDO = 1.6V (used as FB-pull-up) >>>>> * R1 = 1000ohms >>>>> * R2 = 150ohms >>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>>> */ >>>>> >>>>> Because I do not know the pull up voltage, and I am not sure if it >>>>> is a >>>>> pull up. >>>>> >>>>> So: >>>>> Vout_o = 1.35V >>>>> Vo = 1.1V >>>>> Vpu = unknown >>>>> R2 = 499 Ohm >>>>> R1 = 2200 Ohm >>>>> Gives: >>>>> Vpu = ~0V >>>>> >>>>> And: >>>>> Vout_o = 1.35V >>>>> Vo = 1.1V >>>>> Vpu = unknown >>>>> R2 = 2200 Ohm >>>>> R1 = 499 Ohm >>>>> Gives: >>>>> Vpu = ~1.04V >>>>> >>>>> I am not quite sure which resistor is R1 and which is R2 but having >>>>> there be a pull down to 0V seems the most logical answer? >>>>> >>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some >>>>> light on >>>>> this setup. >>>> R2 is connected to GND, so Vpu = 0. >>>> With: >>>> regulator-min-microvolt = <1350000>; >>>> regulator-max-microvolt = <1350000>; >>>> rohm,fb-pull-up-microvolt = <0>; >>>> rohm,feedback-pull-up-r1-ohms = <2200>; >>>> rohm,feedback-pull-up-r2-ohms = <499>; >>>> the correct voltage should be produced on the BUCK8 output, but a quick >>>> test with these parameters led to: >>>> |failed to get the current voltage: -EINVAL >>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register >>>> buck6 regulator >>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>>> >>>> Apparently noone has ever tested this feature in real life. >>> >>> Thanks for trying it out Lothar. I am positive this was tested - but >>> probably the use-case has been using a pull-up. I assume having the zero >>> pull-up voltage causes the driver to calculate some bogus values. I >>> think fixing the computation in the driver might not be that big of a >>> task(?) The benefit of doing it would be that the correct voltages would >>> be calculated by the driver. >>> >>> If real voltages aren't matching what is calculated by the driver, then >>> the voltages requested by regulator consumers will cause wrong voltages >>> to be applied. Debug interfaces will also show wrong voltages, and the >>> safety limits set in the device-tree will not be really respected. >>> >>> I think this would be well worth fixing. >>> >> Before doing the real-life test I did the same calculation that's done >> in the driver to be sure that it will generate the correct values: >> bc 1.07.1 >> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >> Free Software Foundation, Inc. >> This is free software with ABSOLUTELY NO WARRANTY. >> For details type `warranty'. >> fb_uv=0 >> r1=2200 >> r2=499 >> min=800000 >> step=10000 >> # default voltage without divider >> min+30*step >> 1100000 >> min=min-(fb_uv-min)*r2/r1 >> step=step*(r1+r2)/r1 >> min >> 981454 >> step >> 12268 >> # default voltage with divider >> min+30*step >> 1349494 >> >> Probably we need to use this value rather than the nominal 135000 as >> the target voltage in the DTB. > > Yes. When the driver calculates the voltages which match the actual > voltages, then you should also use the actual voltages in the device-tree. > Think I've got it: diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/bd718x7-regulator.c index 022d98f3c32a2..ea9c4058ee6a5 100644 --- a/drivers/regulator/bd718x7-regulator.c +++ b/drivers/regulator/bd718x7-regulator.c @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, struct device_node *np, step /= r1; new[j].min = min; + new[j].min_sel = desc->linear_ranges[j].min_sel; + new[j].max_sel = desc->linear_ranges[j].max_sel; new[j].step = step; dev_dbg(dev, "%s: old range min %d, step %d\n", the min_sel and max_sel fields were uninitialized in the new linear_range, copying them over from the old one (they refer to the register range if I understand correctly so they should not change) initializes them. Then setting 1349494 as the actual voltage makes it fully work. Otherwise it complains: buck6: failed to apply 1350000-1350000uV constraint: -EINVAL Final debug output now: [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up configured I will add this fix to the next version of this patchset and include your requested change in the dts. Kind regards, Maud ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 15:35 ` Maud Spierings @ 2025-10-29 15:51 ` Maud Spierings 2025-10-29 19:04 ` Matti Vaittinen 2025-10-30 8:54 ` Lothar Waßmann 1 sibling, 1 reply; 34+ messages in thread From: Maud Spierings @ 2025-10-29 15:51 UTC (permalink / raw) To: Matti Vaittinen, Lothar Waßmann Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 10/29/25 16:35, Maud Spierings wrote: > Hi Matti, > > On 10/29/25 11:05, Matti Vaittinen wrote: >> On 29/10/2025 11:48, Lothar Waßmann wrote: >>> Hi, >>> >>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>> Hi, >>>>> >>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>> [...] >>>>>>>> Could/Should this be described using the: >>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>> scaled voltages. >>>>>>>> >>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>> >>>>>>> Ah I didn't know those existed, should've checked the bindings in >>>>>>> more >>>>>>> detail, thanks for the hint! >>>>>>> >>>>>>> I will have to investigate this carefully, since I don't have >>>>>>> access to >>>>>>> the actual design of the COM, so I don't know exactly what is there. >>>>>> >>>>>> So I am not yet entirely sure if this works out, I used the >>>>>> calculation >>>>>> in the driver: >>>>>> >>>>>> /* >>>>>> * Setups where regulator (especially the buck8) output voltage >>>>>> is scaled >>>>>> * by adding external connection where some other regulator >>>>>> output is >>>>>> connected >>>>>> * to feedback-pin (over suitable resistors) is getting popular >>>>>> amongst >>>>>> users >>>>>> * of BD71837. (This allows for example scaling down the buck8 >>>>>> voltages >>>>>> to suit >>>>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>>>> supply power >>>>>> * for GPU. Additionally some setups do allow DVS for buck8 but >>>>>> as this do >>>>>> * produce voltage spikes the HW must be evaluated to be able to >>>>>> survive this >>>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>>>> don't want >>>>>> * to help you burn your proto board) >>>>>> * >>>>>> * So we allow describing this external connection from DT and >>>>>> scale the >>>>>> * voltages accordingly. This is what the connection should >>>>>> look like: >>>>>> * >>>>>> * |------------| >>>>>> * | buck 8 |-------+----->Vout >>>>>> * | | | >>>>>> * |------------| | >>>>>> * | FB pin | >>>>>> * | | >>>>>> * +-------+--R2---+ >>>>>> * | >>>>>> * R1 >>>>>> * | >>>>>> * V FB-pull-up >>>>>> * >>>>>> * Here the buck output is sifted according to formula: >>>>>> * >>>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>>>> * Linear_step = step_orig*(R1+R2)/R1 >>>>>> * >>>>>> * where: >>>>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>>>> * Vo is original voltage output at vsel reg value 0 >>>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>>>> * R1 and R2 are resistor values. >>>>>> * >>>>>> * As a real world example for buck8 and a specific GPU: >>>>>> * VLDO = 1.6V (used as FB-pull-up) >>>>>> * R1 = 1000ohms >>>>>> * R2 = 150ohms >>>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>>>> */ >>>>>> >>>>>> Because I do not know the pull up voltage, and I am not sure if it >>>>>> is a >>>>>> pull up. >>>>>> >>>>>> So: >>>>>> Vout_o = 1.35V >>>>>> Vo = 1.1V >>>>>> Vpu = unknown >>>>>> R2 = 499 Ohm >>>>>> R1 = 2200 Ohm >>>>>> Gives: >>>>>> Vpu = ~0V >>>>>> >>>>>> And: >>>>>> Vout_o = 1.35V >>>>>> Vo = 1.1V >>>>>> Vpu = unknown >>>>>> R2 = 2200 Ohm >>>>>> R1 = 499 Ohm >>>>>> Gives: >>>>>> Vpu = ~1.04V >>>>>> >>>>>> I am not quite sure which resistor is R1 and which is R2 but having >>>>>> there be a pull down to 0V seems the most logical answer? >>>>>> >>>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some >>>>>> light on >>>>>> this setup. >>>>> R2 is connected to GND, so Vpu = 0. >>>>> With: >>>>> regulator-min-microvolt = <1350000>; >>>>> regulator-max-microvolt = <1350000>; >>>>> rohm,fb-pull-up-microvolt = <0>; >>>>> rohm,feedback-pull-up-r1-ohms = <2200>; >>>>> rohm,feedback-pull-up-r2-ohms = <499>; >>>>> the correct voltage should be produced on the BUCK8 output, but a >>>>> quick >>>>> test with these parameters led to: >>>>> |failed to get the current voltage: -EINVAL >>>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to >>>>> register buck6 regulator >>>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>>>> >>>>> Apparently noone has ever tested this feature in real life. >>>> >>>> Thanks for trying it out Lothar. I am positive this was tested - but >>>> probably the use-case has been using a pull-up. I assume having the >>>> zero >>>> pull-up voltage causes the driver to calculate some bogus values. I >>>> think fixing the computation in the driver might not be that big of a >>>> task(?) The benefit of doing it would be that the correct voltages >>>> would >>>> be calculated by the driver. >>>> >>>> If real voltages aren't matching what is calculated by the driver, then >>>> the voltages requested by regulator consumers will cause wrong voltages >>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>> safety limits set in the device-tree will not be really respected. >>>> >>>> I think this would be well worth fixing. >>>> >>> Before doing the real-life test I did the same calculation that's done >>> in the driver to be sure that it will generate the correct values: >>> bc 1.07.1 >>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>> Free Software Foundation, Inc. >>> This is free software with ABSOLUTELY NO WARRANTY. >>> For details type `warranty'. >>> fb_uv=0 >>> r1=2200 >>> r2=499 >>> min=800000 >>> step=10000 >>> # default voltage without divider >>> min+30*step >>> 1100000 >>> min=min-(fb_uv-min)*r2/r1 >>> step=step*(r1+r2)/r1 >>> min >>> 981454 >>> step >>> 12268 >>> # default voltage with divider >>> min+30*step >>> 1349494 >>> >>> Probably we need to use this value rather than the nominal 135000 as >>> the target voltage in the DTB. >> >> Yes. When the driver calculates the voltages which match the actual >> voltages, then you should also use the actual voltages in the device- >> tree. >> > > Think I've got it: > > diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/ > bd718x7-regulator.c > index 022d98f3c32a2..ea9c4058ee6a5 100644 > --- a/drivers/regulator/bd718x7-regulator.c > +++ b/drivers/regulator/bd718x7-regulator.c > @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, > struct device_node *np, > step /= r1; > > new[j].min = min; > + new[j].min_sel = desc- > >linear_ranges[j].min_sel; > + new[j].max_sel = desc- > >linear_ranges[j].max_sel; > new[j].step = step; > > dev_dbg(dev, "%s: old range min %d, > step %d\n", > > > the min_sel and max_sel fields were uninitialized in the new > linear_range, copying them over from the old one (they refer to the > register range if I understand correctly so they should not change) > initializes them. > > Then setting 1349494 as the actual voltage makes it fully work. > Otherwise it complains: > buck6: failed to apply 1350000-1350000uV constraint: -EINVAL > > Final debug output now: > [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 > [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 > [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up > configured > > I will add this fix to the next version of this patchset and include > your requested change in the dts. New idea, why don't we just change the values of the original linear_range? Do away with the allocation there entirely. Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 15:51 ` Maud Spierings @ 2025-10-29 19:04 ` Matti Vaittinen 0 siblings, 0 replies; 34+ messages in thread From: Matti Vaittinen @ 2025-10-29 19:04 UTC (permalink / raw) To: Maud Spierings, Lothar Waßmann Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 29/10/2025 17:51, Maud Spierings wrote: > > > On 10/29/25 16:35, Maud Spierings wrote: >> Hi Matti, >> >> On 10/29/25 11:05, Matti Vaittinen wrote: >>> On 29/10/2025 11:48, Lothar Waßmann wrote: >>>> Hi, >>>> >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>>> [...] >>>>>>>>> Could/Should this be described using the: >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>>> scaled voltages. >>>>>>>>> >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>>> >>>>>>>> Ah I didn't know those existed, should've checked the bindings >>>>>>>> in more >>>>>>>> detail, thanks for the hint! >>>>>>>> >>>>>>>> I will have to investigate this carefully, since I don't have >>>>>>>> access to >>>>>>>> the actual design of the COM, so I don't know exactly what is >>>>>>>> there. >>>>>>> >>>>>>> So I am not yet entirely sure if this works out, I used the >>>>>>> calculation >>>>>>> in the driver: >>>>>>> >>>>>>> /* >>>>>>> * Setups where regulator (especially the buck8) output >>>>>>> voltage is scaled >>>>>>> * by adding external connection where some other regulator >>>>>>> output is >>>>>>> connected >>>>>>> * to feedback-pin (over suitable resistors) is getting >>>>>>> popular amongst >>>>>>> users >>>>>>> * of BD71837. (This allows for example scaling down the buck8 >>>>>>> voltages >>>>>>> to suit >>>>>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>>>>> supply power >>>>>>> * for GPU. Additionally some setups do allow DVS for buck8 >>>>>>> but as this do >>>>>>> * produce voltage spikes the HW must be evaluated to be able to >>>>>>> survive this >>>>>>> * - hence I keep the DVS disabled for non DVS bucks by >>>>>>> default. I >>>>>>> don't want >>>>>>> * to help you burn your proto board) >>>>>>> * >>>>>>> * So we allow describing this external connection from DT and >>>>>>> scale the >>>>>>> * voltages accordingly. This is what the connection should >>>>>>> look like: >>>>>>> * >>>>>>> * |------------| >>>>>>> * | buck 8 |-------+----->Vout >>>>>>> * | | | >>>>>>> * |------------| | >>>>>>> * | FB pin | >>>>>>> * | | >>>>>>> * +-------+--R2---+ >>>>>>> * | >>>>>>> * R1 >>>>>>> * | >>>>>>> * V FB-pull-up >>>>>>> * >>>>>>> * Here the buck output is sifted according to formula: >>>>>>> * >>>>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>>>>> * Linear_step = step_orig*(R1+R2)/R1 >>>>>>> * >>>>>>> * where: >>>>>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>>>>> * Vo is original voltage output at vsel reg value 0 >>>>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>>>>> * R1 and R2 are resistor values. >>>>>>> * >>>>>>> * As a real world example for buck8 and a specific GPU: >>>>>>> * VLDO = 1.6V (used as FB-pull-up) >>>>>>> * R1 = 1000ohms >>>>>>> * R2 = 150ohms >>>>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>>>>> */ >>>>>>> >>>>>>> Because I do not know the pull up voltage, and I am not sure if >>>>>>> it is a >>>>>>> pull up. >>>>>>> >>>>>>> So: >>>>>>> Vout_o = 1.35V >>>>>>> Vo = 1.1V >>>>>>> Vpu = unknown >>>>>>> R2 = 499 Ohm >>>>>>> R1 = 2200 Ohm >>>>>>> Gives: >>>>>>> Vpu = ~0V >>>>>>> >>>>>>> And: >>>>>>> Vout_o = 1.35V >>>>>>> Vo = 1.1V >>>>>>> Vpu = unknown >>>>>>> R2 = 2200 Ohm >>>>>>> R1 = 499 Ohm >>>>>>> Gives: >>>>>>> Vpu = ~1.04V >>>>>>> >>>>>>> I am not quite sure which resistor is R1 and which is R2 but having >>>>>>> there be a pull down to 0V seems the most logical answer? >>>>>>> >>>>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some >>>>>>> light on >>>>>>> this setup. >>>>>> R2 is connected to GND, so Vpu = 0. >>>>>> With: >>>>>> regulator-min-microvolt = <1350000>; >>>>>> regulator-max-microvolt = <1350000>; >>>>>> rohm,fb-pull-up-microvolt = <0>; >>>>>> rohm,feedback-pull-up-r1-ohms = <2200>; >>>>>> rohm,feedback-pull-up-r2-ohms = <499>; >>>>>> the correct voltage should be produced on the BUCK8 output, but a >>>>>> quick >>>>>> test with these parameters led to: >>>>>> |failed to get the current voltage: -EINVAL >>>>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to >>>>>> register buck6 regulator >>>>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>>>>> >>>>>> Apparently noone has ever tested this feature in real life. >>>>> >>>>> Thanks for trying it out Lothar. I am positive this was tested - but >>>>> probably the use-case has been using a pull-up. I assume having the >>>>> zero >>>>> pull-up voltage causes the driver to calculate some bogus values. I >>>>> think fixing the computation in the driver might not be that big of a >>>>> task(?) The benefit of doing it would be that the correct voltages >>>>> would >>>>> be calculated by the driver. >>>>> >>>>> If real voltages aren't matching what is calculated by the driver, >>>>> then >>>>> the voltages requested by regulator consumers will cause wrong >>>>> voltages >>>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>>> safety limits set in the device-tree will not be really respected. >>>>> >>>>> I think this would be well worth fixing. >>>>> >>>> Before doing the real-life test I did the same calculation that's done >>>> in the driver to be sure that it will generate the correct values: >>>> bc 1.07.1 >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>>> Free Software Foundation, Inc. >>>> This is free software with ABSOLUTELY NO WARRANTY. >>>> For details type `warranty'. >>>> fb_uv=0 >>>> r1=2200 >>>> r2=499 >>>> min=800000 >>>> step=10000 >>>> # default voltage without divider >>>> min+30*step >>>> 1100000 >>>> min=min-(fb_uv-min)*r2/r1 >>>> step=step*(r1+r2)/r1 >>>> min >>>> 981454 >>>> step >>>> 12268 >>>> # default voltage with divider >>>> min+30*step >>>> 1349494 >>>> >>>> Probably we need to use this value rather than the nominal 135000 as >>>> the target voltage in the DTB. >>> >>> Yes. When the driver calculates the voltages which match the actual >>> voltages, then you should also use the actual voltages in the device- >>> tree. >>> >> >> Think I've got it: >> >> diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/ >> regulator/ bd718x7-regulator.c >> index 022d98f3c32a2..ea9c4058ee6a5 100644 >> --- a/drivers/regulator/bd718x7-regulator.c >> +++ b/drivers/regulator/bd718x7-regulator.c >> @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device >> *dev, struct device_node *np, >> step /= r1; >> >> new[j].min = min; >> + new[j].min_sel = desc- >> >linear_ranges[j].min_sel; >> + new[j].max_sel = desc- >> >linear_ranges[j].max_sel; >> new[j].step = step; >> >> dev_dbg(dev, "%s: old range min %d, >> step %d\n", >> >> >> the min_sel and max_sel fields were uninitialized in the new >> linear_range, copying them over from the old one (they refer to the >> register range if I understand correctly so they should not change) >> initializes them. Ah, indeed. Well spotted! Thanks for debugging it :) >> Then setting 1349494 as the actual voltage makes it fully work. >> Otherwise it complains: >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL >> >> Final debug output now: >> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step >> 10000 >> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 >> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up >> configured >> >> I will add this fix to the next version of this patchset and include >> your requested change in the dts. > > New idea, why don't we just change the values of the original > linear_range? Do away with the allocation there entirely. I kind of like to keep the global structs const, and allocate new memory for anything we need to change. That should help us if we ever need to support more than 1 instance of the driver (Eg, on a system with multiple PMICs) - although that's not likely, and AFAIR, the driver is currently not written to work in such use-case. Anyways, the selectors won't change when voltage gets scaled. Maybe just allocate with kmemdup, update the min and step, and be done with it(?) Well, hard to say what's the best approach without seeing it :) I'd suggest you consider what you think is the best solution, write a patch and let's see how it looks like (and, at the end of the day, what Mark thinks of it).Yours, -- Matti ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-29 15:35 ` Maud Spierings 2025-10-29 15:51 ` Maud Spierings @ 2025-10-30 8:54 ` Lothar Waßmann 2025-10-30 11:01 ` Matti Vaittinen 2025-10-30 14:45 ` Maud Spierings 1 sibling, 2 replies; 34+ messages in thread From: Lothar Waßmann @ 2025-10-30 8:54 UTC (permalink / raw) To: Maud Spierings Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi, On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: > Hi Matti, > > On 10/29/25 11:05, Matti Vaittinen wrote: > > On 29/10/2025 11:48, Lothar Waßmann wrote: > >> Hi, > >> > >> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: > >>> On 29/10/2025 09:11, Lothar Waßmann wrote: > >>>> Hi, > >>>> > >>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: > >>>>> On 10/28/25 13:42, Maud Spierings wrote: > >>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: > >>>> [...] > >>>>>>> Could/Should this be described using the: > >>>>>>> 'rohm,feedback-pull-up-r1-ohms' and > >>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment > >>>>>>> correctly, that might allow the driver to be able to use correctly > >>>>>>> scaled voltages. > >>>>>>> > >>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > >>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > >>>>>> > >>>>>> Ah I didn't know those existed, should've checked the bindings in > >>>>>> more > >>>>>> detail, thanks for the hint! > >>>>>> > >>>>>> I will have to investigate this carefully, since I don't have > >>>>>> access to > >>>>>> the actual design of the COM, so I don't know exactly what is there. > >>>>> > >>>>> So I am not yet entirely sure if this works out, I used the > >>>>> calculation > >>>>> in the driver: > >>>>> > >>>>> /* > >>>>> * Setups where regulator (especially the buck8) output voltage > >>>>> is scaled > >>>>> * by adding external connection where some other regulator > >>>>> output is > >>>>> connected > >>>>> * to feedback-pin (over suitable resistors) is getting popular > >>>>> amongst > >>>>> users > >>>>> * of BD71837. (This allows for example scaling down the buck8 > >>>>> voltages > >>>>> to suit > >>>>> * lover GPU voltages for projects where buck8 is (ab)used to > >>>>> supply power > >>>>> * for GPU. Additionally some setups do allow DVS for buck8 but > >>>>> as this do > >>>>> * produce voltage spikes the HW must be evaluated to be able to > >>>>> survive this > >>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I > >>>>> don't want > >>>>> * to help you burn your proto board) > >>>>> * > >>>>> * So we allow describing this external connection from DT and > >>>>> scale the > >>>>> * voltages accordingly. This is what the connection should look > >>>>> like: > >>>>> * > >>>>> * |------------| > >>>>> * | buck 8 |-------+----->Vout > >>>>> * | | | > >>>>> * |------------| | > >>>>> * | FB pin | > >>>>> * | | > >>>>> * +-------+--R2---+ > >>>>> * | > >>>>> * R1 > >>>>> * | > >>>>> * V FB-pull-up > >>>>> * > >>>>> * Here the buck output is sifted according to formula: > >>>>> * > >>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 > >>>>> * Linear_step = step_orig*(R1+R2)/R1 > >>>>> * > >>>>> * where: > >>>>> * Vout_o is adjusted voltage output at vsel reg value 0 > >>>>> * Vo is original voltage output at vsel reg value 0 > >>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture > >>>>> * R1 and R2 are resistor values. > >>>>> * > >>>>> * As a real world example for buck8 and a specific GPU: > >>>>> * VLDO = 1.6V (used as FB-pull-up) > >>>>> * R1 = 1000ohms > >>>>> * R2 = 150ohms > >>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V > >>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV > >>>>> */ > >>>>> > >>>>> Because I do not know the pull up voltage, and I am not sure if it > >>>>> is a > >>>>> pull up. > >>>>> > >>>>> So: > >>>>> Vout_o = 1.35V > >>>>> Vo = 1.1V > >>>>> Vpu = unknown > >>>>> R2 = 499 Ohm > >>>>> R1 = 2200 Ohm > >>>>> Gives: > >>>>> Vpu = ~0V > >>>>> > >>>>> And: > >>>>> Vout_o = 1.35V > >>>>> Vo = 1.1V > >>>>> Vpu = unknown > >>>>> R2 = 2200 Ohm > >>>>> R1 = 499 Ohm > >>>>> Gives: > >>>>> Vpu = ~1.04V > >>>>> > >>>>> I am not quite sure which resistor is R1 and which is R2 but having > >>>>> there be a pull down to 0V seems the most logical answer? > >>>>> > >>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some > >>>>> light on > >>>>> this setup. > >>>> R2 is connected to GND, so Vpu = 0. > >>>> With: > >>>> regulator-min-microvolt = <1350000>; > >>>> regulator-max-microvolt = <1350000>; > >>>> rohm,fb-pull-up-microvolt = <0>; > >>>> rohm,feedback-pull-up-r1-ohms = <2200>; > >>>> rohm,feedback-pull-up-r2-ohms = <499>; > >>>> the correct voltage should be produced on the BUCK8 output, but a quick > >>>> test with these parameters led to: > >>>> |failed to get the current voltage: -EINVAL > >>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register > >>>> buck6 regulator > >>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 > >>>> > >>>> Apparently noone has ever tested this feature in real life. > >>> > >>> Thanks for trying it out Lothar. I am positive this was tested - but > >>> probably the use-case has been using a pull-up. I assume having the zero > >>> pull-up voltage causes the driver to calculate some bogus values. I > >>> think fixing the computation in the driver might not be that big of a > >>> task(?) The benefit of doing it would be that the correct voltages would > >>> be calculated by the driver. > >>> > >>> If real voltages aren't matching what is calculated by the driver, then > >>> the voltages requested by regulator consumers will cause wrong voltages > >>> to be applied. Debug interfaces will also show wrong voltages, and the > >>> safety limits set in the device-tree will not be really respected. > >>> > >>> I think this would be well worth fixing. > >>> > >> Before doing the real-life test I did the same calculation that's done > >> in the driver to be sure that it will generate the correct values: > >> bc 1.07.1 > >> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 > >> Free Software Foundation, Inc. > >> This is free software with ABSOLUTELY NO WARRANTY. > >> For details type `warranty'. > >> fb_uv=0 > >> r1=2200 > >> r2=499 > >> min=800000 > >> step=10000 > >> # default voltage without divider > >> min+30*step > >> 1100000 > >> min=min-(fb_uv-min)*r2/r1 > >> step=step*(r1+r2)/r1 > >> min > >> 981454 > >> step > >> 12268 > >> # default voltage with divider > >> min+30*step > >> 1349494 > >> > >> Probably we need to use this value rather than the nominal 135000 as > >> the target voltage in the DTB. > > > > Yes. When the driver calculates the voltages which match the actual > > voltages, then you should also use the actual voltages in the device-tree. > > > > Think I've got it: > > diff --git a/drivers/regulator/bd718x7-regulator.c > b/drivers/regulator/bd718x7-regulator.c > index 022d98f3c32a2..ea9c4058ee6a5 100644 > --- a/drivers/regulator/bd718x7-regulator.c > +++ b/drivers/regulator/bd718x7-regulator.c > @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, > struct device_node *np, > step /= r1; > > new[j].min = min; > + new[j].min_sel = > desc->linear_ranges[j].min_sel; > + new[j].max_sel = > desc->linear_ranges[j].max_sel; > new[j].step = step; > > dev_dbg(dev, "%s: old range min %d, > step %d\n", > > > the min_sel and max_sel fields were uninitialized in the new > linear_range, copying them over from the old one (they refer to the > register range if I understand correctly so they should not change) > initializes them. > > Then setting 1349494 as the actual voltage makes it fully work. > Otherwise it complains: > buck6: failed to apply 1350000-1350000uV constraint: -EINVAL > > Final debug output now: > [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 > [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 > [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up > configured > > I will add this fix to the next version of this patchset and include > your requested change in the dts. > Does it also work with min/max settings in the DTS that are taken from the designated value +/- 5% tolerance margin, so that the DTS contains reasonable values determined by the HW requirements, rather than some artificial number that is enforced by the SW behaviour? E.g.: regulator-min-microvolts = <(135000 - 6750)>; regulator-min-microvolts = <(135000 + 6750)>; Thus, the nominal value of the voltage is explicitly shown in the DTS file. Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-30 8:54 ` Lothar Waßmann @ 2025-10-30 11:01 ` Matti Vaittinen 2025-10-30 12:00 ` Lothar Waßmann 2025-10-30 14:45 ` Maud Spierings 1 sibling, 1 reply; 34+ messages in thread From: Matti Vaittinen @ 2025-10-30 11:01 UTC (permalink / raw) To: Lothar Waßmann, Maud Spierings Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 30/10/2025 10:54, Lothar Waßmann wrote: > Hi, > > On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: >> Hi Matti, >> >> On 10/29/25 11:05, Matti Vaittinen wrote: >>> On 29/10/2025 11:48, Lothar Waßmann wrote: >>>> Hi, >>>> >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>>> [...] >>>>>>>>> Could/Should this be described using the: >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>>> scaled voltages. >>>>>>>>> >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>>> // snip >>>>> >>>>> If real voltages aren't matching what is calculated by the driver, then >>>>> the voltages requested by regulator consumers will cause wrong voltages >>>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>>> safety limits set in the device-tree will not be really respected. >>>>> >>>>> I think this would be well worth fixing. >>>>> >>>> Before doing the real-life test I did the same calculation that's done >>>> in the driver to be sure that it will generate the correct values: >>>> bc 1.07.1 >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>>> Free Software Foundation, Inc. >>>> This is free software with ABSOLUTELY NO WARRANTY. >>>> For details type `warranty'. >>>> fb_uv=0 >>>> r1=2200 >>>> r2=499 >>>> min=800000 >>>> step=10000 >>>> # default voltage without divider >>>> min+30*step >>>> 1100000 >>>> min=min-(fb_uv-min)*r2/r1 >>>> step=step*(r1+r2)/r1 >>>> min >>>> 981454 >>>> step >>>> 12268 >>>> # default voltage with divider >>>> min+30*step >>>> 1349494 >>>> >>>> Probably we need to use this value rather than the nominal 135000 as >>>> the target voltage in the DTB. >>> >>> Yes. When the driver calculates the voltages which match the actual >>> voltages, then you should also use the actual voltages in the device-tree. >>> >> // snip >> >> Then setting 1349494 as the actual voltage makes it fully work. >> Otherwise it complains: >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL >> >> Final debug output now: >> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 >> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 >> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up >> configured >> >> I will add this fix to the next version of this patchset and include >> your requested change in the dts. >> > Does it also work with min/max settings in the DTS that are taken from > the designated value +/- 5% tolerance margin, so that the DTS contains > reasonable values determined by the HW requirements, rather than some > artificial number that is enforced by the SW behaviour? I am unsure what you mean by "artificial number that is enforced by the SW behaviour"? As far as I understand, the PMIC operation is altered by modifying the feedback-pin voltage, right? So, the HW _really_ outputs something else but the 'PMIC nominal voltage'? When this hardware connection to the feedback-pin is done, the nominal voltage is never really seen anywhere else but the PMIC data-sheet, right? > E.g.: > regulator-min-microvolts = <(135000 - 6750)>; > regulator-min-microvolts = <(135000 + 6750)>; > Thus, the nominal value of the voltage is explicitly shown in the DTS > file. I don't know why there should be two different min values? Assuming the latter should be max - I have no problem seeing a range of allowed voltages in constrains - if the hardware can tolerate voltages within the range. In my opinion, the values used should however reflect the _actual_ output voltage, taking the effect of the feedback-pin modification into account. This is also what using the: 'rohm,feedback-pull-up-r1-ohms' 'rohm,feedback-pull-up-r2-ohms' and the pull-up voltage property allows one to use. In general, regulator consumers expect to get the _actual_ voltage the regulator outputs, via regulator APIs. Think for example of an ADC getting reference voltage from a regulator. If it asks for used voltage and gets 1350000uV from the regulator subsystem it will use that to calculate the scale. If voltage really is something else, altered by a feedback-pin connection, the ADC will be having offset. I don't know if voltages reported by the framework matter in your specific use-case - but it doesn't mean letting the regulator subsystem use bogus voltages is right. Yours, -- Matti -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-30 11:01 ` Matti Vaittinen @ 2025-10-30 12:00 ` Lothar Waßmann 2025-10-31 12:07 ` Matti Vaittinen 0 siblings, 1 reply; 34+ messages in thread From: Lothar Waßmann @ 2025-10-30 12:00 UTC (permalink / raw) To: Matti Vaittinen Cc: Maud Spierings, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi, On Thu, 30 Oct 2025 13:01:52 +0200 Matti Vaittinen wrote: > On 30/10/2025 10:54, Lothar Waßmann wrote: > > Hi, > > > > On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: > >> Hi Matti, > >> > >> On 10/29/25 11:05, Matti Vaittinen wrote: > >>> On 29/10/2025 11:48, Lothar Waßmann wrote: > >>>> Hi, > >>>> > >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: > >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: > >>>>>> Hi, > >>>>>> > >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: > >>>>>>> On 10/28/25 13:42, Maud Spierings wrote: > >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: > >>>>>> [...] > >>>>>>>>> Could/Should this be described using the: > >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and > >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment > >>>>>>>>> correctly, that might allow the driver to be able to use correctly > >>>>>>>>> scaled voltages. > >>>>>>>>> > >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > >>>>>>>> > > // snip > > >>>>> > >>>>> If real voltages aren't matching what is calculated by the driver, then > >>>>> the voltages requested by regulator consumers will cause wrong voltages > >>>>> to be applied. Debug interfaces will also show wrong voltages, and the > >>>>> safety limits set in the device-tree will not be really respected. > >>>>> > >>>>> I think this would be well worth fixing. > >>>>> > >>>> Before doing the real-life test I did the same calculation that's done > >>>> in the driver to be sure that it will generate the correct values: > >>>> bc 1.07.1 > >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 > >>>> Free Software Foundation, Inc. > >>>> This is free software with ABSOLUTELY NO WARRANTY. > >>>> For details type `warranty'. > >>>> fb_uv=0 > >>>> r1=2200 > >>>> r2=499 > >>>> min=800000 > >>>> step=10000 > >>>> # default voltage without divider > >>>> min+30*step > >>>> 1100000 > >>>> min=min-(fb_uv-min)*r2/r1 > >>>> step=step*(r1+r2)/r1 > >>>> min > >>>> 981454 > >>>> step > >>>> 12268 > >>>> # default voltage with divider > >>>> min+30*step > >>>> 1349494 > >>>> > >>>> Probably we need to use this value rather than the nominal 135000 as > >>>> the target voltage in the DTB. > >>> > >>> Yes. When the driver calculates the voltages which match the actual > >>> voltages, then you should also use the actual voltages in the device-tree. > >>> > >> > > // snip > > >> > >> Then setting 1349494 as the actual voltage makes it fully work. > >> Otherwise it complains: > >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL > >> > >> Final debug output now: > >> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 > >> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 > >> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up > >> configured > >> > >> I will add this fix to the next version of this patchset and include > >> your requested change in the dts. > >> > > Does it also work with min/max settings in the DTS that are taken from > > the designated value +/- 5% tolerance margin, so that the DTS contains > > reasonable values determined by the HW requirements, rather than some > > artificial number that is enforced by the SW behaviour? > > I am unsure what you mean by "artificial number that is enforced by the > SW behaviour"? > The nominal voltage that is required by the consumer is 1.35 V. That's the voltage I would expect to set as target for the regulator. If that voltage cannot be achieved exactly, I would prefer to have the intended voltage listed explicitly rather than listing a value that accidentally can be achieved by the regulator but has nothing to do with the requirements of the consumer. > I don't know why there should be two different min values? Assuming the > latter should be max - I have no problem seeing a range of allowed > My copypaste is obviously spoiled... ;) Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-30 12:00 ` Lothar Waßmann @ 2025-10-31 12:07 ` Matti Vaittinen 0 siblings, 0 replies; 34+ messages in thread From: Matti Vaittinen @ 2025-10-31 12:07 UTC (permalink / raw) To: Lothar Waßmann Cc: Maud Spierings, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel On 30/10/2025 14:00, Lothar Waßmann wrote: > Hi, > > On Thu, 30 Oct 2025 13:01:52 +0200 Matti Vaittinen wrote: >> On 30/10/2025 10:54, Lothar Waßmann wrote: >>> Hi, >>> >>> On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: >>>> Hi Matti, >>>> >>>> On 10/29/25 11:05, Matti Vaittinen wrote: >>>>> On 29/10/2025 11:48, Lothar Waßmann wrote: >>>>>> Hi, >>>>>> >>>>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>>>>> [...] >>>>>>>>>>> Could/Should this be described using the: >>>>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>>>>> scaled voltages. >>>>>>>>>>> >>>>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>>>>> >> >> // snip >> >>>>>>> >>>>>>> If real voltages aren't matching what is calculated by the driver, then >>>>>>> the voltages requested by regulator consumers will cause wrong voltages >>>>>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>>>>> safety limits set in the device-tree will not be really respected. >>>>>>> >>>>>>> I think this would be well worth fixing. >>>>>>> >>>>>> Before doing the real-life test I did the same calculation that's done >>>>>> in the driver to be sure that it will generate the correct values: >>>>>> bc 1.07.1 >>>>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>>>>> Free Software Foundation, Inc. >>>>>> This is free software with ABSOLUTELY NO WARRANTY. >>>>>> For details type `warranty'. >>>>>> fb_uv=0 >>>>>> r1=2200 >>>>>> r2=499 >>>>>> min=800000 >>>>>> step=10000 >>>>>> # default voltage without divider >>>>>> min+30*step >>>>>> 1100000 >>>>>> min=min-(fb_uv-min)*r2/r1 >>>>>> step=step*(r1+r2)/r1 >>>>>> min >>>>>> 981454 >>>>>> step >>>>>> 12268 >>>>>> # default voltage with divider >>>>>> min+30*step >>>>>> 1349494 >>>>>> >>>>>> Probably we need to use this value rather than the nominal 135000 as >>>>>> the target voltage in the DTB. >>>>> >>>>> Yes. When the driver calculates the voltages which match the actual >>>>> voltages, then you should also use the actual voltages in the device-tree. >>>>> >>>> >> >> // snip >> >>>> >>>> Then setting 1349494 as the actual voltage makes it fully work. >>>> Otherwise it complains: >>>> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL >>>> >>>> Final debug output now: >>>> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 >>>> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 >>>> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up >>>> configured >>>> >>>> I will add this fix to the next version of this patchset and include >>>> your requested change in the dts. >>>> >>> Does it also work with min/max settings in the DTS that are taken from >>> the designated value +/- 5% tolerance margin, so that the DTS contains >>> reasonable values determined by the HW requirements, rather than some >>> artificial number that is enforced by the SW behaviour? >> >> I am unsure what you mean by "artificial number that is enforced by the >> SW behaviour"? >> > The nominal voltage that is required by the consumer is 1.35 V. That's > the voltage I would expect to set as target for the regulator. > If that voltage cannot be achieved exactly, I would prefer to have the > intended voltage listed explicitly rather than listing a value that > accidentally can be achieved by the regulator but has nothing to do with > the requirements of the consumer. Ah. Thanks for the explanation. I get it now - sorry for the noise. -- Matti Vaittinen Linux kernel developer at ROHM Semiconductors Oulu Finland ~~ When things go utterly wrong vim users can always type :help! ~~ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-30 8:54 ` Lothar Waßmann 2025-10-30 11:01 ` Matti Vaittinen @ 2025-10-30 14:45 ` Maud Spierings 2025-10-31 5:36 ` Lothar Waßmann 1 sibling, 1 reply; 34+ messages in thread From: Maud Spierings @ 2025-10-30 14:45 UTC (permalink / raw) To: Lothar Waßmann Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi Lothar, On 10/30/25 09:54, Lothar Waßmann wrote: > Hi, > > On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: >> Hi Matti, >> >> On 10/29/25 11:05, Matti Vaittinen wrote: >>> On 29/10/2025 11:48, Lothar Waßmann wrote: >>>> Hi, >>>> >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>>> [...] >>>>>>>>> Could/Should this be described using the: >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>>> scaled voltages. >>>>>>>>> >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>>> >>>>>>>> Ah I didn't know those existed, should've checked the bindings in >>>>>>>> more >>>>>>>> detail, thanks for the hint! >>>>>>>> >>>>>>>> I will have to investigate this carefully, since I don't have >>>>>>>> access to >>>>>>>> the actual design of the COM, so I don't know exactly what is there. >>>>>>> >>>>>>> So I am not yet entirely sure if this works out, I used the >>>>>>> calculation >>>>>>> in the driver: >>>>>>> >>>>>>> /* >>>>>>> * Setups where regulator (especially the buck8) output voltage >>>>>>> is scaled >>>>>>> * by adding external connection where some other regulator >>>>>>> output is >>>>>>> connected >>>>>>> * to feedback-pin (over suitable resistors) is getting popular >>>>>>> amongst >>>>>>> users >>>>>>> * of BD71837. (This allows for example scaling down the buck8 >>>>>>> voltages >>>>>>> to suit >>>>>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>>>>> supply power >>>>>>> * for GPU. Additionally some setups do allow DVS for buck8 but >>>>>>> as this do >>>>>>> * produce voltage spikes the HW must be evaluated to be able to >>>>>>> survive this >>>>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>>>>> don't want >>>>>>> * to help you burn your proto board) >>>>>>> * >>>>>>> * So we allow describing this external connection from DT and >>>>>>> scale the >>>>>>> * voltages accordingly. This is what the connection should look >>>>>>> like: >>>>>>> * >>>>>>> * |------------| >>>>>>> * | buck 8 |-------+----->Vout >>>>>>> * | | | >>>>>>> * |------------| | >>>>>>> * | FB pin | >>>>>>> * | | >>>>>>> * +-------+--R2---+ >>>>>>> * | >>>>>>> * R1 >>>>>>> * | >>>>>>> * V FB-pull-up >>>>>>> * >>>>>>> * Here the buck output is sifted according to formula: >>>>>>> * >>>>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>>>>> * Linear_step = step_orig*(R1+R2)/R1 >>>>>>> * >>>>>>> * where: >>>>>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>>>>> * Vo is original voltage output at vsel reg value 0 >>>>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>>>>> * R1 and R2 are resistor values. >>>>>>> * >>>>>>> * As a real world example for buck8 and a specific GPU: >>>>>>> * VLDO = 1.6V (used as FB-pull-up) >>>>>>> * R1 = 1000ohms >>>>>>> * R2 = 150ohms >>>>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>>>>> */ >>>>>>> >>>>>>> Because I do not know the pull up voltage, and I am not sure if it >>>>>>> is a >>>>>>> pull up. >>>>>>> >>>>>>> So: >>>>>>> Vout_o = 1.35V >>>>>>> Vo = 1.1V >>>>>>> Vpu = unknown >>>>>>> R2 = 499 Ohm >>>>>>> R1 = 2200 Ohm >>>>>>> Gives: >>>>>>> Vpu = ~0V >>>>>>> >>>>>>> And: >>>>>>> Vout_o = 1.35V >>>>>>> Vo = 1.1V >>>>>>> Vpu = unknown >>>>>>> R2 = 2200 Ohm >>>>>>> R1 = 499 Ohm >>>>>>> Gives: >>>>>>> Vpu = ~1.04V >>>>>>> >>>>>>> I am not quite sure which resistor is R1 and which is R2 but having >>>>>>> there be a pull down to 0V seems the most logical answer? >>>>>>> >>>>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some >>>>>>> light on >>>>>>> this setup. >>>>>> R2 is connected to GND, so Vpu = 0. >>>>>> With: >>>>>> regulator-min-microvolt = <1350000>; >>>>>> regulator-max-microvolt = <1350000>; >>>>>> rohm,fb-pull-up-microvolt = <0>; >>>>>> rohm,feedback-pull-up-r1-ohms = <2200>; >>>>>> rohm,feedback-pull-up-r2-ohms = <499>; >>>>>> the correct voltage should be produced on the BUCK8 output, but a quick >>>>>> test with these parameters led to: >>>>>> |failed to get the current voltage: -EINVAL >>>>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register >>>>>> buck6 regulator >>>>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>>>>> >>>>>> Apparently noone has ever tested this feature in real life. >>>>> >>>>> Thanks for trying it out Lothar. I am positive this was tested - but >>>>> probably the use-case has been using a pull-up. I assume having the zero >>>>> pull-up voltage causes the driver to calculate some bogus values. I >>>>> think fixing the computation in the driver might not be that big of a >>>>> task(?) The benefit of doing it would be that the correct voltages would >>>>> be calculated by the driver. >>>>> >>>>> If real voltages aren't matching what is calculated by the driver, then >>>>> the voltages requested by regulator consumers will cause wrong voltages >>>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>>> safety limits set in the device-tree will not be really respected. >>>>> >>>>> I think this would be well worth fixing. >>>>> >>>> Before doing the real-life test I did the same calculation that's done >>>> in the driver to be sure that it will generate the correct values: >>>> bc 1.07.1 >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>>> Free Software Foundation, Inc. >>>> This is free software with ABSOLUTELY NO WARRANTY. >>>> For details type `warranty'. >>>> fb_uv=0 >>>> r1=2200 >>>> r2=499 >>>> min=800000 >>>> step=10000 >>>> # default voltage without divider >>>> min+30*step >>>> 1100000 >>>> min=min-(fb_uv-min)*r2/r1 >>>> step=step*(r1+r2)/r1 >>>> min >>>> 981454 >>>> step >>>> 12268 >>>> # default voltage with divider >>>> min+30*step >>>> 1349494 >>>> >>>> Probably we need to use this value rather than the nominal 135000 as >>>> the target voltage in the DTB. >>> >>> Yes. When the driver calculates the voltages which match the actual >>> voltages, then you should also use the actual voltages in the device-tree. >>> >> >> Think I've got it: >> >> diff --git a/drivers/regulator/bd718x7-regulator.c >> b/drivers/regulator/bd718x7-regulator.c >> index 022d98f3c32a2..ea9c4058ee6a5 100644 >> --- a/drivers/regulator/bd718x7-regulator.c >> +++ b/drivers/regulator/bd718x7-regulator.c >> @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, >> struct device_node *np, >> step /= r1; >> >> new[j].min = min; >> + new[j].min_sel = >> desc->linear_ranges[j].min_sel; >> + new[j].max_sel = >> desc->linear_ranges[j].max_sel; >> new[j].step = step; >> >> dev_dbg(dev, "%s: old range min %d, >> step %d\n", >> >> >> the min_sel and max_sel fields were uninitialized in the new >> linear_range, copying them over from the old one (they refer to the >> register range if I understand correctly so they should not change) >> initializes them. >> >> Then setting 1349494 as the actual voltage makes it fully work. >> Otherwise it complains: >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL >> >> Final debug output now: >> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 >> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 >> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up >> configured >> >> I will add this fix to the next version of this patchset and include >> your requested change in the dts. >> > Does it also work with min/max settings in the DTS that are taken from > the designated value +/- 5% tolerance margin, so that the DTS contains > reasonable values determined by the HW requirements, rather than some > artificial number that is enforced by the SW behaviour? > E.g.: > regulator-min-microvolts = <(135000 - 6750)>; > regulator-min-microvolts = <(135000 + 6750)>; > Thus, the nominal value of the voltage is explicitly shown in the DTS > file. Setting that range seems to work: regulator use open bypass opmode voltage current min max --------------------------------------------------------------------------------------- regulator-dummy 1 1 0 unknown 0mV 0mA 0mV 0mV 2-0014-vled 0 0mA 0mV 0mV 6v4 1 0 0 unknown 6400mV 0mA 6400mV 6400mV 3v3-etn 1 1 0 unknown 3300mV 0mA 3300mV 3300mV 30be0000.ethernet-phy 1 0mA 0mV 0mV 3v3-m.2 3 3 0 unknown 3300mV 0mA 3300mV 3300mV 30b50000.mmc-vmmc 1 0mA 3300mV 3400mV serial0-0-vddio 1 0mA 0mV 0mV serial0-0-vbat 1 0mA 0mV 0mV 5v0 2 1 0 unknown 5000mV 0mA 5000mV 5000mV 32e50000.usb-vbus 1 0mA 0mV 0mV can1-stby 1 1 0 unknown 3300mV 0mA 3300mV 3300mV spi0.2-xceiver 1 0mA 0mV 0mV can2-stby 1 1 0 unknown 3300mV 0mA 3300mV 3300mV spi0.3-xceiver 1 0mA 0mV 0mV can3-stby 1 1 0 unknown 3300mV 0mA 3300mV 3300mV spi1.2-xceiver 1 0mA 0mV 0mV can4-stby 1 1 0 unknown 3300mV 0mA 3300mV 3300mV spi1.3-xceiver 1 0mA 0mV 0mV buck1 1 0 0 unknown 900mV 0mA 780mV 900mV buck2 2 1 0 unknown 850mV 0mA 810mV 950mV cpu0-cpu 1 0mA 850mV 850mV buck3 1 0 0 unknown 900mV 0mA 850mV 900mV buck4 7 6 0 unknown 3300mV 0mA 3300mV 3300mV 30b40000.mmc-vmmc 1 0mA 3300mV 3400mV spi1.3-vdd 1 0mA 0mV 0mV spi1.2-vdd 1 0mA 0mV 0mV spi0.3-vdd 1 0mA 0mV 0mV spi0.2-vdd 1 0mA 0mV 0mV spi2.4-vref 1 0mA 0mV 0mV buck5 3 2 0 unknown 1800mV 0mA 1755mV 1950mV 30b40000.mmc-vqmmc 1 0mA 0mV 0mV ldo6 1 0 0 unknown 1200mV 0mA 1200mV 1200mV buck6 1 0 0 unknown 1349mV 0mA 1288mV 1410mV ldo1 1 0 0 unknown 1800mV 0mA 1700mV 1900mV ldo2 1 0 0 unknown 800mV 0mA 800mV 900mV ldo3 1 0 0 unknown 1800mV 0mA 1800mV 1800mV ldo4 1 0 0 unknown 900mV 0mA 900mV 1000mV ldo5 0 0 0 unknown 3300mV 0mA 1800mV 3300mV buck6 at 1349 mV Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-30 14:45 ` Maud Spierings @ 2025-10-31 5:36 ` Lothar Waßmann 2025-10-31 7:26 ` Maud Spierings 0 siblings, 1 reply; 34+ messages in thread From: Lothar Waßmann @ 2025-10-31 5:36 UTC (permalink / raw) To: Maud Spierings Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi, On Thu, 30 Oct 2025 15:45:14 +0100 Maud Spierings wrote: > Hi Lothar, > > On 10/30/25 09:54, Lothar Waßmann wrote: > > Hi, > > > > On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: > >> Hi Matti, > >> > >> On 10/29/25 11:05, Matti Vaittinen wrote: > >>> On 29/10/2025 11:48, Lothar Waßmann wrote: > >>>> Hi, > >>>> > >>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: > >>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: > >>>>>> Hi, > >>>>>> > >>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: > >>>>>>> On 10/28/25 13:42, Maud Spierings wrote: > >>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: > >>>>>> [...] > >>>>>>>>> Could/Should this be described using the: > >>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and > >>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment > >>>>>>>>> correctly, that might allow the driver to be able to use correctly > >>>>>>>>> scaled voltages. > >>>>>>>>> > >>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ > >>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 > >>>>>>>> > >>>>>>>> Ah I didn't know those existed, should've checked the bindings in > >>>>>>>> more > >>>>>>>> detail, thanks for the hint! > >>>>>>>> > >>>>>>>> I will have to investigate this carefully, since I don't have > >>>>>>>> access to > >>>>>>>> the actual design of the COM, so I don't know exactly what is there. > >>>>>>> > >>>>>>> So I am not yet entirely sure if this works out, I used the > >>>>>>> calculation > >>>>>>> in the driver: > >>>>>>> > >>>>>>> /* > >>>>>>> * Setups where regulator (especially the buck8) output voltage > >>>>>>> is scaled > >>>>>>> * by adding external connection where some other regulator > >>>>>>> output is > >>>>>>> connected > >>>>>>> * to feedback-pin (over suitable resistors) is getting popular > >>>>>>> amongst > >>>>>>> users > >>>>>>> * of BD71837. (This allows for example scaling down the buck8 > >>>>>>> voltages > >>>>>>> to suit > >>>>>>> * lover GPU voltages for projects where buck8 is (ab)used to > >>>>>>> supply power > >>>>>>> * for GPU. Additionally some setups do allow DVS for buck8 but > >>>>>>> as this do > >>>>>>> * produce voltage spikes the HW must be evaluated to be able to > >>>>>>> survive this > >>>>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I > >>>>>>> don't want > >>>>>>> * to help you burn your proto board) > >>>>>>> * > >>>>>>> * So we allow describing this external connection from DT and > >>>>>>> scale the > >>>>>>> * voltages accordingly. This is what the connection should look > >>>>>>> like: > >>>>>>> * > >>>>>>> * |------------| > >>>>>>> * | buck 8 |-------+----->Vout > >>>>>>> * | | | > >>>>>>> * |------------| | > >>>>>>> * | FB pin | > >>>>>>> * | | > >>>>>>> * +-------+--R2---+ > >>>>>>> * | > >>>>>>> * R1 > >>>>>>> * | > >>>>>>> * V FB-pull-up > >>>>>>> * > >>>>>>> * Here the buck output is sifted according to formula: > >>>>>>> * > >>>>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 > >>>>>>> * Linear_step = step_orig*(R1+R2)/R1 > >>>>>>> * > >>>>>>> * where: > >>>>>>> * Vout_o is adjusted voltage output at vsel reg value 0 > >>>>>>> * Vo is original voltage output at vsel reg value 0 > >>>>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture > >>>>>>> * R1 and R2 are resistor values. > >>>>>>> * > >>>>>>> * As a real world example for buck8 and a specific GPU: > >>>>>>> * VLDO = 1.6V (used as FB-pull-up) > >>>>>>> * R1 = 1000ohms > >>>>>>> * R2 = 150ohms > >>>>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V > >>>>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV > >>>>>>> */ > >>>>>>> > >>>>>>> Because I do not know the pull up voltage, and I am not sure if it > >>>>>>> is a > >>>>>>> pull up. > >>>>>>> > >>>>>>> So: > >>>>>>> Vout_o = 1.35V > >>>>>>> Vo = 1.1V > >>>>>>> Vpu = unknown > >>>>>>> R2 = 499 Ohm > >>>>>>> R1 = 2200 Ohm > >>>>>>> Gives: > >>>>>>> Vpu = ~0V > >>>>>>> > >>>>>>> And: > >>>>>>> Vout_o = 1.35V > >>>>>>> Vo = 1.1V > >>>>>>> Vpu = unknown > >>>>>>> R2 = 2200 Ohm > >>>>>>> R1 = 499 Ohm > >>>>>>> Gives: > >>>>>>> Vpu = ~1.04V > >>>>>>> > >>>>>>> I am not quite sure which resistor is R1 and which is R2 but having > >>>>>>> there be a pull down to 0V seems the most logical answer? > >>>>>>> > >>>>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some > >>>>>>> light on > >>>>>>> this setup. > >>>>>> R2 is connected to GND, so Vpu = 0. > >>>>>> With: > >>>>>> regulator-min-microvolt = <1350000>; > >>>>>> regulator-max-microvolt = <1350000>; > >>>>>> rohm,fb-pull-up-microvolt = <0>; > >>>>>> rohm,feedback-pull-up-r1-ohms = <2200>; > >>>>>> rohm,feedback-pull-up-r2-ohms = <499>; > >>>>>> the correct voltage should be produced on the BUCK8 output, but a quick > >>>>>> test with these parameters led to: > >>>>>> |failed to get the current voltage: -EINVAL > >>>>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register > >>>>>> buck6 regulator > >>>>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 > >>>>>> > >>>>>> Apparently noone has ever tested this feature in real life. > >>>>> > >>>>> Thanks for trying it out Lothar. I am positive this was tested - but > >>>>> probably the use-case has been using a pull-up. I assume having the zero > >>>>> pull-up voltage causes the driver to calculate some bogus values. I > >>>>> think fixing the computation in the driver might not be that big of a > >>>>> task(?) The benefit of doing it would be that the correct voltages would > >>>>> be calculated by the driver. > >>>>> > >>>>> If real voltages aren't matching what is calculated by the driver, then > >>>>> the voltages requested by regulator consumers will cause wrong voltages > >>>>> to be applied. Debug interfaces will also show wrong voltages, and the > >>>>> safety limits set in the device-tree will not be really respected. > >>>>> > >>>>> I think this would be well worth fixing. > >>>>> > >>>> Before doing the real-life test I did the same calculation that's done > >>>> in the driver to be sure that it will generate the correct values: > >>>> bc 1.07.1 > >>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 > >>>> Free Software Foundation, Inc. > >>>> This is free software with ABSOLUTELY NO WARRANTY. > >>>> For details type `warranty'. > >>>> fb_uv=0 > >>>> r1=2200 > >>>> r2=499 > >>>> min=800000 > >>>> step=10000 > >>>> # default voltage without divider > >>>> min+30*step > >>>> 1100000 > >>>> min=min-(fb_uv-min)*r2/r1 > >>>> step=step*(r1+r2)/r1 > >>>> min > >>>> 981454 > >>>> step > >>>> 12268 > >>>> # default voltage with divider > >>>> min+30*step > >>>> 1349494 > >>>> > >>>> Probably we need to use this value rather than the nominal 135000 as > >>>> the target voltage in the DTB. > >>> > >>> Yes. When the driver calculates the voltages which match the actual > >>> voltages, then you should also use the actual voltages in the device-tree. > >>> > >> > >> Think I've got it: > >> > >> diff --git a/drivers/regulator/bd718x7-regulator.c > >> b/drivers/regulator/bd718x7-regulator.c > >> index 022d98f3c32a2..ea9c4058ee6a5 100644 > >> --- a/drivers/regulator/bd718x7-regulator.c > >> +++ b/drivers/regulator/bd718x7-regulator.c > >> @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, > >> struct device_node *np, > >> step /= r1; > >> > >> new[j].min = min; > >> + new[j].min_sel = > >> desc->linear_ranges[j].min_sel; > >> + new[j].max_sel = > >> desc->linear_ranges[j].max_sel; > >> new[j].step = step; > >> > >> dev_dbg(dev, "%s: old range min %d, > >> step %d\n", > >> > >> > >> the min_sel and max_sel fields were uninitialized in the new > >> linear_range, copying them over from the old one (they refer to the > >> register range if I understand correctly so they should not change) > >> initializes them. > >> > >> Then setting 1349494 as the actual voltage makes it fully work. > >> Otherwise it complains: > >> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL > >> > >> Final debug output now: > >> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 > >> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 > >> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up > >> configured > >> > >> I will add this fix to the next version of this patchset and include > >> your requested change in the dts. > >> > > Does it also work with min/max settings in the DTS that are taken from > > the designated value +/- 5% tolerance margin, so that the DTS contains > > reasonable values determined by the HW requirements, rather than some > > artificial number that is enforced by the SW behaviour? > > E.g.: > > regulator-min-microvolts = <(135000 - 6750)>; > > regulator-min-microvolts = <(135000 + 6750)>; > > Thus, the nominal value of the voltage is explicitly shown in the DTS > > file. > > Setting that range seems to work: > I just checked the datasheet of the DRAM powered by the regulator. The voltage tolerance of the 1.35V supply is -.067 V + .1 V. I.e. the voltage settings should be: regulator-min-microvolts = <(135000 - 6700)>; regulator-max-microvolts = <(135000 + 10000)>; to match the actual requirements of the consumer for this regulator. Lothar Waßmann ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM 2025-10-31 5:36 ` Lothar Waßmann @ 2025-10-31 7:26 ` Maud Spierings 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-31 7:26 UTC (permalink / raw) To: Lothar Waßmann Cc: Matti Vaittinen, Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, imx, linux-arm-kernel Hi Lothar, On 10/31/25 06:36, Lothar Waßmann wrote: > Hi, > > On Thu, 30 Oct 2025 15:45:14 +0100 Maud Spierings wrote: >> Hi Lothar, >> >> On 10/30/25 09:54, Lothar Waßmann wrote: >>> Hi, >>> >>> On Wed, 29 Oct 2025 16:35:25 +0100 Maud Spierings wrote: >>>> Hi Matti, >>>> >>>> On 10/29/25 11:05, Matti Vaittinen wrote: >>>>> On 29/10/2025 11:48, Lothar Waßmann wrote: >>>>>> Hi, >>>>>> >>>>>> On Wed, 29 Oct 2025 10:42:17 +0200 Matti Vaittinen wrote: >>>>>>> On 29/10/2025 09:11, Lothar Waßmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On Tue, 28 Oct 2025 14:10:04 +0100 Maud Spierings wrote: >>>>>>>>> On 10/28/25 13:42, Maud Spierings wrote: >>>>>>>>>> On 10/28/25 13:15, Matti Vaittinen wrote: >>>>>>>> [...] >>>>>>>>>>> Could/Should this be described using the: >>>>>>>>>>> 'rohm,feedback-pull-up-r1-ohms' and >>>>>>>>>>> 'rohm,feedback-pull-up-r2-ohms'? If I understand the comment >>>>>>>>>>> correctly, that might allow the driver to be able to use correctly >>>>>>>>>>> scaled voltages. >>>>>>>>>>> >>>>>>>>>>> https://elixir.bootlin.com/linux/v6.18-rc1/source/Documentation/ >>>>>>>>>>> devicetree/bindings/regulator/rohm,bd71837-regulator.yaml#L108 >>>>>>>>>> >>>>>>>>>> Ah I didn't know those existed, should've checked the bindings in >>>>>>>>>> more >>>>>>>>>> detail, thanks for the hint! >>>>>>>>>> >>>>>>>>>> I will have to investigate this carefully, since I don't have >>>>>>>>>> access to >>>>>>>>>> the actual design of the COM, so I don't know exactly what is there. >>>>>>>>> >>>>>>>>> So I am not yet entirely sure if this works out, I used the >>>>>>>>> calculation >>>>>>>>> in the driver: >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * Setups where regulator (especially the buck8) output voltage >>>>>>>>> is scaled >>>>>>>>> * by adding external connection where some other regulator >>>>>>>>> output is >>>>>>>>> connected >>>>>>>>> * to feedback-pin (over suitable resistors) is getting popular >>>>>>>>> amongst >>>>>>>>> users >>>>>>>>> * of BD71837. (This allows for example scaling down the buck8 >>>>>>>>> voltages >>>>>>>>> to suit >>>>>>>>> * lover GPU voltages for projects where buck8 is (ab)used to >>>>>>>>> supply power >>>>>>>>> * for GPU. Additionally some setups do allow DVS for buck8 but >>>>>>>>> as this do >>>>>>>>> * produce voltage spikes the HW must be evaluated to be able to >>>>>>>>> survive this >>>>>>>>> * - hence I keep the DVS disabled for non DVS bucks by default. I >>>>>>>>> don't want >>>>>>>>> * to help you burn your proto board) >>>>>>>>> * >>>>>>>>> * So we allow describing this external connection from DT and >>>>>>>>> scale the >>>>>>>>> * voltages accordingly. This is what the connection should look >>>>>>>>> like: >>>>>>>>> * >>>>>>>>> * |------------| >>>>>>>>> * | buck 8 |-------+----->Vout >>>>>>>>> * | | | >>>>>>>>> * |------------| | >>>>>>>>> * | FB pin | >>>>>>>>> * | | >>>>>>>>> * +-------+--R2---+ >>>>>>>>> * | >>>>>>>>> * R1 >>>>>>>>> * | >>>>>>>>> * V FB-pull-up >>>>>>>>> * >>>>>>>>> * Here the buck output is sifted according to formula: >>>>>>>>> * >>>>>>>>> * Vout_o = Vo - (Vpu - Vo)*R2/R1 >>>>>>>>> * Linear_step = step_orig*(R1+R2)/R1 >>>>>>>>> * >>>>>>>>> * where: >>>>>>>>> * Vout_o is adjusted voltage output at vsel reg value 0 >>>>>>>>> * Vo is original voltage output at vsel reg value 0 >>>>>>>>> * Vpu is the pull-up voltage V FB-pull-up in the picture >>>>>>>>> * R1 and R2 are resistor values. >>>>>>>>> * >>>>>>>>> * As a real world example for buck8 and a specific GPU: >>>>>>>>> * VLDO = 1.6V (used as FB-pull-up) >>>>>>>>> * R1 = 1000ohms >>>>>>>>> * R2 = 150ohms >>>>>>>>> * VSEL 0x0 => 0.8V – (VLDO – 0.8) * R2 / R1 = 0.68V >>>>>>>>> * Linear Step = 10mV * (R1 + R2) / R1 = 11.5mV >>>>>>>>> */ >>>>>>>>> >>>>>>>>> Because I do not know the pull up voltage, and I am not sure if it >>>>>>>>> is a >>>>>>>>> pull up. >>>>>>>>> >>>>>>>>> So: >>>>>>>>> Vout_o = 1.35V >>>>>>>>> Vo = 1.1V >>>>>>>>> Vpu = unknown >>>>>>>>> R2 = 499 Ohm >>>>>>>>> R1 = 2200 Ohm >>>>>>>>> Gives: >>>>>>>>> Vpu = ~0V >>>>>>>>> >>>>>>>>> And: >>>>>>>>> Vout_o = 1.35V >>>>>>>>> Vo = 1.1V >>>>>>>>> Vpu = unknown >>>>>>>>> R2 = 2200 Ohm >>>>>>>>> R1 = 499 Ohm >>>>>>>>> Gives: >>>>>>>>> Vpu = ~1.04V >>>>>>>>> >>>>>>>>> I am not quite sure which resistor is R1 and which is R2 but having >>>>>>>>> there be a pull down to 0V seems the most logical answer? >>>>>>>>> >>>>>>>>> I am adding Lothar from Ka-Ro to the CC maybe he can shed some >>>>>>>>> light on >>>>>>>>> this setup. >>>>>>>> R2 is connected to GND, so Vpu = 0. >>>>>>>> With: >>>>>>>> regulator-min-microvolt = <1350000>; >>>>>>>> regulator-max-microvolt = <1350000>; >>>>>>>> rohm,fb-pull-up-microvolt = <0>; >>>>>>>> rohm,feedback-pull-up-r1-ohms = <2200>; >>>>>>>> rohm,feedback-pull-up-r2-ohms = <499>; >>>>>>>> the correct voltage should be produced on the BUCK8 output, but a quick >>>>>>>> test with these parameters led to: >>>>>>>> |failed to get the current voltage: -EINVAL >>>>>>>> |bd718xx-pmic bd71847-pmic.3.auto: error -EINVAL: failed to register >>>>>>>> buck6 regulator >>>>>>>> |bd718xx-pmic: probe of bd71847-pmic.3.auto failed with error -22 >>>>>>>> >>>>>>>> Apparently noone has ever tested this feature in real life. >>>>>>> >>>>>>> Thanks for trying it out Lothar. I am positive this was tested - but >>>>>>> probably the use-case has been using a pull-up. I assume having the zero >>>>>>> pull-up voltage causes the driver to calculate some bogus values. I >>>>>>> think fixing the computation in the driver might not be that big of a >>>>>>> task(?) The benefit of doing it would be that the correct voltages would >>>>>>> be calculated by the driver. >>>>>>> >>>>>>> If real voltages aren't matching what is calculated by the driver, then >>>>>>> the voltages requested by regulator consumers will cause wrong voltages >>>>>>> to be applied. Debug interfaces will also show wrong voltages, and the >>>>>>> safety limits set in the device-tree will not be really respected. >>>>>>> >>>>>>> I think this would be well worth fixing. >>>>>>> >>>>>> Before doing the real-life test I did the same calculation that's done >>>>>> in the driver to be sure that it will generate the correct values: >>>>>> bc 1.07.1 >>>>>> Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 >>>>>> Free Software Foundation, Inc. >>>>>> This is free software with ABSOLUTELY NO WARRANTY. >>>>>> For details type `warranty'. >>>>>> fb_uv=0 >>>>>> r1=2200 >>>>>> r2=499 >>>>>> min=800000 >>>>>> step=10000 >>>>>> # default voltage without divider >>>>>> min+30*step >>>>>> 1100000 >>>>>> min=min-(fb_uv-min)*r2/r1 >>>>>> step=step*(r1+r2)/r1 >>>>>> min >>>>>> 981454 >>>>>> step >>>>>> 12268 >>>>>> # default voltage with divider >>>>>> min+30*step >>>>>> 1349494 >>>>>> >>>>>> Probably we need to use this value rather than the nominal 135000 as >>>>>> the target voltage in the DTB. >>>>> >>>>> Yes. When the driver calculates the voltages which match the actual >>>>> voltages, then you should also use the actual voltages in the device-tree. >>>>> >>>> >>>> Think I've got it: >>>> >>>> diff --git a/drivers/regulator/bd718x7-regulator.c >>>> b/drivers/regulator/bd718x7-regulator.c >>>> index 022d98f3c32a2..ea9c4058ee6a5 100644 >>>> --- a/drivers/regulator/bd718x7-regulator.c >>>> +++ b/drivers/regulator/bd718x7-regulator.c >>>> @@ -1613,6 +1613,8 @@ static int setup_feedback_loop(struct device *dev, >>>> struct device_node *np, >>>> step /= r1; >>>> >>>> new[j].min = min; >>>> + new[j].min_sel = >>>> desc->linear_ranges[j].min_sel; >>>> + new[j].max_sel = >>>> desc->linear_ranges[j].max_sel; >>>> new[j].step = step; >>>> >>>> dev_dbg(dev, "%s: old range min %d, >>>> step %d\n", >>>> >>>> >>>> the min_sel and max_sel fields were uninitialized in the new >>>> linear_range, copying them over from the old one (they refer to the >>>> register range if I understand correctly so they should not change) >>>> initializes them. >>>> >>>> Then setting 1349494 as the actual voltage makes it fully work. >>>> Otherwise it complains: >>>> buck6: failed to apply 1350000-1350000uV constraint: -EINVAL >>>> >>>> Final debug output now: >>>> [ 0.327807] rohm-bd718x7 0-004b: buck6: old range min 800000, step 10000 >>>> [ 0.327813] rohm-bd718x7 0-004b: new range min 981454, step 12268 >>>> [ 0.327819] rohm-bd718x7 0-004b: regulator 'buck6' has FB pull-up >>>> configured >>>> >>>> I will add this fix to the next version of this patchset and include >>>> your requested change in the dts. >>>> >>> Does it also work with min/max settings in the DTS that are taken from >>> the designated value +/- 5% tolerance margin, so that the DTS contains >>> reasonable values determined by the HW requirements, rather than some >>> artificial number that is enforced by the SW behaviour? >>> E.g.: >>> regulator-min-microvolts = <(135000 - 6750)>; >>> regulator-min-microvolts = <(135000 + 6750)>; >>> Thus, the nominal value of the voltage is explicitly shown in the DTS >>> file. >> >> Setting that range seems to work: >> > I just checked the datasheet of the DRAM powered by the regulator. The voltage > tolerance of the 1.35V supply is -.067 V + .1 V. > I.e. the voltage settings should be: > regulator-min-microvolts = <(135000 - 6700)>; > regulator-max-microvolts = <(135000 + 10000)>; > to match the actual requirements of the consumer for this regulator. Thank you very much for providing these numbers and verifying the calculations. I've incorperated them into my V4 of the patchset. Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV 2025-10-22 7:22 ` Maud Spierings via B4 Relay @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings The Moduline IV is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 8 Moduline IO modules - 4 CAN busses - 1 LIN bus - 1 Ethernet - 4 RGB leds - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/Makefile | 2 + .../imx8mm-tx8m-1610-moduline-iv-306-d.dts | 801 +++++++++++++++++++++ 2 files changed, 803 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index 525ef180481d3..b2fef44e0a370 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@ -124,6 +124,8 @@ imx8mm-evk-pcie-ep-dtbs += imx8mm-evk.dtb imx-pcie0-ep.dtbo imx8mm-evkb-pcie-ep-dtbs += imx8mm-evkb.dtb imx-pcie0-ep.dtbo dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk-pcie-ep.dtb imx8mm-evkb-pcie-ep.dtb +dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb + dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-ctouch2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-edimm2.2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-iot-gateway.dtb diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts new file mode 100644 index 0000000000000..52a8caf4e078e --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts @@ -0,0 +1,801 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +/dts-v1/; + +#include "imx8mm-tx8m-1610.dtsi" +#include <dt-bindings/leds/common.h> + +/ { + chassis-type = "embedded"; + compatible = "gocontroll,moduline-iv", "fsl,imx8mm"; + hardware = "Moduline IV V3.06-D"; + model = "GOcontroll Moduline IV"; + + aliases { + usb-host = &usbotg2; + usbotg = &usbotg1; + spi0 = &ecspi2; /* spidev number compatibility */ + spi1 = &ecspi3; /* spidev number compatibility */ + spi2 = &ecspi1; /* spidev number compatibility */ + }; + + chosen { + stdout-path = "serial2:115200n8"; + }; + + mcp_clock: mcp-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <20000000>; + }; + + reg_3v3_m2: regulator-3v3-m2 { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_m2>; + pinctrl-names = "default"; + power-supply = <®_6v4>; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3-m.2"; + }; + + reg_5v0: regulator-5v0 { + compatible = "regulator-fixed"; + power-supply = <®_6v4>; + regulator-always-on; + regulator-max-microvolt = <5000000>; + regulator-min-microvolt = <5000000>; + regulator-name = "5v0"; + }; + + reg_6v4: regulator-6v4 { + compatible = "regulator-fixed"; + regulator-always-on; + regulator-max-microvolt = <6400000>; + regulator-min-microvolt = <6400000>; + regulator-name = "6v4"; + }; + + reg_can1_stby: regulator-can1-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 16 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can1_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can1-stby"; + }; + + reg_can2_stby: regulator-can2-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 17 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can2_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can2-stby"; + }; + + reg_can3_stby: regulator-can3-stby { + compatible = "regulator-fixed"; + gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can3_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can3-stby"; + }; + + reg_can4_stby: regulator-can4-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 8 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can4_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can4-stby"; + }; + + wifi_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-0 = <&pinctrl_wl_reg>; + pinctrl-names = "default"; + post-power-on-delay-ms = <100>; + power-off-delay-us = <500000>; + reset-gpios = <&gpio3 3 GPIO_ACTIVE_LOW>; + }; +}; + +/* SPI 2 */ +&ecspi1 { + pinctrl-0 = <&pinctrl_ecspi1>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 9 GPIO_ACTIVE_LOW + &gpio1 0 GPIO_ACTIVE_LOW + &gpio5 2 GPIO_ACTIVE_LOW + &gpio4 27 GPIO_ACTIVE_LOW + &gpio3 1 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>; + slot-number = <3>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <21 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; + slot-number = <4>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@2 { + compatible = "gocontroll,moduline-module-slot"; + reg = <2>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 25 GPIO_ACTIVE_LOW>; + slot-number = <5>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@3 { + compatible = "gocontroll,moduline-module-slot"; + reg = <3>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio4>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>; + slot-number = <6>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + adc@4 { + compatible = "microchip,mcp3004"; + reg = <4>; + spi-max-frequency = <2300000>; + vref-supply = <®_vdd_3v3>; + }; +}; + +&ecspi2 { + pinctrl-0 = <&pinctrl_ecspi2>; + pinctrl-names = "default"; + cs-gpios = < + &gpio3 23 GPIO_ACTIVE_LOW + &gpio5 9 GPIO_ACTIVE_LOW + &gpio3 2 GPIO_ACTIVE_LOW + &gpio5 25 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <19 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + slot-number = <7>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <22 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; + slot-number = <8>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + can@2 { // reg vdd? + compatible = "microchip,mcp25625"; + reg = <2>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can1>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can1_stby>; + }; + + can@3 { + compatible = "microchip,mcp25625"; + reg = <3>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <13 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can2>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can2_stby>; + }; +}; + +&ecspi3 { + pinctrl-0 = <&pinctrl_ecspi3>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 4 GPIO_ACTIVE_LOW + &gpio1 10 GPIO_ACTIVE_LOW + &gpio5 5 GPIO_ACTIVE_LOW + &gpio5 4 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <6 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + slot-number = <1>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 11 GPIO_ACTIVE_LOW>; + slot-number = <2>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + can@2 { + compatible = "microchip,mcp25625"; + reg = <2>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can3>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can3_stby>; + }; + + can@3 { + compatible = "microchip,mcp25625"; + reg = <3>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <18 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can4>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can4_stby>; + }; +}; + +&gpu_2d { + status = "disabled"; +}; + +&gpu_3d { + status = "disabled"; +}; + +&i2c2 { + clock-frequency = <400000>; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c2>; + pinctrl-1 = <&pinctrl_i2c2_gpio>; + scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; +}; + +&i2c3 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c3>; + pinctrl-1 = <&pinctrl_i2c3_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + lp5012@14 { + compatible = "ti,lp5012"; + reg = <0x14>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + color = <LED_COLOR_ID_RGB>; + label = "case-led1"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_RGB>; + label = "case-led2"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_RGB>; + label = "case-led3"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + color = <LED_COLOR_ID_RGB>; + label = "case-led4"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + }; +}; + +&iomuxc { + pinctrl_bt: btgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 + MX8MM_DSE_X1 + >; + }; + + pinctrl_can1: can1grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_CE3_B_GPIO3_IO4 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can1_reg: can1reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can2: can2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA07_GPIO3_IO13 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can2_reg: can2reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_WE_B_GPIO3_IO17 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can3: can3grp { + fsl,pins = < + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA06_GPIO3_IO12 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can3_reg: can3reggrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can4: can4grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DQS_GPIO3_IO14 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_WP_B_GPIO3_IO18 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can4_reg: can4reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DATA02_GPIO3_IO8 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_ecspi1: ecspi1grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23 + MX8MM_DSE_X1 + MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2 + MX8MM_DSE_X1 + MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi3: ecspi3grp { + fsl,pins = < + MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 + MX8MM_DSE_X1 + >; + }; + + pinctrl_i2c2: i2c2grp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c2_gpio: i2c2-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3: i2c3grp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3_gpio: i2c3-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_reg_m2: reg-m2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 + MX8MM_DSE_X1 + >; + }; + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart2: uart2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart3: uart3grp { + fsl,pins = < + MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc2: pinctrlusdhc2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + >; + }; + + pinctrl_wl_int: wlintgrp { + fsl,pins = < + MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_wl_reg: wlreggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_CE2_B_GPIO3_IO3 + MX8MM_DSE_X1 + >; + }; +}; + +&uart1 { + pinctrl-0 = <&pinctrl_uart1>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt"; + device-wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH>; + interrupt-names = "host-wakeup"; + interrupt-parent = <&gpio3>; + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; + max-speed = <921600>; + pinctrl-0 = <&pinctrl_bt>; + pinctrl-names = "default"; + shutdown-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; + vbat-supply = <®_3v3_m2>; + vddio-supply = <®_3v3_m2>; + }; +}; + +&uart2 { + pinctrl-0 = <&pinctrl_uart2>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; +}; + +&uart3 { + pinctrl-0 = <&pinctrl_uart3>; + pinctrl-names = "default"; + status = "okay"; +}; + +&uart4 { + pinctrl-0 = <&pinctrl_uart4>; + pinctrl-names = "default"; + status = "okay"; +}; + +&usbotg1 { + disable-over-current; + dr_mode = "peripheral"; + status = "okay"; +}; + +&usbotg2 { + disable-over-current; + dr_mode = "host"; + vbus-supply = <®_5v0>; + status = "okay"; +}; + +&usdhc2 { + #address-cells = <1>; + #size-cells = <0>; + cap-power-off-card; + keep-power-in-suspend; + max-frequency = <50000000>; + mmc-pwrseq = <&wifi_pwrseq>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc2>; + pinctrl-names = "default"; + sd-uhs-sdr25; + vmmc-supply = <®_3v3_m2>; + status = "okay"; + + wifi@1 { + compatible = "infineon,cyw43439-fmac", "brcm,bcm4329-fmac"; + reg = <1>; + pinctrl-0 = <&pinctrl_wl_int>; + pinctrl-names = "default"; + interrupt-names = "host-wake"; + interrupt-parent = <&gpio3>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + brcm,board-type = "GOcontroll,moduline"; + }; +}; + +&vpu_blk_ctrl { + status = "disabled"; +}; + +&vpu_g1 { + status = "disabled"; +}; + +&vpu_g2 { + status = "disabled"; +}; + +&wdog1 { + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings From: Maud Spierings <maudspierings@gocontroll.com> The Moduline IV is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 8 Moduline IO modules - 4 CAN busses - 1 LIN bus - 1 Ethernet - 4 RGB leds - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/Makefile | 2 + .../imx8mm-tx8m-1610-moduline-iv-306-d.dts | 801 +++++++++++++++++++++ 2 files changed, 803 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index 525ef180481d3..b2fef44e0a370 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@ -124,6 +124,8 @@ imx8mm-evk-pcie-ep-dtbs += imx8mm-evk.dtb imx-pcie0-ep.dtbo imx8mm-evkb-pcie-ep-dtbs += imx8mm-evkb.dtb imx-pcie0-ep.dtbo dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk-pcie-ep.dtb imx8mm-evkb-pcie-ep.dtb +dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb + dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-ctouch2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-edimm2.2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-iot-gateway.dtb diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts new file mode 100644 index 0000000000000..52a8caf4e078e --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-iv-306-d.dts @@ -0,0 +1,801 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +/dts-v1/; + +#include "imx8mm-tx8m-1610.dtsi" +#include <dt-bindings/leds/common.h> + +/ { + chassis-type = "embedded"; + compatible = "gocontroll,moduline-iv", "fsl,imx8mm"; + hardware = "Moduline IV V3.06-D"; + model = "GOcontroll Moduline IV"; + + aliases { + usb-host = &usbotg2; + usbotg = &usbotg1; + spi0 = &ecspi2; /* spidev number compatibility */ + spi1 = &ecspi3; /* spidev number compatibility */ + spi2 = &ecspi1; /* spidev number compatibility */ + }; + + chosen { + stdout-path = "serial2:115200n8"; + }; + + mcp_clock: mcp-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <20000000>; + }; + + reg_3v3_m2: regulator-3v3-m2 { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio4 8 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_m2>; + pinctrl-names = "default"; + power-supply = <®_6v4>; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3-m.2"; + }; + + reg_5v0: regulator-5v0 { + compatible = "regulator-fixed"; + power-supply = <®_6v4>; + regulator-always-on; + regulator-max-microvolt = <5000000>; + regulator-min-microvolt = <5000000>; + regulator-name = "5v0"; + }; + + reg_6v4: regulator-6v4 { + compatible = "regulator-fixed"; + regulator-always-on; + regulator-max-microvolt = <6400000>; + regulator-min-microvolt = <6400000>; + regulator-name = "6v4"; + }; + + reg_can1_stby: regulator-can1-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 16 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can1_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can1-stby"; + }; + + reg_can2_stby: regulator-can2-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 17 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can2_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can2-stby"; + }; + + reg_can3_stby: regulator-can3-stby { + compatible = "regulator-fixed"; + gpio = <&gpio1 11 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can3_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can3-stby"; + }; + + reg_can4_stby: regulator-can4-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 8 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can4_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can4-stby"; + }; + + wifi_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-0 = <&pinctrl_wl_reg>; + pinctrl-names = "default"; + post-power-on-delay-ms = <100>; + power-off-delay-us = <500000>; + reset-gpios = <&gpio3 3 GPIO_ACTIVE_LOW>; + }; +}; + +/* SPI 2 */ +&ecspi1 { + pinctrl-0 = <&pinctrl_ecspi1>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 9 GPIO_ACTIVE_LOW + &gpio1 0 GPIO_ACTIVE_LOW + &gpio5 2 GPIO_ACTIVE_LOW + &gpio4 27 GPIO_ACTIVE_LOW + &gpio3 1 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>; + slot-number = <3>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <21 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 15 GPIO_ACTIVE_LOW>; + slot-number = <4>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@2 { + compatible = "gocontroll,moduline-module-slot"; + reg = <2>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 25 GPIO_ACTIVE_LOW>; + slot-number = <5>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@3 { + compatible = "gocontroll,moduline-module-slot"; + reg = <3>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio4>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>; + slot-number = <6>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + adc@4 { + compatible = "microchip,mcp3004"; + reg = <4>; + spi-max-frequency = <2300000>; + vref-supply = <®_vdd_3v3>; + }; +}; + +&ecspi2 { + pinctrl-0 = <&pinctrl_ecspi2>; + pinctrl-names = "default"; + cs-gpios = < + &gpio3 23 GPIO_ACTIVE_LOW + &gpio5 9 GPIO_ACTIVE_LOW + &gpio3 2 GPIO_ACTIVE_LOW + &gpio5 25 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <19 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 24 GPIO_ACTIVE_LOW>; + slot-number = <7>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <22 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; + slot-number = <8>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + can@2 { // reg vdd? + compatible = "microchip,mcp25625"; + reg = <2>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can1>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can1_stby>; + }; + + can@3 { + compatible = "microchip,mcp25625"; + reg = <3>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <13 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can2>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can2_stby>; + }; +}; + +&ecspi3 { + pinctrl-0 = <&pinctrl_ecspi3>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 4 GPIO_ACTIVE_LOW + &gpio1 10 GPIO_ACTIVE_LOW + &gpio5 5 GPIO_ACTIVE_LOW + &gpio5 4 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <6 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 8 GPIO_ACTIVE_LOW>; + slot-number = <1>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio5>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 11 GPIO_ACTIVE_LOW>; + slot-number = <2>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + can@2 { + compatible = "microchip,mcp25625"; + reg = <2>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <12 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can3>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can3_stby>; + }; + + can@3 { + compatible = "microchip,mcp25625"; + reg = <3>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <18 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can4>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can4_stby>; + }; +}; + +&gpu_2d { + status = "disabled"; +}; + +&gpu_3d { + status = "disabled"; +}; + +&i2c2 { + clock-frequency = <400000>; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c2>; + pinctrl-1 = <&pinctrl_i2c2_gpio>; + scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; +}; + +&i2c3 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c3>; + pinctrl-1 = <&pinctrl_i2c3_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + lp5012@14 { + compatible = "ti,lp5012"; + reg = <0x14>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + color = <LED_COLOR_ID_RGB>; + label = "case-led1"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_RGB>; + label = "case-led2"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_RGB>; + label = "case-led3"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + + multi-led@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + color = <LED_COLOR_ID_RGB>; + label = "case-led4"; + + led@0 { + color = <LED_COLOR_ID_RED>; + reg = <0>; + }; + + led@1 { + color = <LED_COLOR_ID_GREEN>; + reg = <1>; + }; + + led@2 { + color = <LED_COLOR_ID_BLUE>; + reg = <2>; + }; + }; + }; +}; + +&iomuxc { + pinctrl_bt: btgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 + MX8MM_DSE_X1 + >; + }; + + pinctrl_can1: can1grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_ALE_GPIO3_IO0 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_CE3_B_GPIO3_IO4 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can1_reg: can1reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_READY_B_GPIO3_IO16 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can2: can2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA07_GPIO3_IO13 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can2_reg: can2reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_WE_B_GPIO3_IO17 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can3: can3grp { + fsl,pins = < + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA06_GPIO3_IO12 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can3_reg: can3reggrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can4: can4grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DQS_GPIO3_IO14 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_WP_B_GPIO3_IO18 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can4_reg: can4reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DATA02_GPIO3_IO8 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_ecspi1: ecspi1grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23 + MX8MM_DSE_X1 + MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2 + MX8MM_DSE_X1 + MX8MM_IOMUXC_UART2_TXD_GPIO5_IO25 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi3: ecspi3grp { + fsl,pins = < + MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 + MX8MM_DSE_X1 + >; + }; + + pinctrl_i2c2: i2c2grp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c2_gpio: i2c2-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3: i2c3grp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3_gpio: i2c3-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_reg_m2: reg-m2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI1_RXD6_GPIO4_IO8 + MX8MM_DSE_X1 + >; + }; + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart2: uart2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart3: uart3grp { + fsl,pins = < + MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart4: uart4grp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc2: pinctrlusdhc2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + >; + }; + + pinctrl_wl_int: wlintgrp { + fsl,pins = < + MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_wl_reg: wlreggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_CE2_B_GPIO3_IO3 + MX8MM_DSE_X1 + >; + }; +}; + +&uart1 { + pinctrl-0 = <&pinctrl_uart1>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt"; + device-wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH>; + interrupt-names = "host-wakeup"; + interrupt-parent = <&gpio3>; + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; + max-speed = <921600>; + pinctrl-0 = <&pinctrl_bt>; + pinctrl-names = "default"; + shutdown-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; + vbat-supply = <®_3v3_m2>; + vddio-supply = <®_3v3_m2>; + }; +}; + +&uart2 { + pinctrl-0 = <&pinctrl_uart2>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; +}; + +&uart3 { + pinctrl-0 = <&pinctrl_uart3>; + pinctrl-names = "default"; + status = "okay"; +}; + +&uart4 { + pinctrl-0 = <&pinctrl_uart4>; + pinctrl-names = "default"; + status = "okay"; +}; + +&usbotg1 { + disable-over-current; + dr_mode = "peripheral"; + status = "okay"; +}; + +&usbotg2 { + disable-over-current; + dr_mode = "host"; + vbus-supply = <®_5v0>; + status = "okay"; +}; + +&usdhc2 { + #address-cells = <1>; + #size-cells = <0>; + cap-power-off-card; + keep-power-in-suspend; + max-frequency = <50000000>; + mmc-pwrseq = <&wifi_pwrseq>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc2>; + pinctrl-names = "default"; + sd-uhs-sdr25; + vmmc-supply = <®_3v3_m2>; + status = "okay"; + + wifi@1 { + compatible = "infineon,cyw43439-fmac", "brcm,bcm4329-fmac"; + reg = <1>; + pinctrl-0 = <&pinctrl_wl_int>; + pinctrl-names = "default"; + interrupt-names = "host-wake"; + interrupt-parent = <&gpio3>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + brcm,board-type = "GOcontroll,moduline"; + }; +}; + +&vpu_blk_ctrl { + status = "disabled"; +}; + +&vpu_g1 { + status = "disabled"; +}; + +&vpu_g2 { + status = "disabled"; +}; + +&wdog1 { + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV 2025-10-22 7:22 ` Maud Spierings via B4 Relay (?) @ 2025-10-22 7:57 ` Marc Kleine-Budde 2025-10-22 8:23 ` Maud Spierings -1 siblings, 1 reply; 34+ messages in thread From: Marc Kleine-Budde @ 2025-10-22 7:57 UTC (permalink / raw) To: Maud Spierings via B4 Relay Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, Maud Spierings, linux-kernel, linux-arm-kernel, imx [-- Attachment #1: Type: text/plain, Size: 721 bytes --] On 22.10.2025 09:22:40, Maud Spierings via B4 Relay wrote: > + can@2 { // reg vdd? What about this comment? > + compatible = "microchip,mcp25625"; > + reg = <2>; > + clocks = <&mcp_clock>; > + interrupt-parent = <&gpio3>; > + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; > + pinctrl-0 = <&pinctrl_can1>; > + pinctrl-names = "default"; > + spi-max-frequency = <10000000>; > + xceiver-supply = <®_can1_stby>; > + }; regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung Nürnberg | Phone: +49-5121-206917-129 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV 2025-10-22 7:57 ` Marc Kleine-Budde @ 2025-10-22 8:23 ` Maud Spierings 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 8:23 UTC (permalink / raw) To: Marc Kleine-Budde, Maud Spierings via B4 Relay Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, devicetree, linux-kernel, linux-arm-kernel, imx Hi Marc, Thanks for the review On 10/22/25 09:57, Marc Kleine-Budde wrote: > On 22.10.2025 09:22:40, Maud Spierings via B4 Relay wrote: >> + can@2 { // reg vdd? > > What about this comment? Thought I resolved that oops, will be fixed in the next version >> + compatible = "microchip,mcp25625"; >> + reg = <2>; >> + clocks = <&mcp_clock>; >> + interrupt-parent = <&gpio3>; >> + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; >> + pinctrl-0 = <&pinctrl_can1>; >> + pinctrl-names = "default"; >> + spi-max-frequency = <10000000>; >> + xceiver-supply = <®_can1_stby>; >> + }; Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV 2025-10-22 7:22 ` Maud Spierings via B4 Relay (?) (?) @ 2025-10-22 10:18 ` Maud Spierings -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 10:18 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel > +/* SPI 2 */ > +&ecspi1 { > + pinctrl-0 = <&pinctrl_ecspi1>; > + pinctrl-names = "default"; This is bad, missed this. Will be fixed in the next version, same for the mini devicetree and all spi interfaces. > + cs-gpios = < > + &gpio1 9 GPIO_ACTIVE_LOW > + &gpio1 0 GPIO_ACTIVE_LOW > + &gpio5 2 GPIO_ACTIVE_LOW > + &gpio4 27 GPIO_ACTIVE_LOW > + &gpio3 1 GPIO_ACTIVE_LOW > + >; > + status = "okay"; Kind regards, Maud ^ permalink raw reply [flat|nested] 34+ messages in thread
* [PATCH v2 5/5] arm64: dts: freescale: Add the GOcontroll Moduline Mini 2025-10-22 7:22 ` Maud Spierings via B4 Relay @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay -1 siblings, 0 replies; 34+ messages in thread From: Maud Spierings @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings The Moduline Mini is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 4 Moduline IO modules - 2 CAN busses - 1 Ethernet - 4 RGB leds - 1 3D accelerometer - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/Makefile | 1 + .../imx8mm-tx8m-1610-moduline-mini-111.dts | 691 +++++++++++++++++++++ 2 files changed, 692 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index b2fef44e0a370..0a84c7dc89e39 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@ -125,6 +125,7 @@ imx8mm-evkb-pcie-ep-dtbs += imx8mm-evkb.dtb imx-pcie0-ep.dtbo dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk-pcie-ep.dtb imx8mm-evkb-pcie-ep.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb +dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-mini-111.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-ctouch2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-edimm2.2.dtb diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts new file mode 100644 index 0000000000000..651524781a7ba --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts @@ -0,0 +1,691 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +/dts-v1/; + +#include "imx8mm-tx8m-1610.dtsi" +#include <dt-bindings/leds/common.h> + +/ { + chassis-type = "embedded"; + compatible = "gocontroll,moduline-mini", "fsl,imx8mm"; + hardware = "Moduline Mini V1.11"; + model = "GOcontroll Moduline Mini"; + + aliases { + usb-host = &usbotg2; + usbotg = &usbotg1; + spi0 = &ecspi2; /* spidev number compatibility */ + spi1 = &ecspi3; /* spidev number compatibility */ + spi2 = &ecspi1; /* spidev number compatibility */ + }; + + chosen { + stdout-path = "serial2:115200n8"; + }; + + mcp_clock: mcp-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <20000000>; + }; + + reg_3v3_comm: regulator-3v3-communication { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_comm>; + pinctrl-names = "default"; + power-supply = <®_6v4>; + /* also powers the cellular modem which can't vote on the regulator */ + regulator-always-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3_comm"; + }; + + reg_5v0: regulator-5v0 { + compatible = "regulator-fixed"; + power-supply = <®_6v4>; + regulator-always-on; + regulator-max-microvolt = <5000000>; + regulator-min-microvolt = <5000000>; + regulator-name = "5v0"; + }; + + reg_6v4: regulator-6v4 { + compatible = "regulator-fixed"; + regulator-always-on; + regulator-max-microvolt = <6400000>; + regulator-min-microvolt = <6400000>; + regulator-name = "6v4"; + }; + + reg_can1_stby: regulator-can1-stby { + compatible = "regulator-fixed"; + gpio = <&gpio2 12 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can1_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can1-stby"; + }; + + reg_can2_stby: regulator-can2-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 15 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can2_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can2-stby"; + }; + + wifi_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-0 = <&pinctrl_wl_reg>; + pinctrl-names = "default"; + post-power-on-delay-ms = <100>; + power-off-delay-us = <500000>; + reset-gpios = <&gpio5 28 GPIO_ACTIVE_LOW>; + }; +}; + +&ecspi1 { + pinctrl-0 = <&pinctrl_ecspi1>; + pinctrl-names = "default"; + cs-gpios = < + &gpio4 27 GPIO_ACTIVE_LOW + &gpio3 23 GPIO_ACTIVE_LOW + &gpio3 1 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio4>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>; + slot-number = <3>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <19 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; + slot-number = <4>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + adc@2 { + compatible = "microchip,mcp3004"; + reg = <2>; + spi-max-frequency = <2300000>; + vref-supply = <®_vdd_3v3>; + }; +}; + +&ecspi2 { + pinctrl-0 = <&pinctrl_ecspi2>; + pinctrl-names = "default"; + cs-gpios = < + &gpio3 24 GPIO_ACTIVE_LOW + &gpio3 9 GPIO_ACTIVE_LOW + >; + status = "okay"; + + can@0 { + compatible = "microchip,mcp25625"; + reg = <0>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <22 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can1>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can1_stby>; + }; + + can@1 { + compatible = "microchip,mcp25625"; + reg = <1>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <6 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can2>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can2_stby>; + }; +}; + +&ecspi3 { + pinctrl-0 = <&pinctrl_ecspi3>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 9 GPIO_ACTIVE_LOW + &gpio1 2 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <10 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + slot-number = <1>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>; + slot-number = <2>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; +}; + +&gpu_2d { + status = "disabled"; +}; + +&gpu_3d { + status = "disabled"; +}; + +&i2c2 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c2>; + pinctrl-1 = <&pinctrl_i2c2_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; +}; + +&i2c3 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c3>; + pinctrl-1 = <&pinctrl_i2c3_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + lp5012@14 { + compatible = "ti,lp5012"; + reg = <0x14>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + color = <LED_COLOR_ID_RGB>; + label = "case-led1"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_RGB>; + label = "case-led2"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_RGB>; + label = "case-led3"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + color = <LED_COLOR_ID_RGB>; + label = "case-led4"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + + accelerometer@18 { + compatible = "st,lis2dw12"; + reg = <0x18>; + interrupt-parent = <&gpio5>; + interrupts = <3 IRQ_TYPE_EDGE_RISING>, <5 IRQ_TYPE_EDGE_RISING>; + pinctrl-0 = <&pinctrl_lis_int>; + pinctrl-names = "default"; + vddio-supply = <®_vdd_3v3>; + vdd-supply = <®_vdd_3v3>; + }; + + humidity-sensor@5f { + compatible = "st,hts221"; + reg = <0x5f>; + interrupt-parent = <&gpio3>; + interrupts = <10 IRQ_TYPE_EDGE_RISING>; + pinctrl-0 = <&pinctrl_hts_int>; + pinctrl-names = "default"; + vdd-supply = <®_vdd_3v3>; + }; +}; + +&iomuxc { + pinctrl_bt: btgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 + MX8MM_DSE_X1 + >; + }; + + pinctrl_can1: can1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can1_reg: can1reggrp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can2: can2grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_CLE_GPIO3_IO5 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can2_reg: can2reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_RE_B_GPIO3_IO15 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_ecspi1: ecspi1grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_DATA03_GPIO3_IO9 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi3: ecspi3grp { + fsl,pins = < + MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO02_GPIO1_IO2 + MX8MM_DSE_X1 + >; + }; + + pinctrl_hts_int: htsintgrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO10 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_i2c2: i2c2grp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c2_gpio: i2c2-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3: i2c3grp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3_gpio: i2c3-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_lis_int: lisintgrp { + fsl,pins = < + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_reg_comm: reg_commgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11 + MX8MM_DSE_X1 + >; + }; + + pinctrl_sysfs_gpios: sysfsgpiogrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 + MX8MM_DSE_X1 + MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6 + MX8MM_DSE_X1 + >; + }; + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart2: uart2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart3: uart3grp { + fsl,pins = < + MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc2: pinctrlusdhc2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + >; + }; + + pinctrl_wl_int: wlintgrp { + fsl,pins = < + MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_wl_reg: wlreggrp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_GPIO5_IO28 + MX8MM_DSE_X1 + >; + }; +}; + +&uart1 { + pinctrl-0 = <&pinctrl_uart1>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt"; + device-wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH>; + interrupt-names = "host-wakeup"; + interrupt-parent = <&gpio3>; + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; + max-speed = <921600>; + pinctrl-0 = <&pinctrl_bt>; + pinctrl-names = "default"; + shutdown-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; + vbat-supply = <®_3v3_comm>; + vddio-supply = <®_3v3_comm>; + }; +}; + +&uart2 { + pinctrl-0 = <&pinctrl_uart2>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; +}; + +&uart3 { + pinctrl-0 = <&pinctrl_uart3>; + pinctrl-names = "default"; + status = "okay"; +}; + +&usbotg1 { + disable-over-current; + dr_mode = "peripheral"; + status = "okay"; +}; + +&usbotg2 { + disable-over-current; + dr_mode = "host"; + vbus-supply = <®_5v0>; + status = "okay"; +}; + +&usdhc2 { + #address-cells = <1>; + #size-cells = <0>; + cap-power-off-card; + keep-power-in-suspend; + max-frequency = <50000000>; + mmc-pwrseq = <&wifi_pwrseq>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc2>; + pinctrl-names = "default"; + sd-uhs-sdr25; + vmmc-supply = <®_3v3_comm>; + status = "okay"; + + wifi@1 { + compatible = "infineon,cyw43439-fmac", "brcm,bcm4329-fmac"; + reg = <1>; + pinctrl-0 = <&pinctrl_wl_int>; + pinctrl-names = "default"; + interrupt-names = "host-wake"; + interrupt-parent = <&gpio3>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + brcm,board-type = "GOcontroll,moduline"; + }; +}; + +&vpu_blk_ctrl { + status = "disabled"; +}; + +&vpu_g1 { + status = "disabled"; +}; + +&vpu_g2 { + status = "disabled"; +}; + +&wdog1 { + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [PATCH v2 5/5] arm64: dts: freescale: Add the GOcontroll Moduline Mini @ 2025-10-22 7:22 ` Maud Spierings via B4 Relay 0 siblings, 0 replies; 34+ messages in thread From: Maud Spierings via B4 Relay @ 2025-10-22 7:22 UTC (permalink / raw) To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam Cc: devicetree, linux-kernel, imx, linux-arm-kernel, Maud Spierings From: Maud Spierings <maudspierings@gocontroll.com> The Moduline Mini is a part of the wider GOcontroll Moduline ecosystem. These are embedded controllers that focus on modularity with their swappable IO modules. Features: - up to 4 Moduline IO modules - 2 CAN busses - 1 Ethernet - 4 RGB leds - 1 3D accelerometer - optional Wi-Fi/Bluetooth - optional 4G/GPS Signed-off-by: Maud Spierings <maudspierings@gocontroll.com> --- arch/arm64/boot/dts/freescale/Makefile | 1 + .../imx8mm-tx8m-1610-moduline-mini-111.dts | 691 +++++++++++++++++++++ 2 files changed, 692 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile index b2fef44e0a370..0a84c7dc89e39 100644 --- a/arch/arm64/boot/dts/freescale/Makefile +++ b/arch/arm64/boot/dts/freescale/Makefile @@ -125,6 +125,7 @@ imx8mm-evkb-pcie-ep-dtbs += imx8mm-evkb.dtb imx-pcie0-ep.dtbo dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk-pcie-ep.dtb imx8mm-evkb-pcie-ep.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb +dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-mini-111.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-ctouch2.dtb dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-edimm2.2.dtb diff --git a/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts new file mode 100644 index 0000000000000..651524781a7ba --- /dev/null +++ b/arch/arm64/boot/dts/freescale/imx8mm-tx8m-1610-moduline-mini-111.dts @@ -0,0 +1,691 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* + * Copyright (C) 2025 Maud Spierings <maudspierings@gocontroll.com> + */ + +/dts-v1/; + +#include "imx8mm-tx8m-1610.dtsi" +#include <dt-bindings/leds/common.h> + +/ { + chassis-type = "embedded"; + compatible = "gocontroll,moduline-mini", "fsl,imx8mm"; + hardware = "Moduline Mini V1.11"; + model = "GOcontroll Moduline Mini"; + + aliases { + usb-host = &usbotg2; + usbotg = &usbotg1; + spi0 = &ecspi2; /* spidev number compatibility */ + spi1 = &ecspi3; /* spidev number compatibility */ + spi2 = &ecspi1; /* spidev number compatibility */ + }; + + chosen { + stdout-path = "serial2:115200n8"; + }; + + mcp_clock: mcp-clock { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <20000000>; + }; + + reg_3v3_comm: regulator-3v3-communication { + compatible = "regulator-fixed"; + enable-active-high; + gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>; + pinctrl-0 = <&pinctrl_reg_comm>; + pinctrl-names = "default"; + power-supply = <®_6v4>; + /* also powers the cellular modem which can't vote on the regulator */ + regulator-always-on; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "3v3_comm"; + }; + + reg_5v0: regulator-5v0 { + compatible = "regulator-fixed"; + power-supply = <®_6v4>; + regulator-always-on; + regulator-max-microvolt = <5000000>; + regulator-min-microvolt = <5000000>; + regulator-name = "5v0"; + }; + + reg_6v4: regulator-6v4 { + compatible = "regulator-fixed"; + regulator-always-on; + regulator-max-microvolt = <6400000>; + regulator-min-microvolt = <6400000>; + regulator-name = "6v4"; + }; + + reg_can1_stby: regulator-can1-stby { + compatible = "regulator-fixed"; + gpio = <&gpio2 12 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can1_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can1-stby"; + }; + + reg_can2_stby: regulator-can2-stby { + compatible = "regulator-fixed"; + gpio = <&gpio3 15 GPIO_ACTIVE_LOW>; + pinctrl-0 = <&pinctrl_can2_reg>; + pinctrl-names = "default"; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <3300000>; + regulator-name = "can2-stby"; + }; + + wifi_pwrseq: wifi-pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-0 = <&pinctrl_wl_reg>; + pinctrl-names = "default"; + post-power-on-delay-ms = <100>; + power-off-delay-us = <500000>; + reset-gpios = <&gpio5 28 GPIO_ACTIVE_LOW>; + }; +}; + +&ecspi1 { + pinctrl-0 = <&pinctrl_ecspi1>; + pinctrl-names = "default"; + cs-gpios = < + &gpio4 27 GPIO_ACTIVE_LOW + &gpio3 23 GPIO_ACTIVE_LOW + &gpio3 1 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio4>; + interrupts = <26 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio4 28 GPIO_ACTIVE_LOW>; + slot-number = <3>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio3>; + interrupts = <19 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; + slot-number = <4>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + adc@2 { + compatible = "microchip,mcp3004"; + reg = <2>; + spi-max-frequency = <2300000>; + vref-supply = <®_vdd_3v3>; + }; +}; + +&ecspi2 { + pinctrl-0 = <&pinctrl_ecspi2>; + pinctrl-names = "default"; + cs-gpios = < + &gpio3 24 GPIO_ACTIVE_LOW + &gpio3 9 GPIO_ACTIVE_LOW + >; + status = "okay"; + + can@0 { + compatible = "microchip,mcp25625"; + reg = <0>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <22 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can1>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can1_stby>; + }; + + can@1 { + compatible = "microchip,mcp25625"; + reg = <1>; + clocks = <&mcp_clock>; + interrupt-parent = <&gpio3>; + interrupts = <6 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&pinctrl_can2>; + pinctrl-names = "default"; + spi-max-frequency = <10000000>; + xceiver-supply = <®_can2_stby>; + }; +}; + +&ecspi3 { + pinctrl-0 = <&pinctrl_ecspi3>; + pinctrl-names = "default"; + cs-gpios = < + &gpio1 9 GPIO_ACTIVE_LOW + &gpio1 2 GPIO_ACTIVE_LOW + >; + status = "okay"; + + connector@0 { + compatible = "gocontroll,moduline-module-slot"; + reg = <0>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <10 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>; + slot-number = <1>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; + + connector@1 { + compatible = "gocontroll,moduline-module-slot"; + reg = <1>; + i2c-bus = <&i2c2>; + interrupt-parent = <&gpio1>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio5 21 GPIO_ACTIVE_LOW>; + slot-number = <2>; + spi-max-frequency = <54000000>; + sync-gpios = <&gpio3 7 GPIO_ACTIVE_HIGH>; + vddhpp-supply = <®_6v4>; + vddp-supply = <®_5v0>; + vdd-supply = <®_vdd_3v3>; + }; +}; + +&gpu_2d { + status = "disabled"; +}; + +&gpu_3d { + status = "disabled"; +}; + +&i2c2 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c2>; + pinctrl-1 = <&pinctrl_i2c2_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; +}; + +&i2c3 { + clock-frequency = <400000>; + pinctrl-0 = <&pinctrl_i2c3>; + pinctrl-1 = <&pinctrl_i2c3_gpio>; + pinctrl-names = "default", "gpio"; + scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + status = "okay"; + + lp5012@14 { + compatible = "ti,lp5012"; + reg = <0x14>; + #address-cells = <1>; + #size-cells = <0>; + + multi-led@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + color = <LED_COLOR_ID_RGB>; + label = "case-led1"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + color = <LED_COLOR_ID_RGB>; + label = "case-led2"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + color = <LED_COLOR_ID_RGB>; + label = "case-led3"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + + multi-led@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + color = <LED_COLOR_ID_RGB>; + label = "case-led4"; + + led@0 { + reg = <0>; + color = <LED_COLOR_ID_RED>; + }; + + led@1 { + reg = <1>; + color = <LED_COLOR_ID_GREEN>; + }; + + led@2 { + reg = <2>; + color = <LED_COLOR_ID_BLUE>; + }; + }; + }; + + accelerometer@18 { + compatible = "st,lis2dw12"; + reg = <0x18>; + interrupt-parent = <&gpio5>; + interrupts = <3 IRQ_TYPE_EDGE_RISING>, <5 IRQ_TYPE_EDGE_RISING>; + pinctrl-0 = <&pinctrl_lis_int>; + pinctrl-names = "default"; + vddio-supply = <®_vdd_3v3>; + vdd-supply = <®_vdd_3v3>; + }; + + humidity-sensor@5f { + compatible = "st,hts221"; + reg = <0x5f>; + interrupt-parent = <&gpio3>; + interrupts = <10 IRQ_TYPE_EDGE_RISING>; + pinctrl-0 = <&pinctrl_hts_int>; + pinctrl-names = "default"; + vdd-supply = <®_vdd_3v3>; + }; +}; + +&iomuxc { + pinctrl_bt: btgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO01_GPIO1_IO1 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 + MX8MM_DSE_X1 + >; + }; + + pinctrl_can1: can1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_TXC_GPIO4_IO25 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI5_RXD1_GPIO3_IO22 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can1_reg: can1reggrp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_can2: can2grp { + fsl,pins = < + MX8MM_IOMUXC_NAND_CLE_GPIO3_IO5 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_NAND_DATA00_GPIO3_IO6 + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_can2_reg: can2reggrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_RE_B_GPIO3_IO15 + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_ecspi1: ecspi1grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO27 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_RXD2_GPIO3_IO23 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_CE0_B_GPIO3_IO1 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MM_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_ECSPI2_MISO_ECSPI2_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_SAI5_RXD3_GPIO3_IO24 + MX8MM_DSE_X1 + MX8MM_IOMUXC_NAND_DATA03_GPIO3_IO9 + MX8MM_DSE_X1 + >; + }; + + pinctrl_ecspi3: ecspi3grp { + fsl,pins = < + MX8MM_IOMUXC_UART1_TXD_ECSPI3_MOSI + MX8MM_DSE_X4 + MX8MM_IOMUXC_UART2_RXD_ECSPI3_MISO + (MX8MM_DSE_X4 | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_UART1_RXD_ECSPI3_SCLK + MX8MM_DSE_X4 + MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO02_GPIO1_IO2 + MX8MM_DSE_X1 + >; + }; + + pinctrl_hts_int: htsintgrp { + fsl,pins = < + MX8MM_IOMUXC_NAND_DATA04_GPIO3_IO10 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_i2c2: i2c2grp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c2_gpio: i2c2-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3: i2c3grp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_i2c3_gpio: i2c3-gpiogrp { + fsl,pins = < + MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 + MX8MM_I2C_DEFAULT + MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 + MX8MM_I2C_DEFAULT + >; + }; + + pinctrl_lis_int: lisintgrp { + fsl,pins = < + MX8MM_IOMUXC_SPDIF_TX_GPIO5_IO3 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 + (MX8MM_PULL_ENABLE | MX8MM_HYS_SCHMITT) + >; + }; + + pinctrl_reg_comm: reg_commgrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO11_GPIO1_IO11 + MX8MM_DSE_X1 + >; + }; + + pinctrl_sysfs_gpios: sysfsgpiogrp { + fsl,pins = < + MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 + MX8MM_DSE_X1 + MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI3_RXFS_GPIO4_IO28 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SAI5_RXD0_GPIO3_IO21 + MX8MM_DSE_X1 + MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 + MX8MM_DSE_X1 + MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6 + MX8MM_DSE_X1 + >; + }; + + pinctrl_uart1: uart1grp { + fsl,pins = < + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart2: uart2grp { + fsl,pins = < + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_uart3: uart3grp { + fsl,pins = < + MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX + (MX8MM_PULL_UP | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_usdhc2: pinctrlusdhc2grp { + fsl,pins = < + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK + (MX8MM_DSE_X2 | MX8MM_FSEL_FAST | MX8MM_PULL_ENABLE) + MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 + (MX8MM_DSE_X2 | MX8MM_USDHC_DATA_DEFAULT) + >; + }; + + pinctrl_wl_int: wlintgrp { + fsl,pins = < + MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20 + (MX8MM_PULL_UP | MX8MM_HYS_SCHMITT | MX8MM_PULL_ENABLE) + >; + }; + + pinctrl_wl_reg: wlreggrp { + fsl,pins = < + MX8MM_IOMUXC_UART4_RXD_GPIO5_IO28 + MX8MM_DSE_X1 + >; + }; +}; + +&uart1 { + pinctrl-0 = <&pinctrl_uart1>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; + + bluetooth { + compatible = "infineon,cyw43439-bt", "brcm,bcm4329-bt"; + device-wakeup-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH>; + interrupt-names = "host-wakeup"; + interrupt-parent = <&gpio3>; + interrupts = <25 IRQ_TYPE_EDGE_FALLING>; + max-speed = <921600>; + pinctrl-0 = <&pinctrl_bt>; + pinctrl-names = "default"; + shutdown-gpios = <&gpio1 1 GPIO_ACTIVE_HIGH>; + vbat-supply = <®_3v3_comm>; + vddio-supply = <®_3v3_comm>; + }; +}; + +&uart2 { + pinctrl-0 = <&pinctrl_uart2>; + pinctrl-names = "default"; + uart-has-rtscts; + status = "okay"; +}; + +&uart3 { + pinctrl-0 = <&pinctrl_uart3>; + pinctrl-names = "default"; + status = "okay"; +}; + +&usbotg1 { + disable-over-current; + dr_mode = "peripheral"; + status = "okay"; +}; + +&usbotg2 { + disable-over-current; + dr_mode = "host"; + vbus-supply = <®_5v0>; + status = "okay"; +}; + +&usdhc2 { + #address-cells = <1>; + #size-cells = <0>; + cap-power-off-card; + keep-power-in-suspend; + max-frequency = <50000000>; + mmc-pwrseq = <&wifi_pwrseq>; + non-removable; + pinctrl-0 = <&pinctrl_usdhc2>; + pinctrl-names = "default"; + sd-uhs-sdr25; + vmmc-supply = <®_3v3_comm>; + status = "okay"; + + wifi@1 { + compatible = "infineon,cyw43439-fmac", "brcm,bcm4329-fmac"; + reg = <1>; + pinctrl-0 = <&pinctrl_wl_int>; + pinctrl-names = "default"; + interrupt-names = "host-wake"; + interrupt-parent = <&gpio3>; + interrupts = <20 IRQ_TYPE_LEVEL_LOW>; + brcm,board-type = "GOcontroll,moduline"; + }; +}; + +&vpu_blk_ctrl { + status = "disabled"; +}; + +&vpu_g1 { + status = "disabled"; +}; + +&vpu_g2 { + status = "disabled"; +}; + +&wdog1 { + status = "okay"; +}; -- 2.51.1 ^ permalink raw reply related [flat|nested] 34+ messages in thread
end of thread, other threads:[~2025-10-31 12:07 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-10-22 7:22 [PATCH v2 0/5] arm64: dts: freescale: add support for the GOcontroll Moduline IV/Mini Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay 2025-10-22 7:22 ` [PATCH v2 1/5] dt-bindings: arm: fsl: Add " Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay 2025-10-22 7:22 ` [PATCH v2 2/5] arm64: dts: imx8mm: Add pinctrl config definitions Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay 2025-10-22 7:22 ` [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay 2025-10-28 12:15 ` Matti Vaittinen 2025-10-28 12:42 ` Maud Spierings 2025-10-28 13:10 ` Maud Spierings 2025-10-29 7:11 ` Lothar Waßmann 2025-10-29 8:42 ` Matti Vaittinen 2025-10-29 9:00 ` Maud Spierings 2025-10-29 9:33 ` Matti Vaittinen 2025-10-29 9:48 ` Lothar Waßmann 2025-10-29 10:05 ` Matti Vaittinen 2025-10-29 15:35 ` Maud Spierings 2025-10-29 15:51 ` Maud Spierings 2025-10-29 19:04 ` Matti Vaittinen 2025-10-30 8:54 ` Lothar Waßmann 2025-10-30 11:01 ` Matti Vaittinen 2025-10-30 12:00 ` Lothar Waßmann 2025-10-31 12:07 ` Matti Vaittinen 2025-10-30 14:45 ` Maud Spierings 2025-10-31 5:36 ` Lothar Waßmann 2025-10-31 7:26 ` Maud Spierings 2025-10-22 7:22 ` [PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay 2025-10-22 7:57 ` Marc Kleine-Budde 2025-10-22 8:23 ` Maud Spierings 2025-10-22 10:18 ` Maud Spierings 2025-10-22 7:22 ` [PATCH v2 5/5] arm64: dts: freescale: Add the GOcontroll Moduline Mini Maud Spierings 2025-10-22 7:22 ` Maud Spierings via B4 Relay
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.