[PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Svyatoslav Ryhel]

Since the proposed PMIC patches have been accepted, I see the need
to convert boards which I maintain to use DM drivers instead of board hacks.

Svyatoslav Ryhel (5):
  board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
  board: endeavoru: convert HTC One X to use DM PMIC
  board: transformer-t30: convert ASUS Transformers to use DM PMIC
  board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
  ARM: dts: tegra30: enable USB PHY node on some devices

 arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
 .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
 .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
 .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
 arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
 arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
 arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
 arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
 arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
 board/asus/grouper/Kconfig                    |   8 -
 board/asus/grouper/Makefile                   |   4 +-
 .../asus/grouper/configs/grouper_E1565.config |   6 +-
 .../asus/grouper/configs/grouper_PM269.config |   6 +-
 board/asus/grouper/configs/tilapia.config     |   6 +-
 board/asus/grouper/grouper-spl-max.c          |   2 +-
 board/asus/grouper/grouper-spl-ti.c           |   2 +-
 board/asus/grouper/grouper.c                  | 154 +-----------------
 board/asus/transformer-t30/Kconfig            |  10 --
 .../transformer-t30/configs/tf600t.config     |   2 +-
 .../transformer-t30/transformer-t30-spl.c     |   2 +-
 board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
 board/htc/endeavoru/endeavoru-spl.c           |   2 +-
 board/htc/endeavoru/endeavoru.c               |  72 +-------
 board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
 board/lg/x3-t30/x3-t30.c                      |  97 +----------
 configs/endeavoru_defconfig                   |   4 +
 configs/grouper_common_defconfig              |   1 +
 configs/transformer_t30_defconfig             |   5 +
 configs/x3_t30_defconfig                      |   4 +
 29 files changed, 128 insertions(+), 450 deletions(-)

-- 
2.40.1

[PATCH v1 1/5] board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC

[Svyatoslav Ryhel]

Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 arch/arm/dts/tegra30-lg-x3.dtsi |  1 +
 board/lg/x3-t30/x3-t30-spl.c    |  2 +-
 board/lg/x3-t30/x3-t30.c        | 97 ++-------------------------------
 configs/x3_t30_defconfig        |  4 ++
 4 files changed, 11 insertions(+), 93 deletions(-)

diff --git a/arch/arm/dts/tegra30-lg-x3.dtsi b/arch/arm/dts/tegra30-lg-x3.dtsi
index 6e52fc5a53..aa207a70c7 100644
--- a/arch/arm/dts/tegra30-lg-x3.dtsi
+++ b/arch/arm/dts/tegra30-lg-x3.dtsi
@@ -110,6 +110,7 @@
 					regulator-name = "vdd_ddr_rx";
 					regulator-min-microvolt = <2850000>;
 					regulator-max-microvolt = <2850000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/board/lg/x3-t30/x3-t30-spl.c b/board/lg/x3-t30/x3-t30-spl.c
index 864f2de45f..00f79dd1db 100644
--- a/board/lg/x3-t30/x3-t30-spl.c
+++ b/board/lg/x3-t30/x3-t30-spl.c
@@ -9,7 +9,7 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
+#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/tegra_i2c.h>
 #include <linux/delay.h>
 
diff --git a/board/lg/x3-t30/x3-t30.c b/board/lg/x3-t30/x3-t30.c
index a08e00dd87..2eaf16ded4 100644
--- a/board/lg/x3-t30/x3-t30.c
+++ b/board/lg/x3-t30/x3-t30.c
@@ -7,60 +7,14 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
 #include <dm.h>
 #include <fdt_support.h>
-#include <i2c.h>
-#include <log.h>
 #include <asm/arch/pinmux.h>
 #include <asm/arch/clock.h>
-#include <asm/arch/gpio.h>
-#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/fuse.h>
-#include <asm/gpio.h>
-#include <linux/delay.h>
-#include "pinmux-config-x3.h"
-
-#define MAX77663_I2C_ADDR		0x1C
-
-#define MAX77663_REG_SD2		0x18
-#define MAX77663_REG_LDO2		0x27
-#define MAX77663_REG_LDO3		0x29
-#define MAX77663_REG_LDO5		0x2D
-#define MAX77663_REG_ONOFF_CFG1		0x41
-#define   ONOFF_PWR_OFF			BIT(1)
-
-#ifdef CONFIG_CMD_POWEROFF
-int do_poweroff(struct cmd_tbl *cmdtp, int flag,
-		int argc, char *const argv[])
-{
-	struct udevice *dev;
-	uchar data_buffer[1];
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, MAX77663_I2C_ADDR, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return 0;
-	}
-
-	ret = dm_i2c_read(dev, MAX77663_REG_ONOFF_CFG1, data_buffer, 1);
-	if (ret)
-		return ret;
+#include <power/regulator.h>
 
-	data_buffer[0] |= ONOFF_PWR_OFF;
-
-	ret = dm_i2c_write(dev, MAX77663_REG_ONOFF_CFG1, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	/* wait some time and then print error */
-	mdelay(5000);
-
-	printf("Failed to power off!!!\n");
-	return 1;
-}
-#endif
+#include "pinmux-config-x3.h"
 
 /*
  * Routine: pinmux_init
@@ -82,52 +36,11 @@ void pinmux_init(void)
 #endif
 }
 
-#ifdef CONFIG_MMC_SDHCI_TEGRA
-static void max77663_voltage_init(void)
-{
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, MAX77663_I2C_ADDR, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return;
-	}
-
-	/* 0x60 for 1.8v, bit7:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_SD2, 0x60);
-	if (ret)
-		log_debug("vdd_1v8_vio set failed: %d\n", ret);
-
-	/* 0xF2 for 3.30v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_LDO2, 0xF2);
-	if (ret)
-		log_debug("avdd_usb set failed: %d\n", ret);
-
-	/* 0xEC for 3.00v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_LDO3, 0xEC);
-	if (ret)
-		log_debug("vdd_usd set failed: %d\n", ret);
-
-	/* 0xE9 for 2.85v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_LDO5, 0xE9);
-	if (ret)
-		log_debug("vcore_emmc set failed: %d\n", ret);
-}
-
-/*
- * Routine: pin_mux_mmc
- * Description: setup the MMC muxes, power rails, etc.
- */
-void pin_mux_mmc(void)
-{
-	/* Bring up uSD and eMMC power */
-	max77663_voltage_init();
-}
-#endif	/* MMC */
-
 int nvidia_board_init(void)
 {
+	/* Set up boot-on regulators */
+	regulators_enable_boot_on(true);
+
 	/* Set up panel bridge clocks */
 	clock_start_periph_pll(PERIPH_ID_EXTPERIPH3, CLOCK_ID_PERIPH,
 			       24 * 1000000);
diff --git a/configs/x3_t30_defconfig b/configs/x3_t30_defconfig
index a151f58524..90cbc2078a 100644
--- a/configs/x3_t30_defconfig
+++ b/configs/x3_t30_defconfig
@@ -45,6 +45,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_UMS_ABORT_KEYED=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_PAUSE=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -64,11 +65,14 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_BUTTON_KEYBOARD=y
 CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_MAX77663=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_REGULATOR_MAX77663=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_PWM_TEGRA=y
 CONFIG_SYS_NS16550=y
 CONFIG_TEGRA20_SLINK=y
+CONFIG_SYSRESET_MAX77663=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
-- 
2.40.1

[PATCH v1 2/5] board: endeavoru: convert HTC One X to use DM PMIC

[Svyatoslav Ryhel]

Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 arch/arm/dts/tegra30-htc-endeavoru.dts |  1 +
 board/htc/endeavoru/endeavoru-spl.c    |  2 +-
 board/htc/endeavoru/endeavoru.c        | 72 +++-----------------------
 configs/endeavoru_defconfig            |  4 ++
 4 files changed, 12 insertions(+), 67 deletions(-)

diff --git a/arch/arm/dts/tegra30-htc-endeavoru.dts b/arch/arm/dts/tegra30-htc-endeavoru.dts
index 5c7b2deae5..22320de708 100644
--- a/arch/arm/dts/tegra30-htc-endeavoru.dts
+++ b/arch/arm/dts/tegra30-htc-endeavoru.dts
@@ -81,6 +81,7 @@
 					regulator-name = "avdd_dsi_csi";
 					regulator-min-microvolt = <1200000>;
 					regulator-max-microvolt = <1200000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/board/htc/endeavoru/endeavoru-spl.c b/board/htc/endeavoru/endeavoru-spl.c
index 7921ff1a73..2525b50d3e 100644
--- a/board/htc/endeavoru/endeavoru-spl.c
+++ b/board/htc/endeavoru/endeavoru-spl.c
@@ -9,7 +9,7 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
+#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/tegra_i2c.h>
 #include <linux/delay.h>
 
diff --git a/board/htc/endeavoru/endeavoru.c b/board/htc/endeavoru/endeavoru.c
index e1a0b242e2..6835b1ee70 100644
--- a/board/htc/endeavoru/endeavoru.c
+++ b/board/htc/endeavoru/endeavoru.c
@@ -7,48 +7,12 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
 #include <dm.h>
 #include <fdt_support.h>
-#include <i2c.h>
-#include <log.h>
 #include <asm/arch/pinmux.h>
-#include <asm/arch/gp_padctrl.h>
-#include <asm/arch/gpio.h>
-#include <asm/gpio.h>
-#include <linux/delay.h>
-#include "pinmux-config-endeavoru.h"
-
-#define TPS80032_CTL1_I2C_ADDR		0x48
-#define TPS80032_PHOENIX_DEV_ON		0x25
-#define   DEVOFF			BIT(0)
-#define TPS80032_LDO1_CFG_STATE		0x9E
-#define TPS80032_LDO1_CFG_VOLTAGE	0x9F
-
-#ifdef CONFIG_CMD_POWEROFF
-int do_poweroff(struct cmd_tbl *cmdtp, int flag,
-		int argc, char *const argv[])
-{
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS80032_CTL1_I2C_ADDR, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return 0;
-	}
+#include <power/regulator.h>
 
-	ret = dm_i2c_reg_write(dev, TPS80032_PHOENIX_DEV_ON, DEVOFF);
-	if (ret)
-		return ret;
-
-	// wait some time and then print error
-	mdelay(5000);
-
-	printf("Failed to power off!!!\n");
-	return 1;
-}
-#endif
+#include "pinmux-config-endeavoru.h"
 
 /*
  * Routine: pinmux_init
@@ -60,37 +24,13 @@ void pinmux_init(void)
 		ARRAY_SIZE(endeavoru_pinmux_common));
 }
 
-#ifdef CONFIG_MMC_SDHCI_TEGRA
-static void tps80032_voltage_init(void)
+int nvidia_board_init(void)
 {
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS80032_CTL1_I2C_ADDR, 1, &dev);
-	if (ret)
-		log_debug("cannot find PMIC I2C chip\n");
-
-	/* TPS80032: LDO1_REG = 1.2v to DSI */
-	ret = dm_i2c_reg_write(dev, TPS80032_LDO1_CFG_VOLTAGE, 0x03);
-	if (ret)
-		log_debug("avdd_dsi_csi voltage set failed: %d\n", ret);
-
-	/* TPS80032: LDO1_REG enable */
-	ret = dm_i2c_reg_write(dev, TPS80032_LDO1_CFG_STATE, 0x01);
-	if (ret)
-		log_debug("avdd_dsi_csi enable failed: %d\n", ret);
-}
+	/* Set up boot-on regulators */
+	regulators_enable_boot_on(true);
 
-/*
- * Routine: pin_mux_mmc
- * Description: setup the MMC muxes, power rails, etc.
- */
-void pin_mux_mmc(void)
-{
-	/* Bring up DSI power */
-	tps80032_voltage_init();
+	return 0;
 }
-#endif	/* MMC */
 
 #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *blob, struct bd_info *bd)
diff --git a/configs/endeavoru_defconfig b/configs/endeavoru_defconfig
index d605acdfc8..7212675546 100644
--- a/configs/endeavoru_defconfig
+++ b/configs/endeavoru_defconfig
@@ -44,6 +44,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_UMS_ABORT_KEYED=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_PAUSE=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -61,10 +62,13 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
 CONFIG_SYS_I2C_TEGRA=y
 CONFIG_BUTTON_KEYBOARD=y
 CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_TPS80031=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_TPS80031=y
 CONFIG_PWM_TEGRA=y
 CONFIG_SYS_NS16550=y
+CONFIG_SYSRESET_TPS80031=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
-- 
2.40.1

[PATCH v1 3/5] board: transformer-t30: convert ASUS Transformers to use DM PMIC

[Svyatoslav Ryhel]

Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 arch/arm/dts/tegra30-asus-p1801-t.dts         |   2 +
 arch/arm/dts/tegra30-asus-tf600t.dts          |   4 +
 arch/arm/dts/tegra30-asus-transformer.dtsi    |   2 +
 board/asus/transformer-t30/Kconfig            |  10 --
 .../transformer-t30/configs/tf600t.config     |   2 +-
 .../transformer-t30/transformer-t30-spl.c     |   2 +-
 board/asus/transformer-t30/transformer-t30.c  | 121 +-----------------
 configs/transformer_t30_defconfig             |   5 +
 8 files changed, 21 insertions(+), 127 deletions(-)

diff --git a/arch/arm/dts/tegra30-asus-p1801-t.dts b/arch/arm/dts/tegra30-asus-p1801-t.dts
index 39f7caf8d0..d62d43268b 100644
--- a/arch/arm/dts/tegra30-asus-p1801-t.dts
+++ b/arch/arm/dts/tegra30-asus-p1801-t.dts
@@ -101,6 +101,7 @@
 					regulator-name = "vdd_emmc_core";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
 				};
 
 				/* uSD slot VDD */
@@ -108,6 +109,7 @@
 					regulator-name = "vdd_usd";
 					regulator-min-microvolt = <3100000>;
 					regulator-max-microvolt = <3100000>;
+					regulator-boot-on;
 				};
 
 				/* uSD slot VDDIO */
diff --git a/arch/arm/dts/tegra30-asus-tf600t.dts b/arch/arm/dts/tegra30-asus-tf600t.dts
index fd9d11ca19..efc6a83b9d 100644
--- a/arch/arm/dts/tegra30-asus-tf600t.dts
+++ b/arch/arm/dts/tegra30-asus-tf600t.dts
@@ -84,12 +84,14 @@
 					regulator-name = "vdd_1v2_backlight";
 					regulator-min-microvolt = <1200000>;
 					regulator-max-microvolt = <1200000>;
+					regulator-boot-on;
 				};
 
 				vcore_lcd: vdd2 {
 					regulator-name = "vcore_lcd";
 					regulator-min-microvolt = <1500000>;
 					regulator-max-microvolt = <1500000>;
+					regulator-boot-on;
 				};
 
 				vdd_1v8_vio: vddio {
@@ -105,6 +107,7 @@
 					regulator-name = "vdd_emmc_core";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
 				};
 
 				/* uSD slot VDDIO */
@@ -119,6 +122,7 @@
 					regulator-name = "avdd_dsi_csi";
 					regulator-min-microvolt = <1200000>;
 					regulator-max-microvolt = <1200000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/arch/arm/dts/tegra30-asus-transformer.dtsi b/arch/arm/dts/tegra30-asus-transformer.dtsi
index 888f9ca74e..afddb83983 100644
--- a/arch/arm/dts/tegra30-asus-transformer.dtsi
+++ b/arch/arm/dts/tegra30-asus-transformer.dtsi
@@ -82,6 +82,7 @@
 					regulator-name = "vdd_emmc_core";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
 				};
 
 				/* uSD slot VDD */
@@ -89,6 +90,7 @@
 					regulator-name = "vdd_usd";
 					regulator-min-microvolt = <3100000>;
 					regulator-max-microvolt = <3100000>;
+					regulator-boot-on;
 				};
 
 				/* uSD slot VDDIO */
diff --git a/board/asus/transformer-t30/Kconfig b/board/asus/transformer-t30/Kconfig
index accc999c43..915436ba6c 100644
--- a/board/asus/transformer-t30/Kconfig
+++ b/board/asus/transformer-t30/Kconfig
@@ -9,14 +9,4 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
 	default "transformer-t30"
 
-config TRANSFORMER_SPI_BOOT
-	bool "Enable support for SPI based flash"
-	select TEGRA20_SLINK
-	select DM_SPI_FLASH
-	select SPI_FLASH_WINBOND
-	help
-	  Tegra 3 based Transformers with Windows RT have core
-	  boot sequence (BCT and EBT) on separate SPI FLASH
-	  memory with 4MB size.
-
 endif
diff --git a/board/asus/transformer-t30/configs/tf600t.config b/board/asus/transformer-t30/configs/tf600t.config
index 18ab4fbd87..e40d0fdd47 100644
--- a/board/asus/transformer-t30/configs/tf600t.config
+++ b/board/asus/transformer-t30/configs/tf600t.config
@@ -1,4 +1,4 @@
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-asus-tf600t"
-CONFIG_TRANSFORMER_SPI_BOOT=y
 CONFIG_BOOTCOMMAND="setenv gpio_button 222; if run check_button; then poweroff; fi; setenv gpio_button 132; if run check_button; then echo Starting SPI flash update ...; run update_spi; fi; run bootcmd_usb0; run bootcmd_mmc1; run bootcmd_mmc0; poweroff;"
+CONFIG_SPI_FLASH_WINBOND=y
 CONFIG_USB_GADGET_PRODUCT_NUM=0x4d00
diff --git a/board/asus/transformer-t30/transformer-t30-spl.c b/board/asus/transformer-t30/transformer-t30-spl.c
index 89819b2b92..952e2c8224 100644
--- a/board/asus/transformer-t30/transformer-t30-spl.c
+++ b/board/asus/transformer-t30/transformer-t30-spl.c
@@ -9,7 +9,7 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
+#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/tegra_i2c.h>
 #include <linux/delay.h>
 
diff --git a/board/asus/transformer-t30/transformer-t30.c b/board/asus/transformer-t30/transformer-t30.c
index ba795a802e..29d77146bb 100644
--- a/board/asus/transformer-t30/transformer-t30.c
+++ b/board/asus/transformer-t30/transformer-t30.c
@@ -9,70 +9,13 @@
 
 /* T30 Transformers derive from Cardhu board */
 
-#include <common.h>
 #include <dm.h>
 #include <fdt_support.h>
-#include <i2c.h>
-#include <log.h>
 #include <asm/arch/pinmux.h>
 #include <asm/arch/gp_padctrl.h>
-#include <asm/arch/gpio.h>
-#include <asm/gpio.h>
-#include <linux/delay.h>
-#include "pinmux-config-transformer.h"
-
-#define TPS65911_I2C_ADDRESS		0x2D
-
-#define TPS65911_VDD1			0x21
-#define TPS65911_VDD1_OP		0x22
-#define TPS65911_LDO1			0x30
-#define TPS65911_LDO2			0x31
-#define TPS65911_LDO3			0x37
-#define TPS65911_LDO5			0x32
-#define TPS65911_LDO6			0x35
-
-#define TPS65911_DEVCTRL		0x3F
-#define   DEVCTRL_PWR_OFF_MASK		BIT(7)
-#define   DEVCTRL_DEV_ON_MASK		BIT(2)
-#define   DEVCTRL_DEV_OFF_MASK		BIT(0)
-
-#ifdef CONFIG_CMD_POWEROFF
-int do_poweroff(struct cmd_tbl *cmdtp, int flag,
-		int argc, char *const argv[])
-{
-	struct udevice *dev;
-	uchar data_buffer[1];
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS65911_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return 0;
-	}
+#include <power/regulator.h>
 
-	ret = dm_i2c_read(dev, TPS65911_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	data_buffer[0] |= DEVCTRL_PWR_OFF_MASK;
-
-	ret = dm_i2c_write(dev, TPS65911_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	data_buffer[0] |= DEVCTRL_DEV_OFF_MASK;
-	data_buffer[0] &= ~DEVCTRL_DEV_ON_MASK;
-
-	ret = dm_i2c_write(dev, TPS65911_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	// wait some time and then print error
-	mdelay(5000);
-	printf("Failed to power off!!!\n");
-	return 1;
-}
-#endif
+#include "pinmux-config-transformer.h"
 
 /*
  * Routine: pinmux_init
@@ -92,65 +35,13 @@ void pinmux_init(void)
 	}
 }
 
-#ifdef CONFIG_MMC_SDHCI_TEGRA
-static void tps65911_voltage_init(void)
+int nvidia_board_init(void)
 {
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS65911_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return;
-	}
-
-	/* TPS659110: LDO1_REG = 3.3v, ACTIVE to SDMMC4 */
-	ret = dm_i2c_reg_write(dev, TPS65911_LDO1, 0xc9);
-	if (ret)
-		log_debug("vcore_emmc set failed: %d\n", ret);
-
-	if (of_machine_is_compatible("asus,tf600t")) {
-		/* TPS659110: VDD1_REG = 1.2v, ACTIVE to backlight */
-		ret = dm_i2c_reg_write(dev, TPS65911_VDD1_OP, 0x33);
-		if (ret)
-			log_debug("vdd_bl set failed: %d\n", ret);
-
-		ret = dm_i2c_reg_write(dev, TPS65911_VDD1, 0x0d);
-		if (ret)
-			log_debug("vdd_bl enable failed: %d\n", ret);
-
-		/* TPS659110: LDO5_REG = 3.3v, ACTIVE to SDMMC1 VIO */
-		ret = dm_i2c_reg_write(dev, TPS65911_LDO5, 0x65);
-		if (ret)
-			log_debug("vdd_usd set failed: %d\n", ret);
-
-		/* TPS659110: LDO6_REG = 1.2v, ACTIVE to MIPI */
-		ret = dm_i2c_reg_write(dev, TPS65911_LDO6, 0x11);
-		if (ret)
-			log_debug("vdd_mipi set failed: %d\n", ret);
-	} else {
-		/* TPS659110: LDO2_REG = 3.1v, ACTIVE to SDMMC1 */
-		ret = dm_i2c_reg_write(dev, TPS65911_LDO2, 0xb9);
-		if (ret)
-			log_debug("vdd_usd set failed: %d\n", ret);
+	/* Set up boot-on regulators */
+	regulators_enable_boot_on(true);
 
-		/* TPS659110: LDO3_REG = 3.1v, ACTIVE to SDMMC1 VIO */
-		ret = dm_i2c_reg_write(dev, TPS65911_LDO3, 0x5d);
-		if (ret)
-			log_debug("vddio_usd set failed: %d\n", ret);
-	}
-}
-
-/*
- * Routine: pin_mux_mmc
- * Description: setup the MMC muxes, power rails, etc.
- */
-void pin_mux_mmc(void)
-{
-	/* Bring up uSD and eMMC power */
-	tps65911_voltage_init();
+	return 0;
 }
-#endif	/* MMC */
 
 #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *blob, struct bd_info *bd)
diff --git a/configs/transformer_t30_defconfig b/configs/transformer_t30_defconfig
index 092c0aa2b0..8d828c1fa6 100644
--- a/configs/transformer_t30_defconfig
+++ b/configs/transformer_t30_defconfig
@@ -45,6 +45,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_UMS_ABORT_KEYED=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_PAUSE=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
@@ -65,10 +66,14 @@ CONFIG_I2C_MUX=y
 CONFIG_I2C_MUX_GPIO=y
 CONFIG_BUTTON_KEYBOARD=y
 CONFIG_DM_PMIC=y
+CONFIG_DM_PMIC_TPS65910=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
+CONFIG_DM_REGULATOR_TPS65911=y
 CONFIG_PWM_TEGRA=y
 CONFIG_SYS_NS16550=y
+CONFIG_TEGRA20_SLINK=y
+CONFIG_SYSRESET_TPS65910=y
 CONFIG_USB=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_EHCI_TEGRA=y
-- 
2.40.1

[PATCH v1 4/5] board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC

[Svyatoslav Ryhel]

Since required drivers were merged, we can safely clean up the
board and switch to DM based driver with device tree support.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
 .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
 .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
 board/asus/grouper/Kconfig                    |   8 -
 board/asus/grouper/Makefile                   |   4 +-
 .../asus/grouper/configs/grouper_E1565.config |   6 +-
 .../asus/grouper/configs/grouper_PM269.config |   6 +-
 board/asus/grouper/configs/tilapia.config     |   6 +-
 board/asus/grouper/grouper-spl-max.c          |   2 +-
 board/asus/grouper/grouper-spl-ti.c           |   2 +-
 board/asus/grouper/grouper.c                  | 154 +-----------------
 configs/grouper_common_defconfig              |   1 +
 12 files changed, 29 insertions(+), 163 deletions(-)

diff --git a/arch/arm/dts/tegra30-asus-nexus7-grouper-E1565.dts b/arch/arm/dts/tegra30-asus-nexus7-grouper-E1565.dts
index 945ae404ac..bfc675ca92 100644
--- a/arch/arm/dts/tegra30-asus-nexus7-grouper-E1565.dts
+++ b/arch/arm/dts/tegra30-asus-nexus7-grouper-E1565.dts
@@ -35,6 +35,7 @@
 					regulator-name = "vcore_emmc";
 					regulator-min-microvolt = <2850000>;
 					regulator-max-microvolt = <2850000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/arch/arm/dts/tegra30-asus-nexus7-grouper-PM269.dts b/arch/arm/dts/tegra30-asus-nexus7-grouper-PM269.dts
index 4363bfc87d..cf03011bc1 100644
--- a/arch/arm/dts/tegra30-asus-nexus7-grouper-PM269.dts
+++ b/arch/arm/dts/tegra30-asus-nexus7-grouper-PM269.dts
@@ -36,6 +36,7 @@
 					regulator-name = "vdd_emmc_core";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/arch/arm/dts/tegra30-asus-nexus7-tilapia-E1565.dts b/arch/arm/dts/tegra30-asus-nexus7-tilapia-E1565.dts
index 89348fde13..ef8b2b5049 100644
--- a/arch/arm/dts/tegra30-asus-nexus7-tilapia-E1565.dts
+++ b/arch/arm/dts/tegra30-asus-nexus7-tilapia-E1565.dts
@@ -35,6 +35,7 @@
 					regulator-name = "vcore_emmc";
 					regulator-min-microvolt = <2850000>;
 					regulator-max-microvolt = <2850000>;
+					regulator-boot-on;
 				};
 			};
 		};
diff --git a/board/asus/grouper/Kconfig b/board/asus/grouper/Kconfig
index 47d9bae946..f935cce422 100644
--- a/board/asus/grouper/Kconfig
+++ b/board/asus/grouper/Kconfig
@@ -9,12 +9,4 @@ config SYS_VENDOR
 config SYS_CONFIG_NAME
 	default "grouper"
 
-config GROUPER_TPS65911
-	bool "Enable support TI TPS65911 PMIC"
-	select CMD_POWEROFF
-
-config GROUPER_MAX77663
-	bool "Enable support MAXIM MAX77663 PMIC"
-	select CMD_POWEROFF
-
 endif
diff --git a/board/asus/grouper/Makefile b/board/asus/grouper/Makefile
index e4a477a366..d041cf8087 100644
--- a/board/asus/grouper/Makefile
+++ b/board/asus/grouper/Makefile
@@ -7,8 +7,8 @@
 #  Svyatoslav Ryhel <clamor95@gmail.com>
 
 ifdef CONFIG_SPL_BUILD
-obj-$(CONFIG_GROUPER_MAX77663) += grouper-spl-max.o
-obj-$(CONFIG_GROUPER_TPS65911) += grouper-spl-ti.o
+obj-$(CONFIG_DM_PMIC_MAX77663) += grouper-spl-max.o
+obj-$(CONFIG_DM_PMIC_TPS65910) += grouper-spl-ti.o
 endif
 
 obj-y += grouper.o
diff --git a/board/asus/grouper/configs/grouper_E1565.config b/board/asus/grouper/configs/grouper_E1565.config
index 4d8d5263fa..265295c8b3 100644
--- a/board/asus/grouper/configs/grouper_E1565.config
+++ b/board/asus/grouper/configs/grouper_E1565.config
@@ -1,2 +1,6 @@
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-asus-nexus7-grouper-E1565"
-CONFIG_GROUPER_MAX77663=y
+CONFIG_CMD_POWEROFF=y
+# CONFIG_MAX77663_GPIO is not set
+CONFIG_DM_PMIC_MAX77663=y
+CONFIG_DM_REGULATOR_MAX77663=y
+CONFIG_SYSRESET_MAX77663=y
diff --git a/board/asus/grouper/configs/grouper_PM269.config b/board/asus/grouper/configs/grouper_PM269.config
index fc768b2051..a7ee3587ed 100644
--- a/board/asus/grouper/configs/grouper_PM269.config
+++ b/board/asus/grouper/configs/grouper_PM269.config
@@ -1,2 +1,6 @@
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-asus-nexus7-grouper-PM269"
-CONFIG_GROUPER_TPS65911=y
+CONFIG_CMD_POWEROFF=y
+CONFIG_DM_PMIC_TPS65910=y
+# CONFIG_DM_REGULATOR_TPS65910 is not set
+CONFIG_DM_REGULATOR_TPS65911=y
+CONFIG_SYSRESET_TPS65910=y
diff --git a/board/asus/grouper/configs/tilapia.config b/board/asus/grouper/configs/tilapia.config
index 1fb0633e3a..d461b4752a 100644
--- a/board/asus/grouper/configs/tilapia.config
+++ b/board/asus/grouper/configs/tilapia.config
@@ -1,3 +1,7 @@
 CONFIG_DEFAULT_DEVICE_TREE="tegra30-asus-nexus7-tilapia-E1565"
-CONFIG_GROUPER_MAX77663=y
 CONFIG_SYS_PROMPT="Tegra30 (Tilapia) # "
+CONFIG_CMD_POWEROFF=y
+# CONFIG_MAX77663_GPIO is not set
+CONFIG_DM_PMIC_MAX77663=y
+CONFIG_DM_REGULATOR_MAX77663=y
+CONFIG_SYSRESET_MAX77663=y
diff --git a/board/asus/grouper/grouper-spl-max.c b/board/asus/grouper/grouper-spl-max.c
index 844383766a..3e58bf97cc 100644
--- a/board/asus/grouper/grouper-spl-max.c
+++ b/board/asus/grouper/grouper-spl-max.c
@@ -9,7 +9,7 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
+#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/tegra_i2c.h>
 #include <linux/delay.h>
 
diff --git a/board/asus/grouper/grouper-spl-ti.c b/board/asus/grouper/grouper-spl-ti.c
index e5b78f0121..1dcce80b48 100644
--- a/board/asus/grouper/grouper-spl-ti.c
+++ b/board/asus/grouper/grouper-spl-ti.c
@@ -9,7 +9,7 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
+#include <asm/arch/tegra.h>
 #include <asm/arch-tegra/tegra_i2c.h>
 #include <linux/delay.h>
 
diff --git a/board/asus/grouper/grouper.c b/board/asus/grouper/grouper.c
index 5398ec8b9f..839a95ae15 100644
--- a/board/asus/grouper/grouper.c
+++ b/board/asus/grouper/grouper.c
@@ -7,105 +7,13 @@
  *  Svyatoslav Ryhel <clamor95@gmail.com>
  */
 
-#include <common.h>
 #include <dm.h>
 #include <fdt_support.h>
-#include <i2c.h>
-#include <log.h>
 #include <asm/arch/pinmux.h>
 #include <asm/arch/gp_padctrl.h>
-#include <asm/arch/gpio.h>
-#include <asm/gpio.h>
-#include <linux/delay.h>
-#include "pinmux-config-grouper.h"
-
-#define TPS65911_I2C_ADDRESS		0x2D
-
-#define TPS65911_REG_LDO1		0x30
-#define TPS65911_REG_DEVCTRL		0x3F
-#define   DEVCTRL_PWR_OFF_MASK		BIT(7)
-#define   DEVCTRL_DEV_ON_MASK		BIT(2)
-#define   DEVCTRL_DEV_OFF_MASK		BIT(0)
-
-#define MAX77663_I2C_ADDRESS		0x3C
-
-#define MAX77663_REG_SD2		0x18
-#define MAX77663_REG_LDO3		0x29
-#define MAX77663_REG_ONOFF_CFG1		0x41
-#define   ONOFF_PWR_OFF			BIT(1)
-
-#ifdef CONFIG_CMD_POWEROFF
-#ifdef CONFIG_GROUPER_TPS65911
-int do_poweroff(struct cmd_tbl *cmdtp,
-		int flag, int argc, char *const argv[])
-{
-	struct udevice *dev;
-	uchar data_buffer[1];
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS65911_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return 0;
-	}
-
-	ret = dm_i2c_read(dev, TPS65911_REG_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	data_buffer[0] |= DEVCTRL_PWR_OFF_MASK;
-
-	ret = dm_i2c_write(dev, TPS65911_REG_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	data_buffer[0] |= DEVCTRL_DEV_OFF_MASK;
-	data_buffer[0] &= ~DEVCTRL_DEV_ON_MASK;
-
-	ret = dm_i2c_write(dev, TPS65911_REG_DEVCTRL, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	// wait some time and then print error
-	mdelay(5000);
-
-	printf("Failed to power off!!!\n");
-	return 1;
-}
-#endif /* CONFIG_GROUPER_TPS65911 */
-
-#ifdef CONFIG_GROUPER_MAX77663
-int do_poweroff(struct cmd_tbl *cmdtp,
-		int flag, int argc, char *const argv[])
-{
-	struct udevice *dev;
-	uchar data_buffer[1];
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, MAX77663_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return 0;
-	}
-
-	ret = dm_i2c_read(dev, MAX77663_REG_ONOFF_CFG1, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	data_buffer[0] |= ONOFF_PWR_OFF;
+#include <power/regulator.h>
 
-	ret = dm_i2c_write(dev, MAX77663_REG_ONOFF_CFG1, data_buffer, 1);
-	if (ret)
-		return ret;
-
-	// wait some time and then print error
-	mdelay(5000);
-
-	printf("Failed to power off!!!\n");
-	return 1;
-}
-#endif /* CONFIG_GROUPER_MAX77663 */
-#endif /* CONFIG_CMD_POWEROFF */
+#include "pinmux-config-grouper.h"
 
 /*
  * Routine: pinmux_init
@@ -120,63 +28,13 @@ void pinmux_init(void)
 		ARRAY_SIZE(grouper_padctrl));
 }
 
-#ifdef CONFIG_MMC_SDHCI_TEGRA
-static void __maybe_unused tps65911_voltage_init(void)
-{
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, TPS65911_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return;
-	}
-
-	/* TPS659110: LDO1_REG = 3.3v, ACTIVE to SDMMC4 */
-	ret = dm_i2c_reg_write(dev, TPS65911_REG_LDO1, 0xC9);
-	if (ret)
-		log_debug("vcore_emmc set failed: %d\n", ret);
-}
-
-static void __maybe_unused max77663_voltage_init(void)
-{
-	struct udevice *dev;
-	int ret;
-
-	ret = i2c_get_chip_for_busnum(0, MAX77663_I2C_ADDRESS, 1, &dev);
-	if (ret) {
-		log_debug("cannot find PMIC I2C chip\n");
-		return;
-	}
-
-	/* 0x60 for 1.8v, bit7:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_SD2, 0x60);
-	if (ret)
-		log_debug("vdd_1v8_vio set failed: %d\n", ret);
-
-	/* 0xEC for 3.00v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
-	ret = dm_i2c_reg_write(dev, MAX77663_REG_LDO3, 0xEC);
-	if (ret)
-		log_debug("vcore_emmc set failed: %d\n", ret);
-}
-
-/*
- * Routine: pin_mux_mmc
- * Description: setup the MMC muxes, power rails, etc.
- */
-void pin_mux_mmc(void)
+int nvidia_board_init(void)
 {
-#ifdef CONFIG_GROUPER_MAX77663
-	/* Bring up eMMC power on MAX PMIC */
-	max77663_voltage_init();
-#endif
+	/* Set up boot-on regulators */
+	regulators_enable_boot_on(true);
 
-#ifdef CONFIG_GROUPER_TPS65911
-	/* Bring up eMMC power on TI PMIC */
-	tps65911_voltage_init();
-#endif
+	return 0;
 }
-#endif	/* MMC */
 
 #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
 int ft_board_setup(void *blob, struct bd_info *bd)
diff --git a/configs/grouper_common_defconfig b/configs/grouper_common_defconfig
index 258d7b1139..616540f7d5 100644
--- a/configs/grouper_common_defconfig
+++ b/configs/grouper_common_defconfig
@@ -43,6 +43,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y
 CONFIG_CMD_UMS_ABORT_KEYED=y
 # CONFIG_CMD_SETEXPR is not set
 CONFIG_CMD_PAUSE=y
+CONFIG_CMD_REGULATOR=y
 CONFIG_CMD_EXT4_WRITE=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
-- 
2.40.1

[PATCH v1 5/5] ARM: dts: tegra30: enable USB PHY node on some devices

[Svyatoslav Ryhel]

Enable USB PHY nodes on ASUS Transformers, Grouper, Enadevoru
and LG X3. This is not mandatory since driver will use default
values but preferable for new devices.

Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
 arch/arm/dts/tegra30-asus-grouper-common.dtsi |  7 +++++++
 arch/arm/dts/tegra30-asus-p1801-t.dts         | 15 +++++++++++++++
 arch/arm/dts/tegra30-asus-tf600t.dts          | 11 +++++++++++
 arch/arm/dts/tegra30-asus-transformer.dtsi    |  7 +++++++
 arch/arm/dts/tegra30-htc-endeavoru.dts        |  7 +++++++
 arch/arm/dts/tegra30-lg-x3.dtsi               |  8 ++++++++
 6 files changed, 55 insertions(+)

diff --git a/arch/arm/dts/tegra30-asus-grouper-common.dtsi b/arch/arm/dts/tegra30-asus-grouper-common.dtsi
index fcf31e2dd0..c9277388c9 100644
--- a/arch/arm/dts/tegra30-asus-grouper-common.dtsi
+++ b/arch/arm/dts/tegra30-asus-grouper-common.dtsi
@@ -71,6 +71,13 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+	};
+
 	backlight: backlight {
 		compatible = "pwm-backlight";
 
diff --git a/arch/arm/dts/tegra30-asus-p1801-t.dts b/arch/arm/dts/tegra30-asus-p1801-t.dts
index d62d43268b..19de984d5f 100644
--- a/arch/arm/dts/tegra30-asus-p1801-t.dts
+++ b/arch/arm/dts/tegra30-asus-p1801-t.dts
@@ -150,17 +150,32 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+	};
+
 	/* Mini USB port */
 	usb2: usb@7d004000 {
 		status = "okay";
 		nvidia,vbus-gpio = <&gpio TEGRA_GPIO(H, 7) GPIO_ACTIVE_HIGH>;
 	};
 
+	usb-phy@7d004000 {
+		status = "okay";
+	};
+
 	/* Dock's USB port */
 	usb3: usb@7d008000 {
 		status = "okay";
 	};
 
+	usb-phy@7d008000 {
+		status = "okay";
+	};
+
 	/* PMIC has a built-in 32KHz oscillator which is used by PMC */
 	clk32k_in: clock-32k {
 		compatible = "fixed-clock";
diff --git a/arch/arm/dts/tegra30-asus-tf600t.dts b/arch/arm/dts/tegra30-asus-tf600t.dts
index efc6a83b9d..3f11d33bc4 100644
--- a/arch/arm/dts/tegra30-asus-tf600t.dts
+++ b/arch/arm/dts/tegra30-asus-tf600t.dts
@@ -165,11 +165,22 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+	};
+
 	/* Dock's USB port */
 	usb3: usb@7d008000 {
 		status = "okay";
 	};
 
+	usb-phy@7d008000 {
+		status = "okay";
+	};
+
 	backlight: backlight {
 		compatible = "pwm-backlight";
 
diff --git a/arch/arm/dts/tegra30-asus-transformer.dtsi b/arch/arm/dts/tegra30-asus-transformer.dtsi
index afddb83983..c4649eee79 100644
--- a/arch/arm/dts/tegra30-asus-transformer.dtsi
+++ b/arch/arm/dts/tegra30-asus-transformer.dtsi
@@ -131,6 +131,13 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+	};
+
 	/* Dock's USB port */
 	usb3: usb@7d008000 {
 		status = "okay";
diff --git a/arch/arm/dts/tegra30-htc-endeavoru.dts b/arch/arm/dts/tegra30-htc-endeavoru.dts
index 22320de708..21cd0f9207 100644
--- a/arch/arm/dts/tegra30-htc-endeavoru.dts
+++ b/arch/arm/dts/tegra30-htc-endeavoru.dts
@@ -101,6 +101,13 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+	};
+
 	backlight: backlight {
 		compatible = "nvidia,tegra-pwm-backlight";
 
diff --git a/arch/arm/dts/tegra30-lg-x3.dtsi b/arch/arm/dts/tegra30-lg-x3.dtsi
index aa207a70c7..01936b872e 100644
--- a/arch/arm/dts/tegra30-lg-x3.dtsi
+++ b/arch/arm/dts/tegra30-lg-x3.dtsi
@@ -153,6 +153,14 @@
 		dr_mode = "otg";
 	};
 
+	usb-phy@7d000000 {
+		status = "okay";
+		nvidia,hssync-start-delay = <0>;
+		nvidia,xcvr-lsfslew = <2>;
+		nvidia,xcvr-lsrslew = <2>;
+		vbus-supply = <&avdd_3v3_periph>;
+	};
+
 	/* PMIC has a built-in 32KHz oscillator which is used by PMC */
 	clk32k_in: clock-32k {
 		compatible = "fixed-clock";
-- 
2.40.1

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Peter Robinson]

Hi Svyatoslav,

> Since the proposed PMIC patches have been accepted, I see the need
> to convert boards which I maintain to use DM drivers instead of board hacks.
>
> Svyatoslav Ryhel (5):
>   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
>   board: endeavoru: convert HTC One X to use DM PMIC

Is there a reason why the two above devices don't appear to have their
.dts files in the upstream kernel?

>   board: transformer-t30: convert ASUS Transformers to use DM PMIC
>   board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
>   ARM: dts: tegra30: enable USB PHY node on some devices
>
>  arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
>  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
>  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
>  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
>  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
>  arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
>  arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
>  arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
>  arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
>  board/asus/grouper/Kconfig                    |   8 -
>  board/asus/grouper/Makefile                   |   4 +-
>  .../asus/grouper/configs/grouper_E1565.config |   6 +-
>  .../asus/grouper/configs/grouper_PM269.config |   6 +-
>  board/asus/grouper/configs/tilapia.config     |   6 +-
>  board/asus/grouper/grouper-spl-max.c          |   2 +-
>  board/asus/grouper/grouper-spl-ti.c           |   2 +-
>  board/asus/grouper/grouper.c                  | 154 +-----------------
>  board/asus/transformer-t30/Kconfig            |  10 --
>  .../transformer-t30/configs/tf600t.config     |   2 +-
>  .../transformer-t30/transformer-t30-spl.c     |   2 +-
>  board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
>  board/htc/endeavoru/endeavoru-spl.c           |   2 +-
>  board/htc/endeavoru/endeavoru.c               |  72 +-------
>  board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
>  board/lg/x3-t30/x3-t30.c                      |  97 +----------
>  configs/endeavoru_defconfig                   |   4 +
>  configs/grouper_common_defconfig              |   1 +
>  configs/transformer_t30_defconfig             |   5 +
>  configs/x3_t30_defconfig                      |   4 +
>  29 files changed, 128 insertions(+), 450 deletions(-)
>
> --
> 2.40.1
>

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Svyatoslav Ryhel]

пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
>
> Hi Svyatoslav,
>
> > Since the proposed PMIC patches have been accepted, I see the need
> > to convert boards which I maintain to use DM drivers instead of board hacks.
> >
> > Svyatoslav Ryhel (5):
> >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> >   board: endeavoru: convert HTC One X to use DM PMIC
>
> Is there a reason why the two above devices don't appear to have their
> .dts files in the upstream kernel?
>

Yes, there is a reason. Linux maintainers treat submitters as
existential enemies or as dirt at least. I was trying to work with
linux but I have no desire to spend any time to upstream endeavoru or
lg_x3.

> >   board: transformer-t30: convert ASUS Transformers to use DM PMIC
> >   board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
> >   ARM: dts: tegra30: enable USB PHY node on some devices
> >
> >  arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
> >  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
> >  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
> >  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
> >  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
> >  arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
> >  arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
> >  arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
> >  arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
> >  board/asus/grouper/Kconfig                    |   8 -
> >  board/asus/grouper/Makefile                   |   4 +-
> >  .../asus/grouper/configs/grouper_E1565.config |   6 +-
> >  .../asus/grouper/configs/grouper_PM269.config |   6 +-
> >  board/asus/grouper/configs/tilapia.config     |   6 +-
> >  board/asus/grouper/grouper-spl-max.c          |   2 +-
> >  board/asus/grouper/grouper-spl-ti.c           |   2 +-
> >  board/asus/grouper/grouper.c                  | 154 +-----------------
> >  board/asus/transformer-t30/Kconfig            |  10 --
> >  .../transformer-t30/configs/tf600t.config     |   2 +-
> >  .../transformer-t30/transformer-t30-spl.c     |   2 +-
> >  board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
> >  board/htc/endeavoru/endeavoru-spl.c           |   2 +-
> >  board/htc/endeavoru/endeavoru.c               |  72 +-------
> >  board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
> >  board/lg/x3-t30/x3-t30.c                      |  97 +----------
> >  configs/endeavoru_defconfig                   |   4 +
> >  configs/grouper_common_defconfig              |   1 +
> >  configs/transformer_t30_defconfig             |   5 +
> >  configs/x3_t30_defconfig                      |   4 +
> >  29 files changed, 128 insertions(+), 450 deletions(-)
> >
> > --
> > 2.40.1
> >

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Peter Robinson]

On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > > Since the proposed PMIC patches have been accepted, I see the need
> > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > >
> > > Svyatoslav Ryhel (5):
> > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > >   board: endeavoru: convert HTC One X to use DM PMIC
> >
> > Is there a reason why the two above devices don't appear to have their
> > .dts files in the upstream kernel?
> >
>
> Yes, there is a reason. Linux maintainers treat submitters as
> existential enemies or as dirt at least. I was trying to work with
> linux but I have no desire to spend any time to upstream endeavoru or
> lg_x3.

The usual policy for acceptance into U-Boot is to have upstream review
in the kernel first.

> > >   board: transformer-t30: convert ASUS Transformers to use DM PMIC
> > >   board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
> > >   ARM: dts: tegra30: enable USB PHY node on some devices
> > >
> > >  arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
> > >  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
> > >  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
> > >  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
> > >  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
> > >  arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
> > >  arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
> > >  arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
> > >  arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
> > >  board/asus/grouper/Kconfig                    |   8 -
> > >  board/asus/grouper/Makefile                   |   4 +-
> > >  .../asus/grouper/configs/grouper_E1565.config |   6 +-
> > >  .../asus/grouper/configs/grouper_PM269.config |   6 +-
> > >  board/asus/grouper/configs/tilapia.config     |   6 +-
> > >  board/asus/grouper/grouper-spl-max.c          |   2 +-
> > >  board/asus/grouper/grouper-spl-ti.c           |   2 +-
> > >  board/asus/grouper/grouper.c                  | 154 +-----------------
> > >  board/asus/transformer-t30/Kconfig            |  10 --
> > >  .../transformer-t30/configs/tf600t.config     |   2 +-
> > >  .../transformer-t30/transformer-t30-spl.c     |   2 +-
> > >  board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
> > >  board/htc/endeavoru/endeavoru-spl.c           |   2 +-
> > >  board/htc/endeavoru/endeavoru.c               |  72 +-------
> > >  board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
> > >  board/lg/x3-t30/x3-t30.c                      |  97 +----------
> > >  configs/endeavoru_defconfig                   |   4 +
> > >  configs/grouper_common_defconfig              |   1 +
> > >  configs/transformer_t30_defconfig             |   5 +
> > >  configs/x3_t30_defconfig                      |   4 +
> > >  29 files changed, 128 insertions(+), 450 deletions(-)
> > >
> > > --
> > > 2.40.1
> > >

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Svyatoslav Ryhel]

пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
>
> On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > >
> > > Hi Svyatoslav,
> > >
> > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > >
> > > > Svyatoslav Ryhel (5):
> > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > >
> > > Is there a reason why the two above devices don't appear to have their
> > > .dts files in the upstream kernel?
> > >
> >
> > Yes, there is a reason. Linux maintainers treat submitters as
> > existential enemies or as dirt at least. I was trying to work with
> > linux but I have no desire to spend any time to upstream endeavoru or
> > lg_x3.
>
> The usual policy for acceptance into U-Boot is to have upstream review
> in the kernel first.
>

May you point to a policy which clearly and explicitly states this as
a mandatory condition?

> > > >   board: transformer-t30: convert ASUS Transformers to use DM PMIC
> > > >   board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
> > > >   ARM: dts: tegra30: enable USB PHY node on some devices
> > > >
> > > >  arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
> > > >  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
> > > >  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
> > > >  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
> > > >  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
> > > >  arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
> > > >  arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
> > > >  arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
> > > >  arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
> > > >  board/asus/grouper/Kconfig                    |   8 -
> > > >  board/asus/grouper/Makefile                   |   4 +-
> > > >  .../asus/grouper/configs/grouper_E1565.config |   6 +-
> > > >  .../asus/grouper/configs/grouper_PM269.config |   6 +-
> > > >  board/asus/grouper/configs/tilapia.config     |   6 +-
> > > >  board/asus/grouper/grouper-spl-max.c          |   2 +-
> > > >  board/asus/grouper/grouper-spl-ti.c           |   2 +-
> > > >  board/asus/grouper/grouper.c                  | 154 +-----------------
> > > >  board/asus/transformer-t30/Kconfig            |  10 --
> > > >  .../transformer-t30/configs/tf600t.config     |   2 +-
> > > >  .../transformer-t30/transformer-t30-spl.c     |   2 +-
> > > >  board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
> > > >  board/htc/endeavoru/endeavoru-spl.c           |   2 +-
> > > >  board/htc/endeavoru/endeavoru.c               |  72 +-------
> > > >  board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
> > > >  board/lg/x3-t30/x3-t30.c                      |  97 +----------
> > > >  configs/endeavoru_defconfig                   |   4 +
> > > >  configs/grouper_common_defconfig              |   1 +
> > > >  configs/transformer_t30_defconfig             |   5 +
> > > >  configs/x3_t30_defconfig                      |   4 +
> > > >  29 files changed, 128 insertions(+), 450 deletions(-)
> > > >
> > > > --
> > > > 2.40.1
> > > >

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Peter Robinson]

On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>
> пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> >
> > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > >
> > > > Hi Svyatoslav,
> > > >
> > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > >
> > > > > Svyatoslav Ryhel (5):
> > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > >
> > > > Is there a reason why the two above devices don't appear to have their
> > > > .dts files in the upstream kernel?
> > > >
> > >
> > > Yes, there is a reason. Linux maintainers treat submitters as
> > > existential enemies or as dirt at least. I was trying to work with
> > > linux but I have no desire to spend any time to upstream endeavoru or
> > > lg_x3.
> >
> > The usual policy for acceptance into U-Boot is to have upstream review
> > in the kernel first.
> >
>
> May you point to a policy which clearly and explicitly states this as
> a mandatory condition?

There have been a number of devices rejected in the past until their
DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
to clarify the exact policy.

> > > > >   board: transformer-t30: convert ASUS Transformers to use DM PMIC
> > > > >   board: grouper: convert ASUS Google Nexus 7 (2012) to use DM PMIC
> > > > >   ARM: dts: tegra30: enable USB PHY node on some devices
> > > > >
> > > > >  arch/arm/dts/tegra30-asus-grouper-common.dtsi |   7 +
> > > > >  .../dts/tegra30-asus-nexus7-grouper-E1565.dts |   1 +
> > > > >  .../dts/tegra30-asus-nexus7-grouper-PM269.dts |   1 +
> > > > >  .../dts/tegra30-asus-nexus7-tilapia-E1565.dts |   1 +
> > > > >  arch/arm/dts/tegra30-asus-p1801-t.dts         |  17 ++
> > > > >  arch/arm/dts/tegra30-asus-tf600t.dts          |  15 ++
> > > > >  arch/arm/dts/tegra30-asus-transformer.dtsi    |   9 +
> > > > >  arch/arm/dts/tegra30-htc-endeavoru.dts        |   8 +
> > > > >  arch/arm/dts/tegra30-lg-x3.dtsi               |   9 +
> > > > >  board/asus/grouper/Kconfig                    |   8 -
> > > > >  board/asus/grouper/Makefile                   |   4 +-
> > > > >  .../asus/grouper/configs/grouper_E1565.config |   6 +-
> > > > >  .../asus/grouper/configs/grouper_PM269.config |   6 +-
> > > > >  board/asus/grouper/configs/tilapia.config     |   6 +-
> > > > >  board/asus/grouper/grouper-spl-max.c          |   2 +-
> > > > >  board/asus/grouper/grouper-spl-ti.c           |   2 +-
> > > > >  board/asus/grouper/grouper.c                  | 154 +-----------------
> > > > >  board/asus/transformer-t30/Kconfig            |  10 --
> > > > >  .../transformer-t30/configs/tf600t.config     |   2 +-
> > > > >  .../transformer-t30/transformer-t30-spl.c     |   2 +-
> > > > >  board/asus/transformer-t30/transformer-t30.c  | 121 +-------------
> > > > >  board/htc/endeavoru/endeavoru-spl.c           |   2 +-
> > > > >  board/htc/endeavoru/endeavoru.c               |  72 +-------
> > > > >  board/lg/x3-t30/x3-t30-spl.c                  |   2 +-
> > > > >  board/lg/x3-t30/x3-t30.c                      |  97 +----------
> > > > >  configs/endeavoru_defconfig                   |   4 +
> > > > >  configs/grouper_common_defconfig              |   1 +
> > > > >  configs/transformer_t30_defconfig             |   5 +
> > > > >  configs/x3_t30_defconfig                      |   4 +
> > > > >  29 files changed, 128 insertions(+), 450 deletions(-)
> > > > >
> > > > > --
> > > > > 2.40.1
> > > > >

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2814 bytes --]

On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >
> > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > >
> > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > >
> > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > >
> > > > > Hi Svyatoslav,
> > > > >
> > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > >
> > > > > > Svyatoslav Ryhel (5):
> > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > >
> > > > > Is there a reason why the two above devices don't appear to have their
> > > > > .dts files in the upstream kernel?
> > > > >
> > > >
> > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > existential enemies or as dirt at least. I was trying to work with
> > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > lg_x3.
> > >
> > > The usual policy for acceptance into U-Boot is to have upstream review
> > > in the kernel first.
> > >
> >
> > May you point to a policy which clearly and explicitly states this as
> > a mandatory condition?
> 
> There have been a number of devices rejected in the past until their
> DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> to clarify the exact policy.

Well, here is where it's tricky. I brought this up for one of the
Broadcom MIPS platforms a week or two back, and Linus Walleij's point
(and I'm paraphrasing) is there's not really an upstream for it to go.

What we cannot have is device tree bindings[1] that aren't upstream or
worse yet conflict with the official bindings.

So the general way to resolve that is have device tree file be drop-in
from the linux kernel, and what additions we must have be done via
-u-boot.dtsi files. And in turn, some SoCs are better about keeping in
sync with the kernel than other SoCs are.

Now, upstream being actively hostile to dts files, especially for older
platforms? That's unfortunate. So long as we aren't violating the rules
about bindings, the intention is that we don't have device trees that
are either (a) massively out of sync with the kernel[2] or (b) kept
intentionally mismatched from the kernel.

-- 
Tom

[1]: There are both examples like binman that Simon is working on at
least but this is more exception than intentional rule.
[2]: Per our other conversions, I know the tegra ones are in this
unfortunate state in general

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Peter Robinson]

> > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > >
> > > > > > > Svyatoslav Ryhel (5):
> > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > >
> > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > .dts files in the upstream kernel?
> > > > > >
> > > > >
> > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > lg_x3.
> > > >
> > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > in the kernel first.
> > > >
> > >
> > > May you point to a policy which clearly and explicitly states this as
> > > a mandatory condition?
> >
> > There have been a number of devices rejected in the past until their
> > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > to clarify the exact policy.
>
> Well, here is where it's tricky. I brought this up for one of the
> Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> (and I'm paraphrasing) is there's not really an upstream for it to go.
>
> What we cannot have is device tree bindings[1] that aren't upstream or
> worse yet conflict with the official bindings.
>
> So the general way to resolve that is have device tree file be drop-in
> from the linux kernel, and what additions we must have be done via
> -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> sync with the kernel than other SoCs are.
>
> Now, upstream being actively hostile to dts files, especially for older
> platforms? That's unfortunate. So long as we aren't violating the rules
> about bindings, the intention is that we don't have device trees that
> are either (a) massively out of sync with the kernel[2] or (b) kept
> intentionally mismatched from the kernel.

I don't believe I've seen upstream Tegra maintainers being actively
hostile towards updates for older devices, I know they have certainly
defocused them, but I'm not sure that's what I'd consider hostile.

> [1]: There are both examples like binman that Simon is working on at
> least but this is more exception than intentional rule.
> [2]: Per our other conversions, I know the tegra ones are in this
> unfortunate state in general

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3190 bytes --]

On Mon, Nov 13, 2023 at 04:52:22PM +0000, Peter Robinson wrote:
> > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > > >
> > > > > > > > Svyatoslav Ryhel (5):
> > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > > >
> > > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > > .dts files in the upstream kernel?
> > > > > > >
> > > > > >
> > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > > lg_x3.
> > > > >
> > > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > > in the kernel first.
> > > > >
> > > >
> > > > May you point to a policy which clearly and explicitly states this as
> > > > a mandatory condition?
> > >
> > > There have been a number of devices rejected in the past until their
> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > > to clarify the exact policy.
> >
> > Well, here is where it's tricky. I brought this up for one of the
> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> > (and I'm paraphrasing) is there's not really an upstream for it to go.
> >
> > What we cannot have is device tree bindings[1] that aren't upstream or
> > worse yet conflict with the official bindings.
> >
> > So the general way to resolve that is have device tree file be drop-in
> > from the linux kernel, and what additions we must have be done via
> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> > sync with the kernel than other SoCs are.
> >
> > Now, upstream being actively hostile to dts files, especially for older
> > platforms? That's unfortunate. So long as we aren't violating the rules
> > about bindings, the intention is that we don't have device trees that
> > are either (a) massively out of sync with the kernel[2] or (b) kept
> > intentionally mismatched from the kernel.
> 
> I don't believe I've seen upstream Tegra maintainers being actively
> hostile towards updates for older devices, I know they have certainly
> defocused them, but I'm not sure that's what I'd consider hostile.

No objections from me on upstreaming older devices in Linux. I used to
be able to test most of the older devices, but many of which I used to
have direct access to are now defunct (for varying reasons). So I will
have to rely on the community for testing etc. since I cannot scale to
the point where I personally have all of these devices.

Now, I don't think that's hostile and if I ever came across as hostile
I'm sorry. The intent was never to reject device support. Obviously the
Linux kernel has high standards and sometimes that can be off-putting,
but I don't think we've ever asked for anything out of the ordinary.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3686 bytes --]

On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >
> > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > > >
> > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > >
> > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > >
> > > > > > Hi Svyatoslav,
> > > > > >
> > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > >
> > > > > > > Svyatoslav Ryhel (5):
> > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > >
> > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > .dts files in the upstream kernel?
> > > > > >
> > > > >
> > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > lg_x3.
> > > >
> > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > in the kernel first.
> > > >
> > >
> > > May you point to a policy which clearly and explicitly states this as
> > > a mandatory condition?
> > 
> > There have been a number of devices rejected in the past until their
> > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > to clarify the exact policy.
> 
> Well, here is where it's tricky. I brought this up for one of the
> Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> (and I'm paraphrasing) is there's not really an upstream for it to go.
> 
> What we cannot have is device tree bindings[1] that aren't upstream or
> worse yet conflict with the official bindings.
> 
> So the general way to resolve that is have device tree file be drop-in
> from the linux kernel, and what additions we must have be done via
> -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> sync with the kernel than other SoCs are.
> 
> Now, upstream being actively hostile to dts files, especially for older
> platforms? That's unfortunate. So long as we aren't violating the rules
> about bindings, the intention is that we don't have device trees that
> are either (a) massively out of sync with the kernel[2] or (b) kept
> intentionally mismatched from the kernel.
> 
> -- 
> Tom
> 
> [1]: There are both examples like binman that Simon is working on at
> least but this is more exception than intentional rule.
> [2]: Per our other conversions, I know the tegra ones are in this
> unfortunate state in general

On the Tegra side we've been fairly lax about the device trees in
U-Boot, I suppose. The assumption had always been that U-Boot would load
an external DTB and pass it to the kernel on boot, so keeping them both
in sync was never a high priority.

U-Boot does only a very tiny amount of what Linux does, so dropping in
the kernel DTB always seemed a bit overkill.

In either case, if this is problematic, it's something that I could take
a look at. Again, it's expected that the device trees are different, for
historical reasons, but I'd be surprised if they actually conflict with
one another. U-Boot's DTB was always supposed to be a subset of the
Linux DTB.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4371 bytes --]

On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > >
> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > >
> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > > >
> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > > >
> > > > > > > Hi Svyatoslav,
> > > > > > >
> > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > > >
> > > > > > > > Svyatoslav Ryhel (5):
> > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > > >
> > > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > > .dts files in the upstream kernel?
> > > > > > >
> > > > > >
> > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > > lg_x3.
> > > > >
> > > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > > in the kernel first.
> > > > >
> > > >
> > > > May you point to a policy which clearly and explicitly states this as
> > > > a mandatory condition?
> > > 
> > > There have been a number of devices rejected in the past until their
> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > > to clarify the exact policy.
> > 
> > Well, here is where it's tricky. I brought this up for one of the
> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> > (and I'm paraphrasing) is there's not really an upstream for it to go.
> > 
> > What we cannot have is device tree bindings[1] that aren't upstream or
> > worse yet conflict with the official bindings.
> > 
> > So the general way to resolve that is have device tree file be drop-in
> > from the linux kernel, and what additions we must have be done via
> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> > sync with the kernel than other SoCs are.
> > 
> > Now, upstream being actively hostile to dts files, especially for older
> > platforms? That's unfortunate. So long as we aren't violating the rules
> > about bindings, the intention is that we don't have device trees that
> > are either (a) massively out of sync with the kernel[2] or (b) kept
> > intentionally mismatched from the kernel.
> > 
> > -- 
> > Tom
> > 
> > [1]: There are both examples like binman that Simon is working on at
> > least but this is more exception than intentional rule.
> > [2]: Per our other conversions, I know the tegra ones are in this
> > unfortunate state in general
> 
> On the Tegra side we've been fairly lax about the device trees in
> U-Boot, I suppose. The assumption had always been that U-Boot would load
> an external DTB and pass it to the kernel on boot, so keeping them both
> in sync was never a high priority.
> 
> U-Boot does only a very tiny amount of what Linux does, so dropping in
> the kernel DTB always seemed a bit overkill.
> 
> In either case, if this is problematic, it's something that I could take
> a look at. Again, it's expected that the device trees are different, for
> historical reasons, but I'd be surprised if they actually conflict with
> one another. U-Boot's DTB was always supposed to be a subset of the
> Linux DTB.

So, the issue with U-Boot and kernel device trees being out of sync is
that we then can't support the model of "just pass the current DT to the
OS". This in general is good to support because it means that even if a
given platform isn't formally SystemReady IR certified it's still likely
to be functional.

The most strict rule is that you can't have bindings in U-Boot that
conflict with the kernel, or should be in the kernel but aren't, and so
on.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5400 bytes --]

On Wed, Nov 15, 2023 at 02:11:49PM -0500, Tom Rini wrote:
> On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
> > On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> > > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> > > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > >
> > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > >
> > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > > > >
> > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > > > >
> > > > > > > > Hi Svyatoslav,
> > > > > > > >
> > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > > > >
> > > > > > > > > Svyatoslav Ryhel (5):
> > > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > > > >
> > > > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > > > .dts files in the upstream kernel?
> > > > > > > >
> > > > > > >
> > > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > > > lg_x3.
> > > > > >
> > > > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > > > in the kernel first.
> > > > > >
> > > > >
> > > > > May you point to a policy which clearly and explicitly states this as
> > > > > a mandatory condition?
> > > > 
> > > > There have been a number of devices rejected in the past until their
> > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > > > to clarify the exact policy.
> > > 
> > > Well, here is where it's tricky. I brought this up for one of the
> > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> > > (and I'm paraphrasing) is there's not really an upstream for it to go.
> > > 
> > > What we cannot have is device tree bindings[1] that aren't upstream or
> > > worse yet conflict with the official bindings.
> > > 
> > > So the general way to resolve that is have device tree file be drop-in
> > > from the linux kernel, and what additions we must have be done via
> > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> > > sync with the kernel than other SoCs are.
> > > 
> > > Now, upstream being actively hostile to dts files, especially for older
> > > platforms? That's unfortunate. So long as we aren't violating the rules
> > > about bindings, the intention is that we don't have device trees that
> > > are either (a) massively out of sync with the kernel[2] or (b) kept
> > > intentionally mismatched from the kernel.
> > > 
> > > -- 
> > > Tom
> > > 
> > > [1]: There are both examples like binman that Simon is working on at
> > > least but this is more exception than intentional rule.
> > > [2]: Per our other conversions, I know the tegra ones are in this
> > > unfortunate state in general
> > 
> > On the Tegra side we've been fairly lax about the device trees in
> > U-Boot, I suppose. The assumption had always been that U-Boot would load
> > an external DTB and pass it to the kernel on boot, so keeping them both
> > in sync was never a high priority.
> > 
> > U-Boot does only a very tiny amount of what Linux does, so dropping in
> > the kernel DTB always seemed a bit overkill.
> > 
> > In either case, if this is problematic, it's something that I could take
> > a look at. Again, it's expected that the device trees are different, for
> > historical reasons, but I'd be surprised if they actually conflict with
> > one another. U-Boot's DTB was always supposed to be a subset of the
> > Linux DTB.
> 
> So, the issue with U-Boot and kernel device trees being out of sync is
> that we then can't support the model of "just pass the current DT to the
> OS". This in general is good to support because it means that even if a
> given platform isn't formally SystemReady IR certified it's still likely
> to be functional.

This is certainly not something that we ever strived for with Tegra. It
was always very clear that we needed to get the DTB from the same source
as the kernel. The vast majority of what's in the DTB is completely
useless for U-Boot because it simply doesn't support (and doesn't have
to support) a lot of the hardware that Linux supports.

One concern that I have with this policy is that for certain devices we
may just not be able to do this. Especially with some early OEM devices
I recall that they had limited storage for the bootloader. Since the DTB
needs to be embedded, a full-blown DTB from Linux might inflate the size
significantly. Comparing to what we have today, the Linux DTB can be
anywhere from 2 to 3 times as big as the U-Boot DTB.

> The most strict rule is that you can't have bindings in U-Boot that
> conflict with the kernel, or should be in the kernel but aren't, and so
> on.

I think this makes sense.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 6354 bytes --]

On Mon, Dec 11, 2023 at 12:55:32PM +0100, Thierry Reding wrote:
> On Wed, Nov 15, 2023 at 02:11:49PM -0500, Tom Rini wrote:
> > On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
> > > On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> > > > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> > > > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > > >
> > > > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > > >
> > > > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > > > > > > >
> > > > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > > > > > > > >
> > > > > > > > > Hi Svyatoslav,
> > > > > > > > >
> > > > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > > > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > > > > > > > > >
> > > > > > > > > > Svyatoslav Ryhel (5):
> > > > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > > > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > > > > > > > >
> > > > > > > > > Is there a reason why the two above devices don't appear to have their
> > > > > > > > > .dts files in the upstream kernel?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > > > > > > > existential enemies or as dirt at least. I was trying to work with
> > > > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > > > > > > > lg_x3.
> > > > > > >
> > > > > > > The usual policy for acceptance into U-Boot is to have upstream review
> > > > > > > in the kernel first.
> > > > > > >
> > > > > >
> > > > > > May you point to a policy which clearly and explicitly states this as
> > > > > > a mandatory condition?
> > > > > 
> > > > > There have been a number of devices rejected in the past until their
> > > > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > > > > to clarify the exact policy.
> > > > 
> > > > Well, here is where it's tricky. I brought this up for one of the
> > > > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> > > > (and I'm paraphrasing) is there's not really an upstream for it to go.
> > > > 
> > > > What we cannot have is device tree bindings[1] that aren't upstream or
> > > > worse yet conflict with the official bindings.
> > > > 
> > > > So the general way to resolve that is have device tree file be drop-in
> > > > from the linux kernel, and what additions we must have be done via
> > > > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> > > > sync with the kernel than other SoCs are.
> > > > 
> > > > Now, upstream being actively hostile to dts files, especially for older
> > > > platforms? That's unfortunate. So long as we aren't violating the rules
> > > > about bindings, the intention is that we don't have device trees that
> > > > are either (a) massively out of sync with the kernel[2] or (b) kept
> > > > intentionally mismatched from the kernel.
> > > > 
> > > > -- 
> > > > Tom
> > > > 
> > > > [1]: There are both examples like binman that Simon is working on at
> > > > least but this is more exception than intentional rule.
> > > > [2]: Per our other conversions, I know the tegra ones are in this
> > > > unfortunate state in general
> > > 
> > > On the Tegra side we've been fairly lax about the device trees in
> > > U-Boot, I suppose. The assumption had always been that U-Boot would load
> > > an external DTB and pass it to the kernel on boot, so keeping them both
> > > in sync was never a high priority.
> > > 
> > > U-Boot does only a very tiny amount of what Linux does, so dropping in
> > > the kernel DTB always seemed a bit overkill.
> > > 
> > > In either case, if this is problematic, it's something that I could take
> > > a look at. Again, it's expected that the device trees are different, for
> > > historical reasons, but I'd be surprised if they actually conflict with
> > > one another. U-Boot's DTB was always supposed to be a subset of the
> > > Linux DTB.
> > 
> > So, the issue with U-Boot and kernel device trees being out of sync is
> > that we then can't support the model of "just pass the current DT to the
> > OS". This in general is good to support because it means that even if a
> > given platform isn't formally SystemReady IR certified it's still likely
> > to be functional.
> 
> This is certainly not something that we ever strived for with Tegra. It
> was always very clear that we needed to get the DTB from the same source
> as the kernel. The vast majority of what's in the DTB is completely
> useless for U-Boot because it simply doesn't support (and doesn't have
> to support) a lot of the hardware that Linux supports.
> 
> One concern that I have with this policy is that for certain devices we
> may just not be able to do this. Especially with some early OEM devices
> I recall that they had limited storage for the bootloader. Since the DTB
> needs to be embedded, a full-blown DTB from Linux might inflate the size
> significantly. Comparing to what we have today, the Linux DTB can be
> anywhere from 2 to 3 times as big as the U-Boot DTB.

As I noted in a different thread, I will be unhappy if U-Boot is unable
to still be useful on a platform (tbs2910) that has just shy of 384kB of
space for the binary, so still being somewhat small is a feature I want
us to keep.

That said, most of the common community distributions want to be able to
not ship device trees at least some day. At least one today requires
being passed the right / valid device tree. And U-Boot will pass along
the tree we're using if no override is presented. So yes, passing along
the full real device tree to U-Boot and then being able to pass it
further along is generally desired. If you can't you can't. If you want
to take on the headache of keeping them separate, well, OK. But as this
series shows we also make use of more of the tree than we used to as
well, so just doing the drop-in and occasional resync is good.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Svyatoslav Ryhel]

15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini <trini@konsulko.com> написав(-ла):
>On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
>> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
>> > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
>> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> > > >
>> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
>> > > > >
>> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
>> > > > > >
>> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
>> > > > > > >
>> > > > > > > Hi Svyatoslav,
>> > > > > > >
>> > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
>> > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
>> > > > > > > >
>> > > > > > > > Svyatoslav Ryhel (5):
>> > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
>> > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
>> > > > > > >
>> > > > > > > Is there a reason why the two above devices don't appear to have their
>> > > > > > > .dts files in the upstream kernel?
>> > > > > > >
>> > > > > >
>> > > > > > Yes, there is a reason. Linux maintainers treat submitters as
>> > > > > > existential enemies or as dirt at least. I was trying to work with
>> > > > > > linux but I have no desire to spend any time to upstream endeavoru or
>> > > > > > lg_x3.
>> > > > >
>> > > > > The usual policy for acceptance into U-Boot is to have upstream review
>> > > > > in the kernel first.
>> > > > >
>> > > >
>> > > > May you point to a policy which clearly and explicitly states this as
>> > > > a mandatory condition?
>> > > 
>> > > There have been a number of devices rejected in the past until their
>> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
>> > > to clarify the exact policy.
>> > 
>> > Well, here is where it's tricky. I brought this up for one of the
>> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
>> > (and I'm paraphrasing) is there's not really an upstream for it to go.
>> > 
>> > What we cannot have is device tree bindings[1] that aren't upstream or
>> > worse yet conflict with the official bindings.
>> > 
>> > So the general way to resolve that is have device tree file be drop-in
>> > from the linux kernel, and what additions we must have be done via
>> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
>> > sync with the kernel than other SoCs are.
>> > 
>> > Now, upstream being actively hostile to dts files, especially for older
>> > platforms? That's unfortunate. So long as we aren't violating the rules
>> > about bindings, the intention is that we don't have device trees that
>> > are either (a) massively out of sync with the kernel[2] or (b) kept
>> > intentionally mismatched from the kernel.
>> > 
>> > -- 
>> > Tom
>> > 
>> > [1]: There are both examples like binman that Simon is working on at
>> > least but this is more exception than intentional rule.
>> > [2]: Per our other conversions, I know the tegra ones are in this
>> > unfortunate state in general
>> 
>> On the Tegra side we've been fairly lax about the device trees in
>> U-Boot, I suppose. The assumption had always been that U-Boot would load
>> an external DTB and pass it to the kernel on boot, so keeping them both
>> in sync was never a high priority.
>> 
>> U-Boot does only a very tiny amount of what Linux does, so dropping in
>> the kernel DTB always seemed a bit overkill.
>> 
>> In either case, if this is problematic, it's something that I could take
>> a look at. Again, it's expected that the device trees are different, for
>> historical reasons, but I'd be surprised if they actually conflict with
>> one another. U-Boot's DTB was always supposed to be a subset of the
>> Linux DTB.
>
>So, the issue with U-Boot and kernel device trees being out of sync is
>that we then can't support the model of "just pass the current DT to the
>OS". This in general is good to support because it means that even if a
>given platform isn't formally SystemReady IR certified it's still likely
>to be functional.
>
>The most strict rule is that you can't have bindings in U-Boot that
>conflict with the kernel, or should be in the kernel but aren't, and so
>on.
>

So you say that U-Boot should support only components which have linux driver? May you clarify?

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 5110 bytes --]

On Wed, Dec 13, 2023 at 11:42:45AM +0200, Svyatoslav Ryhel wrote:
> 
> 
> 15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini <trini@konsulko.com> написав(-ла):
> >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
> >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> >> > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >> > > >
> >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> >> > > > >
> >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> >> > > > > >
> >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> >> > > > > > >
> >> > > > > > > Hi Svyatoslav,
> >> > > > > > >
> >> > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> >> > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> >> > > > > > > >
> >> > > > > > > > Svyatoslav Ryhel (5):
> >> > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> >> > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> >> > > > > > >
> >> > > > > > > Is there a reason why the two above devices don't appear to have their
> >> > > > > > > .dts files in the upstream kernel?
> >> > > > > > >
> >> > > > > >
> >> > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> >> > > > > > existential enemies or as dirt at least. I was trying to work with
> >> > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> >> > > > > > lg_x3.
> >> > > > >
> >> > > > > The usual policy for acceptance into U-Boot is to have upstream review
> >> > > > > in the kernel first.
> >> > > > >
> >> > > >
> >> > > > May you point to a policy which clearly and explicitly states this as
> >> > > > a mandatory condition?
> >> > > 
> >> > > There have been a number of devices rejected in the past until their
> >> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> >> > > to clarify the exact policy.
> >> > 
> >> > Well, here is where it's tricky. I brought this up for one of the
> >> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> >> > (and I'm paraphrasing) is there's not really an upstream for it to go.
> >> > 
> >> > What we cannot have is device tree bindings[1] that aren't upstream or
> >> > worse yet conflict with the official bindings.
> >> > 
> >> > So the general way to resolve that is have device tree file be drop-in
> >> > from the linux kernel, and what additions we must have be done via
> >> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> >> > sync with the kernel than other SoCs are.
> >> > 
> >> > Now, upstream being actively hostile to dts files, especially for older
> >> > platforms? That's unfortunate. So long as we aren't violating the rules
> >> > about bindings, the intention is that we don't have device trees that
> >> > are either (a) massively out of sync with the kernel[2] or (b) kept
> >> > intentionally mismatched from the kernel.
> >> > 
> >> > -- 
> >> > Tom
> >> > 
> >> > [1]: There are both examples like binman that Simon is working on at
> >> > least but this is more exception than intentional rule.
> >> > [2]: Per our other conversions, I know the tegra ones are in this
> >> > unfortunate state in general
> >> 
> >> On the Tegra side we've been fairly lax about the device trees in
> >> U-Boot, I suppose. The assumption had always been that U-Boot would load
> >> an external DTB and pass it to the kernel on boot, so keeping them both
> >> in sync was never a high priority.
> >> 
> >> U-Boot does only a very tiny amount of what Linux does, so dropping in
> >> the kernel DTB always seemed a bit overkill.
> >> 
> >> In either case, if this is problematic, it's something that I could take
> >> a look at. Again, it's expected that the device trees are different, for
> >> historical reasons, but I'd be surprised if they actually conflict with
> >> one another. U-Boot's DTB was always supposed to be a subset of the
> >> Linux DTB.
> >
> >So, the issue with U-Boot and kernel device trees being out of sync is
> >that we then can't support the model of "just pass the current DT to the
> >OS". This in general is good to support because it means that even if a
> >given platform isn't formally SystemReady IR certified it's still likely
> >to be functional.
> >
> >The most strict rule is that you can't have bindings in U-Boot that
> >conflict with the kernel, or should be in the kernel but aren't, and so
> >on.
> >
> 
> So you say that U-Boot should support only components which have linux
> driver? May you clarify?

I think Tom is referring specifically to the bindings only. While it's
certainly preferable to have drivers in Linux for all bindings, that's
never been a strict requirement.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v1 0/5] Convert recently merged T30 boards to use DM PMIC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5676 bytes --]

On Wed, Dec 13, 2023 at 12:44:34PM +0100, Thierry Reding wrote:
> On Wed, Dec 13, 2023 at 11:42:45AM +0200, Svyatoslav Ryhel wrote:
> > 
> > 
> > 15 листопада 2023 р. 21:11:49 GMT+02:00, Tom Rini <trini@konsulko.com> написав(-ла):
> > >On Wed, Nov 15, 2023 at 04:51:08PM +0100, Thierry Reding wrote:
> > >> On Mon, Nov 06, 2023 at 04:04:07PM -0500, Tom Rini wrote:
> > >> > On Mon, Nov 06, 2023 at 02:11:16PM +0000, Peter Robinson wrote:
> > >> > > On Mon, Nov 6, 2023 at 1:28 PM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >> > > >
> > >> > > > пн, 6 лист. 2023 р. о 15:13 Peter Robinson <pbrobinson@gmail.com> пише:
> > >> > > > >
> > >> > > > > On Mon, Nov 6, 2023 at 11:58 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> > >> > > > > >
> > >> > > > > > пн, 6 лист. 2023 р. о 13:46 Peter Robinson <pbrobinson@gmail.com> пише:
> > >> > > > > > >
> > >> > > > > > > Hi Svyatoslav,
> > >> > > > > > >
> > >> > > > > > > > Since the proposed PMIC patches have been accepted, I see the need
> > >> > > > > > > > to convert boards which I maintain to use DM drivers instead of board hacks.
> > >> > > > > > > >
> > >> > > > > > > > Svyatoslav Ryhel (5):
> > >> > > > > > > >   board: lg-x3: convert LG Optimus 4X and Vu to use DM PMIC
> > >> > > > > > > >   board: endeavoru: convert HTC One X to use DM PMIC
> > >> > > > > > >
> > >> > > > > > > Is there a reason why the two above devices don't appear to have their
> > >> > > > > > > .dts files in the upstream kernel?
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > > Yes, there is a reason. Linux maintainers treat submitters as
> > >> > > > > > existential enemies or as dirt at least. I was trying to work with
> > >> > > > > > linux but I have no desire to spend any time to upstream endeavoru or
> > >> > > > > > lg_x3.
> > >> > > > >
> > >> > > > > The usual policy for acceptance into U-Boot is to have upstream review
> > >> > > > > in the kernel first.
> > >> > > > >
> > >> > > >
> > >> > > > May you point to a policy which clearly and explicitly states this as
> > >> > > > a mandatory condition?
> > >> > > 
> > >> > > There have been a number of devices rejected in the past until their
> > >> > > DT are upstream but I'll leave Tom, who I've explicitly added on cc:,
> > >> > > to clarify the exact policy.
> > >> > 
> > >> > Well, here is where it's tricky. I brought this up for one of the
> > >> > Broadcom MIPS platforms a week or two back, and Linus Walleij's point
> > >> > (and I'm paraphrasing) is there's not really an upstream for it to go.
> > >> > 
> > >> > What we cannot have is device tree bindings[1] that aren't upstream or
> > >> > worse yet conflict with the official bindings.
> > >> > 
> > >> > So the general way to resolve that is have device tree file be drop-in
> > >> > from the linux kernel, and what additions we must have be done via
> > >> > -u-boot.dtsi files. And in turn, some SoCs are better about keeping in
> > >> > sync with the kernel than other SoCs are.
> > >> > 
> > >> > Now, upstream being actively hostile to dts files, especially for older
> > >> > platforms? That's unfortunate. So long as we aren't violating the rules
> > >> > about bindings, the intention is that we don't have device trees that
> > >> > are either (a) massively out of sync with the kernel[2] or (b) kept
> > >> > intentionally mismatched from the kernel.
> > >> > 
> > >> > -- 
> > >> > Tom
> > >> > 
> > >> > [1]: There are both examples like binman that Simon is working on at
> > >> > least but this is more exception than intentional rule.
> > >> > [2]: Per our other conversions, I know the tegra ones are in this
> > >> > unfortunate state in general
> > >> 
> > >> On the Tegra side we've been fairly lax about the device trees in
> > >> U-Boot, I suppose. The assumption had always been that U-Boot would load
> > >> an external DTB and pass it to the kernel on boot, so keeping them both
> > >> in sync was never a high priority.
> > >> 
> > >> U-Boot does only a very tiny amount of what Linux does, so dropping in
> > >> the kernel DTB always seemed a bit overkill.
> > >> 
> > >> In either case, if this is problematic, it's something that I could take
> > >> a look at. Again, it's expected that the device trees are different, for
> > >> historical reasons, but I'd be surprised if they actually conflict with
> > >> one another. U-Boot's DTB was always supposed to be a subset of the
> > >> Linux DTB.
> > >
> > >So, the issue with U-Boot and kernel device trees being out of sync is
> > >that we then can't support the model of "just pass the current DT to the
> > >OS". This in general is good to support because it means that even if a
> > >given platform isn't formally SystemReady IR certified it's still likely
> > >to be functional.
> > >
> > >The most strict rule is that you can't have bindings in U-Boot that
> > >conflict with the kernel, or should be in the kernel but aren't, and so
> > >on.
> > >
> > 
> > So you say that U-Boot should support only components which have linux
> > driver? May you clarify?
> 
> I think Tom is referring specifically to the bindings only. While it's
> certainly preferable to have drivers in Linux for all bindings, that's
> never been a strict requirement.

All bindings must be upstreamed and we've been working with Rob (and
he's been receptive) on this point. There's U-Boot specific bindings,
even, now and those in turn pass validation in the kernel and can be
synced in here. Can you give an example of what you're concerned about
Svyatoslav?

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]