[v2] arm64: dts: freescale: add support for the GOcontroll Moduline IV/Mini

[PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings via B4 Relay 3 months, 2 weeks ago

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 = <&reg_vdd_arm>;
+};
+
+&A53_1 {
+	cpu-supply = <&reg_vdd_arm>;
+};
+
+&A53_2 {
+	cpu-supply = <&reg_vdd_arm>;
+};
+
+&A53_3 {
+	cpu-supply = <&reg_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 = <&ethphy0>;
+	phy-mode = "rmii";
+	phy-reset-duration = <25>;
+	phy-reset-gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
+	phy-reset-post-delay = <1>;
+	phy-supply = <&reg_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 = <&reg_vdd_3v3>;
+	vqmmc-supply = <&reg_vdd_1v8>;
+	status = "okay";
+};

-- 
2.51.1

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 2 weeks ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 2 weeks ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 2 weeks ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Lothar Waßmann 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Lothar Waßmann 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Lothar Waßmann 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Lothar Waßmann 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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! ~~

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Lothar Waßmann 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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! ~~

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 1 week ago


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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Maud Spierings 3 months, 1 week ago


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

Re: [PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM

Posted by Matti Vaittinen 3 months, 1 week ago

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

[PATCH v2 1/5] dt-bindings: arm: fsl: Add GOcontroll Moduline IV/Mini
[PATCH v2 2/5] arm64: dts: imx8mm: Add pinctrl config definitions
[PATCH v2 3/5] arm64: dts: freescale: add Ka-Ro Electronics tx8m-1610 COM
[PATCH v2 4/5] arm64: dts: freescale: Add the GOcontroll Moduline IV
[PATCH v2 5/5] arm64: dts: freescale: Add the GOcontroll Moduline Mini