[PATCH V3 00/14] ARM: stm32: Fix Avenger96

[PATCH V3 00/14] ARM: stm32: Fix Avenger96

[Marek Vasut]

This series fixes the Avenger96 board. Since there are way too many patches
floating around on the ML and because I found various other details that
needed fixing, I decided to bundle the whole set of fixes into this series.

This should go into current release, otherwise the board doesn't even boot.
This V2 is also roughly synchronized with the Linux V2 series fixing very
much the same issues.

Marek Vasut (14):
  ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96
  ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins
  ARM: dts: stm32: Repair SDMMC1 operation on AV96
  ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
  ARM: dts: stm32: Repair SDMMC2 operation
  ARM: dts: stm32: Add QSPI NOR on AV96
  ARM: dts: stm32: Use DT alias for the configuration EEPROM
  ARM: dts: stm32: Add configuration EEPROM on AV96
  ARM: dts: stm32: Add alternate pinmux for ethernet RGMII
  ARM: dts: stm32: Repair ethernet operation on AV96
  ARM: dts: stm32: Add missing ethernet PHY reset on AV96
  ARM: dts: stm32: Repair PMIC configuration on AV96
  ARM: dts: stm32: Adjust PLL4 settings on AV96
  ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

 arch/arm/dts/Makefile                         |   3 +-
 arch/arm/dts/stm32mp157-pinctrl.dtsi          |  96 +++++
 arch/arm/dts/stm32mp157a-avenger96.dts        | 365 +-----------------
 arch/arm/dts/stm32mp15xx-dhcom.dtsi           |   6 +-
 .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi   |  80 ++++
 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts  | 211 ++++++++++
 ...oot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} |  80 +---
 arch/arm/dts/stm32mp15xx-dhcor.dtsi           | 231 +++++++++++
 board/dhelectronics/dh_stm32mp1/board.c       |  15 +-
 doc/board/st/stm32mp1.rst                     |   8 +-
 10 files changed, 645 insertions(+), 450 deletions(-)
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
 rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} (73%)
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor.dtsi

Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>

-- 
2.25.1

[PATCH V3 01/14] ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96

[Marek Vasut]

The sdmmc1_dir_pins_a: sdmmc1-dir-0 layout changed in commit 35a54d41d9d4
("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") such that pins{};
became pins1{};pins2{};, however the SPL extras were not updated to reflect
that change. Fix this.

This fixes booting from SD1 X9 slot on the AV96 board.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Fixes: 35a54d41d9d4 ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: Adjust patch subject
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index d6dc746365..8dcd8866e8 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -152,7 +152,10 @@
 
 &sdmmc1_dir_pins_a {
 	u-boot,dm-spl;
-	pins {
+	pins1 {
+		u-boot,dm-spl;
+	};
+	pins2 {
 		u-boot,dm-spl;
 	};
 };
-- 
2.25.1

[PATCH V3 01/14] ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> The sdmmc1_dir_pins_a: sdmmc1-dir-0 layout changed in commit 35a54d41d9d4
> ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") such that pins{}; became
> pins1{};pins2{};, however the SPL extras were not updated to reflect that change.
> Fix this.
> 
> This fixes booting from SD1 X9 slot on the AV96 board.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Fixes: 35a54d41d9d4 ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4")
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Adjust patch subject
> V3: No change
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 02/14] ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins

[Marek Vasut]

Add another mux option for SDMMC1 direction pins, in particular
SDMMC1_D123DIR, this is used on AV96 board.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: New patch
V3: No change
---
 arch/arm/dts/stm32mp157-pinctrl.dtsi | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 81a363d93d..6842d4cdca 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -832,6 +832,30 @@
 				};
 			};
 
+			sdmmc1_dir_pins_b: sdmmc1-dir-1 {
+				pins1 {
+					pinmux = <STM32_PINMUX('F', 2, AF11)>, /* SDMMC1_D0DIR */
+						 <STM32_PINMUX('E', 14, AF8)>, /* SDMMC1_D123DIR */
+						 <STM32_PINMUX('B', 9, AF11)>; /* SDMMC1_CDIR */
+					slew-rate = <1>;
+					drive-push-pull;
+					bias-pull-up;
+				};
+				pins2{
+					pinmux = <STM32_PINMUX('E', 4, AF8)>; /* SDMMC1_CKIN */
+					bias-pull-up;
+				};
+			};
+
+			sdmmc1_dir_sleep_pins_b: sdmmc1-dir-sleep-1 {
+				pins {
+					pinmux = <STM32_PINMUX('F', 2, ANALOG)>, /* SDMMC1_D0DIR */
+						 <STM32_PINMUX('E', 14, ANALOG)>, /* SDMMC1_D123DIR */
+						 <STM32_PINMUX('B', 9, ANALOG)>, /* SDMMC1_CDIR */
+						 <STM32_PINMUX('E', 4, ANALOG)>; /* SDMMC1_CKIN */
+				};
+			};
+
 			sdmmc2_b4_pins_a: sdmmc2-b4-0 {
 				pins1 {
 					pinmux = <STM32_PINMUX('B', 14, AF9)>, /* SDMMC2_D0 */
-- 
2.25.1

[PATCH V3 02/14] ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> Add another mux option for SDMMC1 direction pins, in particular
> SDMMC1_D123DIR, this is used on AV96 board.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: New patch
> V3: No change
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 03/14] ARM: dts: stm32: Repair SDMMC1 operation on AV96

[Marek Vasut]

The SD uses different pinmux for the D123DIRline, use such a pinmux,
otherwise there is a pinmux collision on the AV96. Add missing SD
voltage regulator switch and enable SDR104 operation.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: New patch
V3: No change
---
 .../arm/dts/stm32mp157a-avenger96-u-boot.dtsi |  2 +-
 arch/arm/dts/stm32mp157a-avenger96.dts        | 25 ++++++++++++++++---
 2 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 8dcd8866e8..47bfbb8d77 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -150,7 +150,7 @@
 	};
 };
 
-&sdmmc1_dir_pins_a {
+&sdmmc1_dir_pins_b {
 	u-boot,dm-spl;
 	pins1 {
 		u-boot,dm-spl;
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 3065593bf2..1e9b45b69d 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -76,6 +76,20 @@
 			default-state = "off";
 		};
 	};
+
+	sd_switch: regulator-sd_switch {
+		compatible = "regulator-gpio";
+		regulator-name = "sd_switch";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <2900000>;
+		regulator-type = "voltage";
+		regulator-always-on;
+
+		gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
+		gpios-states = <0>;
+		states = <1800000 0x1>,
+			 <2900000 0x0>;
+	};
 };
 
 &ethernet0 {
@@ -296,15 +310,18 @@
 
 &sdmmc1 {
 	pinctrl-names = "default", "opendrain", "sleep";
-	pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_a>;
-	pinctrl-1 = <&sdmmc1_b4_od_pins_a>;
-	pinctrl-2 = <&sdmmc1_b4_sleep_pins_a>;
-	broken-cd;
+	pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_b>;
+	pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_b>;
+	pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_b>;
+	cd-gpios = <&gpioi 8 GPIO_ACTIVE_LOW>;
+	disable-wp;
 	st,sig-dir;
 	st,neg-edge;
 	st,use-ckin;
+	sd-uhs-sdr104;
 	bus-width = <4>;
 	vmmc-supply = <&vdd_sd>;
+	vqmmc-supply = <&sd_switch>;
 	status = "okay";
 };
 
-- 
2.25.1

[PATCH V3 03/14] ARM: dts: stm32: Repair SDMMC1 operation on AV96

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> The SD uses different pinmux for the D123DIRline, use such a pinmux, otherwise
> there is a pinmux collision on the AV96. Add missing SD voltage regulator switch
> and enable SDR104 operation.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: New patch
> V3: No change
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 04/14] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7

[Marek Vasut]

Add another mux option for SDMMC2 pins 4..7, this is used on AV96 board.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: Use correct pin AFs
V3: No change
---
 arch/arm/dts/stm32mp157-pinctrl.dtsi | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 6842d4cdca..964e4910ec 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -931,6 +931,27 @@
 				};
 			};
 
+			sdmmc2_d47_pins_b: sdmmc2-d47-1 {
+				pins {
+					pinmux = <STM32_PINMUX('A', 8, AF9)>, /* SDMMC2_D4 */
+						 <STM32_PINMUX('A', 15, AF9)>, /* SDMMC2_D5 */
+						 <STM32_PINMUX('C', 6, AF10)>, /* SDMMC2_D6 */
+						 <STM32_PINMUX('C', 7, AF10)>; /* SDMMC2_D7 */
+					slew-rate = <1>;
+					drive-push-pull;
+					bias-pull-up;
+				};
+			};
+
+			sdmmc2_d47_sleep_pins_b: sdmmc2-d47-sleep-1 {
+				pins {
+					pinmux = <STM32_PINMUX('A', 8, ANALOG)>, /* SDMMC2_D4 */
+						 <STM32_PINMUX('A', 15, ANALOG)>, /* SDMMC2_D5 */
+						 <STM32_PINMUX('C', 6, ANALOG)>, /* SDMMC2_D6 */
+						 <STM32_PINMUX('C', 7, ANALOG)>; /* SDMMC2_D7 */
+				};
+			};
+
 			spdifrx_pins_a: spdifrx-0 {
 				pins {
 					pinmux = <STM32_PINMUX('G', 12, AF8)>; /* SPDIF_IN1 */
-- 
2.25.1

[PATCH V3 04/14] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> Add another mux option for SDMMC2 pins 4..7, this is used on AV96 board.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Use correct pin AFs
> V3: No change
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 05/14] ARM: dts: stm32: Repair SDMMC2 operation

[Marek Vasut]

The eMMC uses different pinmux for the top four data lines, use such
a pinmux, otherwise it takes a very long time until the test for 8bit
operation times out. And this is the correct pinmux per schematic too.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: Update also the -u-boot.dtsi to match this change
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 2 +-
 arch/arm/dts/stm32mp157a-avenger96.dts         | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 47bfbb8d77..2c7dc509a3 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -174,7 +174,7 @@
 	};
 };
 
-&sdmmc2_d47_pins_a {
+&sdmmc2_d47_pins_b {
 	u-boot,dm-spl;
 	pins {
 		u-boot,dm-spl;
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 1e9b45b69d..3fca1ed56d 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -327,7 +327,7 @@
 
 &sdmmc2 {
 	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc2_b4_pins_a &sdmmc2_d47_pins_a>;
+	pinctrl-0 = <&sdmmc2_b4_pins_a &sdmmc2_d47_pins_b>;
 	non-removable;
 	no-sd;
 	no-sdio;
-- 
2.25.1

[PATCH V3 05/14] ARM: dts: stm32: Repair SDMMC2 operation

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> The eMMC uses different pinmux for the top four data lines, use such a pinmux,
> otherwise it takes a very long time until the test for 8bit operation times out. And
> this is the correct pinmux per schematic too.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Update also the -u-boot.dtsi to match this change
> V3: No change
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96

[Marek Vasut]

The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it
into the DT.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: Drop the explicit flash type in DT node, use spi-flash
V3: Reduce the SPI NOR window to 2 MiB
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 3fca1ed56d..023390a662 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -20,6 +20,7 @@
 		mmc0 = &sdmmc1;
 		serial0 = &uart4;
 		serial1 = &uart7;
+		spi0 = &qspi;
 	};
 
 	chosen {
@@ -300,6 +301,25 @@
 	vdd_3v3_usbfs-supply = <&vdd_usb>;
 };
 
+&qspi {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
+	pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
+	reg = <0x58003000 0x1000>, <0x70000000 0x200000>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	flash0: spi-flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-rx-bus-width = <4>;
+		spi-max-frequency = <108000000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
+
 &rng1 {
 	status = "okay";
 };
-- 
2.25.1

[PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96

[Patrick DELAUNAY]

Hi Marek,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it into the
> DT.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Drop the explicit flash type in DT node, use spi-flash
> V3: Reduce the SPI NOR window to 2 MiB
> ---


Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

Thanks

Patrick

[PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96

[Patrick DELAUNAY]

Hi,

> -----Original Message-----
> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> To: u-boot at lists.denx.de
> Cc: Marek Vasut <marex@denx.de>; Manivannan Sadhasivam
> <manivannan.sadhasivam@linaro.org>; Patrick DELAUNAY
> <patrick.delaunay@st.com>; Patrice CHOTARD <patrice.chotard@st.com>
> Subject: [PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96
> Importance: High
> 
> The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it into the
> DT.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Drop the explicit flash type in DT node, use spi-flash
> V3: Reduce the SPI NOR window to 2 MiB
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 07/14] ARM: dts: stm32: Use DT alias for the configuration EEPROM

[Marek Vasut]

Use DT /aliases node to establish a stable phandle to the configuration
EEPROM. This permits the configuration EEPROM to be moved e.g. to a
different address or a different bus. Adjust the board code to handle
new phandle lookup.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/stm32mp15xx-dhcom.dtsi     |  6 +++++-
 board/dhelectronics/dh_stm32mp1/board.c | 15 +++++++--------
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/arch/arm/dts/stm32mp15xx-dhcom.dtsi b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
index bed69c97b6..e5be0a79ac 100644
--- a/arch/arm/dts/stm32mp15xx-dhcom.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcom.dtsi
@@ -10,6 +10,10 @@
 #include <dt-bindings/mfd/st,stpmic1.h>
 
 / {
+	aliases {
+		eeprom0 = &eeprom0;
+	};
+
 	memory at c0000000 {
 		device_type = "memory";
 		reg = <0xC0000000 0x40000000>;
@@ -187,7 +191,7 @@
 		};
 	};
 
-	eeprom at 50 {
+	eeprom0: eeprom at 50 {
 		compatible = "atmel,24c02";
 		reg = <0x50>;
 		pagesize = <16>;
diff --git a/board/dhelectronics/dh_stm32mp1/board.c b/board/dhelectronics/dh_stm32mp1/board.c
index 109d9ec935..a3458a2623 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -78,22 +78,21 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int setup_mac_address(void)
 {
-	struct udevice *dev;
-	ofnode eeprom;
 	unsigned char enetaddr[6];
-	int ret;
+	struct udevice *dev;
+	int off, ret;
 
 	ret = eth_env_get_enetaddr("ethaddr", enetaddr);
 	if (ret)	/* ethaddr is already set */
 		return 0;
 
-	eeprom = ofnode_path("/soc/i2c at 5c002000/eeprom at 50");
-	if (!ofnode_valid(eeprom)) {
-		printf("Invalid hardware path to EEPROM!\n");
-		return -ENODEV;
+	off = fdt_path_offset(gd->fdt_blob, "eeprom0");
+	if (off < 0) {
+		printf("%s: No eeprom0 path offset\n", __func__);
+		return off;
 	}
 
-	ret = uclass_get_device_by_ofnode(UCLASS_I2C_EEPROM, eeprom, &dev);
+	ret = uclass_get_device_by_of_offset(UCLASS_I2C_EEPROM, off, &dev);
 	if (ret) {
 		printf("Cannot find EEPROM!\n");
 		return ret;
-- 
2.25.1

[PATCH V3 07/14] ARM: dts: stm32: Use DT alias for the configuration EEPROM

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:51
> 
> Use DT /aliases node to establish a stable phandle to the configuration EEPROM.
> This permits the configuration EEPROM to be moved e.g. to a different address or
> a different bus. Adjust the board code to handle new phandle lookup.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96

[Marek Vasut]

The board has an EEPROM on the same I2C bus as PMIC, at address 0x53.
The EEPROM contains the board MAC address.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 023390a662..5c7a326c12 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -289,6 +289,12 @@
 			status = "disabled";
 		};
 	};
+
+	eeprom at 53 {
+		compatible = "atmel,24c02";
+		reg = <0x53>;
+		pagesize = <16>;
+	};
 };
 
 &iwdg2 {
-- 
2.25.1

[PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The board has an EEPROM on the same I2C bus as PMIC, at address 0x53.
> The EEPROM contains the board MAC address.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, with one minor modification

I also add the alias eeprom0 = &eeprom0 (with eeprom0: eeprom at 53) to be compatible
with previous patch "ARM: dts: stm32: Use DT alias for the configuration EEPROM"

Regards

Patrick

[PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96

[Marek Vasut]

On 4/1/20 12:02 PM, Patrick DELAUNAY wrote:
> Hi,

Hi,

>> From: Marek Vasut <marex@denx.de>
>> Sent: mardi 31 mars 2020 19:52
>>
>> The board has an EEPROM on the same I2C bus as PMIC, at address 0x53.
>> The EEPROM contains the board MAC address.
>>
>> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
>> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Cc: Patrick Delaunay <patrick.delaunay@st.com>
>> Cc: Patrice Chotard <patrice.chotard@st.com>
>> ---
> 
> Applied to u-boot-stm/master, with one minor modification
> 
> I also add the alias eeprom0 = &eeprom0 (with eeprom0: eeprom at 53) to be compatible
> with previous patch "ARM: dts: stm32: Use DT alias for the configuration EEPROM"

Thanks, this was in 14/14, but got omitted here.

[PATCH V3 09/14] ARM: dts: stm32: Add alternate pinmux for ethernet RGMII

[Marek Vasut]

Add another mux option for DWMAC RGMII, this is used on AV96 board.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/stm32mp157-pinctrl.dtsi | 51 ++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/dts/stm32mp157-pinctrl.dtsi b/arch/arm/dts/stm32mp157-pinctrl.dtsi
index 964e4910ec..422dad1ddd 100644
--- a/arch/arm/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/dts/stm32mp157-pinctrl.dtsi
@@ -288,6 +288,57 @@
 				};
 			};
 
+			ethernet0_rgmii_pins_b: rgmii-1 {
+				pins1 {
+					pinmux = <STM32_PINMUX('G', 5, AF11)>, /* ETH_RGMII_CLK125 */
+						 <STM32_PINMUX('G', 4, AF11)>, /* ETH_RGMII_GTX_CLK */
+						 <STM32_PINMUX('B', 12, AF11)>, /* ETH_RGMII_TXD0 */
+						 <STM32_PINMUX('G', 14, AF11)>, /* ETH_RGMII_TXD1 */
+						 <STM32_PINMUX('C', 2, AF11)>, /* ETH_RGMII_TXD2 */
+						 <STM32_PINMUX('E', 2, AF11)>, /* ETH_RGMII_TXD3 */
+						 <STM32_PINMUX('G', 11, AF11)>, /* ETH_RGMII_TX_CTL */
+						 <STM32_PINMUX('C', 1, AF11)>; /* ETH_MDC */
+					bias-disable;
+					drive-push-pull;
+					slew-rate = <2>;
+				};
+				pins2 {
+					pinmux = <STM32_PINMUX('A', 2, AF11)>; /* ETH_MDIO */
+					bias-disable;
+					drive-push-pull;
+					slew-rate = <0>;
+				};
+				pins3 {
+					pinmux = <STM32_PINMUX('C', 4, AF11)>, /* ETH_RGMII_RXD0 */
+						 <STM32_PINMUX('C', 5, AF11)>, /* ETH_RGMII_RXD1 */
+						 <STM32_PINMUX('H', 6, AF11)>, /* ETH_RGMII_RXD2 */
+						 <STM32_PINMUX('B', 1, AF11)>, /* ETH_RGMII_RXD3 */
+						 <STM32_PINMUX('A', 1, AF11)>, /* ETH_RGMII_RX_CLK */
+						 <STM32_PINMUX('A', 7, AF11)>; /* ETH_RGMII_RX_CTL */
+					bias-disable;
+				};
+			};
+
+			ethernet0_rgmii_pins_sleep_b: rgmii-sleep-1 {
+				pins1 {
+					pinmux = <STM32_PINMUX('G', 5, ANALOG)>, /* ETH_RGMII_CLK125 */
+						 <STM32_PINMUX('G', 4, ANALOG)>, /* ETH_RGMII_GTX_CLK */
+						 <STM32_PINMUX('B', 12, ANALOG)>, /* ETH_RGMII_TXD0 */
+						 <STM32_PINMUX('G', 14, ANALOG)>, /* ETH_RGMII_TXD1 */
+						 <STM32_PINMUX('C', 2, ANALOG)>, /* ETH_RGMII_TXD2 */
+						 <STM32_PINMUX('E', 2, ANALOG)>, /* ETH_RGMII_TXD3 */
+						 <STM32_PINMUX('G', 11, ANALOG)>, /* ETH_RGMII_TX_CTL */
+						 <STM32_PINMUX('A', 2, ANALOG)>, /* ETH_MDIO */
+						 <STM32_PINMUX('C', 1, ANALOG)>, /* ETH_MDC */
+						 <STM32_PINMUX('C', 4, ANALOG)>, /* ETH_RGMII_RXD0 */
+						 <STM32_PINMUX('C', 5, ANALOG)>, /* ETH_RGMII_RXD1 */
+						 <STM32_PINMUX('H', 6, ANALOG)>, /* ETH_RGMII_RXD2 */
+						 <STM32_PINMUX('B', 1, ANALOG)>, /* ETH_RGMII_RXD3 */
+						 <STM32_PINMUX('A', 1, ANALOG)>, /* ETH_RGMII_RX_CLK */
+						 <STM32_PINMUX('A', 7, ANALOG)>; /* ETH_RGMII_RX_CTL */
+				};
+			};
+
 			fmc_pins_a: fmc-0 {
 				pins1 {
 					pinmux = <STM32_PINMUX('D', 4, AF12)>, /* FMC_NOE */
-- 
2.25.1

[PATCH V3 09/14] ARM: dts: stm32: Add alternate pinmux for ethernet RGMII

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> Add another mux option for DWMAC RGMII, this is used on AV96 board.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 10/14] ARM: dts: stm32: Repair ethernet operation on AV96

[Marek Vasut]

The AV96 RGMII uses different pinmux for ETH_RGMII_TXD0, ETH_RGMII_RXD2
and ETH_RGMII_TX_CTL. Use the correct pinmux to make ethernet operational.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 5c7a326c12..88537e6769 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -95,8 +95,8 @@
 
 &ethernet0 {
 	status = "okay";
-	pinctrl-0 = <&ethernet0_rgmii_pins_a>;
-	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_a>;
+	pinctrl-0 = <&ethernet0_rgmii_pins_b>;
+	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_b>;
 	pinctrl-names = "default", "sleep";
 	phy-mode = "rgmii";
 	max-speed = <1000>;
-- 
2.25.1

[PATCH V3 10/14] ARM: dts: stm32: Repair ethernet operation on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The AV96 RGMII uses different pinmux for ETH_RGMII_TXD0,
> ETH_RGMII_RXD2 and ETH_RGMII_TX_CTL. Use the correct pinmux to make
> ethernet operational.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96

[Marek Vasut]

Add PHY reset GPIO on AV96 ethernet PHY.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 88537e6769..8181d1fa05 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -101,6 +101,7 @@
 	phy-mode = "rgmii";
 	max-speed = <1000>;
 	phy-handle = <&phy0>;
+	phy-reset-gpios = <&gpioz 2 GPIO_ACTIVE_LOW>;
 
 	mdio0 {
 		#address-cells = <1>;
-- 
2.25.1

[PATCH V3 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> Add PHY reset GPIO on AV96 ethernet PHY.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

The core and vdd PMIC buck regulators were misconfigured, which caused
instability of the board and malfunction of high-speed interfaces, like
the RGMII. Configure the PMIC correctly to repair these problems. Also,
model the missing Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: - Model the Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator
    - Adjust the PMIC voltages further
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96.dts | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 8181d1fa05..97ff40144e 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -91,6 +91,17 @@
 		states = <1800000 0x1>,
 			 <2900000 0x0>;
 	};
+
+	/* Enpirion EP3A8LQI U2 on the DHCOR */
+	vdd_io: regulator-buck-io {
+		compatible = "regulator-fixed";
+		regulator-name = "buck-io";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd>;
+	};
 };
 
 &ethernet0 {
@@ -167,7 +178,7 @@
 
 			vddcore: buck1 {
 				regulator-name = "vddcore";
-				regulator-min-microvolt = <1200000>;
+				regulator-min-microvolt = <800000>;
 				regulator-max-microvolt = <1350000>;
 				regulator-always-on;
 				regulator-initial-mode = <0>;
@@ -185,8 +196,8 @@
 
 			vdd: buck3 {
 				regulator-name = "vdd";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
+				regulator-min-microvolt = <2900000>;
+				regulator-max-microvolt = <2900000>;
 				regulator-always-on;
 				st,mask_reset;
 				regulator-initial-mode = <0>;
@@ -268,6 +279,7 @@
 				regulator-name = "vbus_otg";
 				interrupts = <IT_OCP_OTG 0>;
 				interrupt-parent = <&pmic>;
+				regulator-active-discharge = <1>;
 			};
 
 			vbus_sw: pwr_sw2 {
@@ -304,7 +316,7 @@
 };
 
 &pwr_regulators {
-	vdd-supply = <&vdd>;
+	vdd-supply = <&vdd_io>;
 	vdd_3v3_usbfs-supply = <&vdd_usb>;
 };
 
-- 
2.25.1

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Patrick DELAUNAY]

Hi Marek and Pascal,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The core and vdd PMIC buck regulators were misconfigured, which caused
> instability of the board and malfunction of high-speed interfaces, like the RGMII.
> Configure the PMIC correctly to repair these problems. Also, model the missing
> Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: - Model the Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator
>     - Adjust the PMIC voltages further
> V3: No change
> ---
>  arch/arm/dts/stm32mp157a-avenger96.dts | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts
> b/arch/arm/dts/stm32mp157a-avenger96.dts
> index 8181d1fa05..97ff40144e 100644
> --- a/arch/arm/dts/stm32mp157a-avenger96.dts
> +++ b/arch/arm/dts/stm32mp157a-avenger96.dts
> @@ -91,6 +91,17 @@
>  		states = <1800000 0x1>,
>  			 <2900000 0x0>;
>  	};
> +
> +	/* Enpirion EP3A8LQI U2 on the DHCOR */
> +	vdd_io: regulator-buck-io {
> +		compatible = "regulator-fixed";
> +		regulator-name = "buck-io";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vdd>;
> +	};
>  };
> 
>  &ethernet0 {
> @@ -167,7 +178,7 @@
> 
>  			vddcore: buck1 {
>  				regulator-name = "vddcore";
> -				regulator-min-microvolt = <1200000>;
> +				regulator-min-microvolt = <800000>;

I don't understood this modification, If I correctly remember, on STM32MP15x 
On ST boards, we set this value to 1200000 to protect VDDCORE on
SOC (it is not allowed to be reduce lower than 1,2V.

0.8V is the minimal supported voltage by STPMIC but not the minal expected 
VDDCORE.

>  				regulator-max-microvolt = <1350000>;
>  				regulator-always-on;
>  				regulator-initial-mode = <0>;
> @@ -185,8 +196,8 @@
> 
>  			vdd: buck3 {
>  				regulator-name = "vdd";
> -				regulator-min-microvolt = <3300000>;
> -				regulator-max-microvolt = <3300000>;
> +				regulator-min-microvolt = <2900000>;
> +				regulator-max-microvolt = <2900000>;
>  				regulator-always-on;
>  				st,mask_reset;
>  				regulator-initial-mode = <0>;
> @@ -268,6 +279,7 @@
>  				regulator-name = "vbus_otg";
>  				interrupts = <IT_OCP_OTG 0>;
>  				interrupt-parent = <&pmic>;
> +				regulator-active-discharge = <1>;

It seems this setting introduced other-consumption, it should not be used.

>  			};
> 
>  			vbus_sw: pwr_sw2 {
> @@ -304,7 +316,7 @@
>  };
> 
>  &pwr_regulators {
> -	vdd-supply = <&vdd>;
> +	vdd-supply = <&vdd_io>;
>  	vdd_3v3_usbfs-supply = <&vdd_usb>;
>  };
> 
> --
> 2.25.1

I let Pascal complete my first feedback or react on the Linux upstream.

Patrick

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> Hi Marek and Pascal,

Hi,

[...]

>> @@ -167,7 +178,7 @@
>>
>>  			vddcore: buck1 {
>>  				regulator-name = "vddcore";
>> -				regulator-min-microvolt = <1200000>;
>> +				regulator-min-microvolt = <800000>;
> 
> I don't understood this modification, If I correctly remember, on STM32MP15x 
> On ST boards, we set this value to 1200000 to protect VDDCORE on
> SOC (it is not allowed to be reduce lower than 1,2V.
> 
> 0.8V is the minimal supported voltage by STPMIC but not the minal expected 
> VDDCORE.

Then we should likely drop this part.

That said, is the core voltage supposed to be 1V2 even in sleep states ?

>> @@ -185,8 +196,8 @@
>>
>>  			vdd: buck3 {
>>  				regulator-name = "vdd";
>> -				regulator-min-microvolt = <3300000>;
>> -				regulator-max-microvolt = <3300000>;
>> +				regulator-min-microvolt = <2900000>;
>> +				regulator-max-microvolt = <2900000>;
>>  				regulator-always-on;
>>  				st,mask_reset;
>>  				regulator-initial-mode = <0>;
>> @@ -268,6 +279,7 @@
>>  				regulator-name = "vbus_otg";
>>  				interrupts = <IT_OCP_OTG 0>;
>>  				interrupt-parent = <&pmic>;
>> +				regulator-active-discharge = <1>;
> 
> It seems this setting introduced other-consumption, it should not be used.

Other-consumption ? What does that mean ?

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Patrice CHOTARD]

On 4/1/20 1:06 PM, Marek Vasut wrote:
> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
>> Hi Marek and Pascal,
> Hi,
>
> [...]
>
>>> @@ -167,7 +178,7 @@
>>>
>>>  			vddcore: buck1 {
>>>  				regulator-name = "vddcore";
>>> -				regulator-min-microvolt = <1200000>;
>>> +				regulator-min-microvolt = <800000>;
>> I don't understood this modification, If I correctly remember, on STM32MP15x 
>> On ST boards, we set this value to 1200000 to protect VDDCORE on
>> SOC (it is not allowed to be reduce lower than 1,2V.
>>
>> 0.8V is the minimal supported voltage by STPMIC but not the minal expected 
>> VDDCORE.
> Then we should likely drop this part.
>
> That said, is the core voltage supposed to be 1V2 even in sleep states ?
>
>>> @@ -185,8 +196,8 @@
>>>
>>>  			vdd: buck3 {
>>>  				regulator-name = "vdd";
>>> -				regulator-min-microvolt = <3300000>;
>>> -				regulator-max-microvolt = <3300000>;
>>> +				regulator-min-microvolt = <2900000>;
>>> +				regulator-max-microvolt = <2900000>;
>>>  				regulator-always-on;
>>>  				st,mask_reset;
>>>  				regulator-initial-mode = <0>;
>>> @@ -268,6 +279,7 @@
>>>  				regulator-name = "vbus_otg";
>>>  				interrupts = <IT_OCP_OTG 0>;
>>>  				interrupt-parent = <&pmic>;
>>> +				regulator-active-discharge = <1>;
>> It seems this setting introduced other-consumption, it should not be used.
> Other-consumption ? What does that mean ?

It's a typo, Patrick means over-consumption.

Patrice

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
> 
> On 4/1/20 1:06 PM, Marek Vasut wrote:
>> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
>>> Hi Marek and Pascal,
>> Hi,
>>
>> [...]
>>
>>>> @@ -167,7 +178,7 @@
>>>>
>>>>  			vddcore: buck1 {
>>>>  				regulator-name = "vddcore";
>>>> -				regulator-min-microvolt = <1200000>;
>>>> +				regulator-min-microvolt = <800000>;
>>> I don't understood this modification, If I correctly remember, on STM32MP15x 
>>> On ST boards, we set this value to 1200000 to protect VDDCORE on
>>> SOC (it is not allowed to be reduce lower than 1,2V.
>>>
>>> 0.8V is the minimal supported voltage by STPMIC but not the minal expected 
>>> VDDCORE.
>> Then we should likely drop this part.
>>
>> That said, is the core voltage supposed to be 1V2 even in sleep states ?
>>
>>>> @@ -185,8 +196,8 @@
>>>>
>>>>  			vdd: buck3 {
>>>>  				regulator-name = "vdd";
>>>> -				regulator-min-microvolt = <3300000>;
>>>> -				regulator-max-microvolt = <3300000>;
>>>> +				regulator-min-microvolt = <2900000>;
>>>> +				regulator-max-microvolt = <2900000>;
>>>>  				regulator-always-on;
>>>>  				st,mask_reset;
>>>>  				regulator-initial-mode = <0>;
>>>> @@ -268,6 +279,7 @@
>>>>  				regulator-name = "vbus_otg";
>>>>  				interrupts = <IT_OCP_OTG 0>;
>>>>  				interrupt-parent = <&pmic>;
>>>> +				regulator-active-discharge = <1>;
>>> It seems this setting introduced other-consumption, it should not be used.
>> Other-consumption ? What does that mean ?
> 
> It's a typo, Patrick means over-consumption.

Ah. Do you have any details on that ?

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mercredi 1 avril 2020 14:53
> To: Patrice CHOTARD <patrice.chotard@st.com>; Patrick DELAUNAY
> <patrick.delaunay@st.com>; u-boot at lists.denx.de; Pascal PAILLET-LME
> <p.paillet@st.com>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>; Alexandre
> TORGUE <alexandre.torgue@st.com>
> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
> AV96
> Importance: High
> 
> On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
> >
> > On 4/1/20 1:06 PM, Marek Vasut wrote:
> >> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> >>> Hi Marek and Pascal,
> >> Hi,
> >>
> >> [...]
[...]
> >>>>  			vdd: buck3 {
> >>>>  				regulator-name = "vdd";
> >>>> -				regulator-min-microvolt = <3300000>;
> >>>> -				regulator-max-microvolt = <3300000>;
> >>>> +				regulator-min-microvolt = <2900000>;
> >>>> +				regulator-max-microvolt = <2900000>;
> >>>>  				regulator-always-on;
> >>>>  				st,mask_reset;
> >>>>  				regulator-initial-mode = <0>;
> >>>> @@ -268,6 +279,7 @@
> >>>>  				regulator-name = "vbus_otg";
> >>>>  				interrupts = <IT_OCP_OTG 0>;
> >>>>  				interrupt-parent = <&pmic>;
> >>>> +				regulator-active-discharge = <1>;
> >>> It seems this setting introduced other-consumption, it should not be used.
> >> Other-consumption ? What does that mean ?
> >
> > It's a typo, Patrick means over-consumption.
> 
> Ah. Do you have any details on that ?

Sorry for typo.

No details on my side, it was a Pascal Paillet's direct feedback
(Maintainer of STPMIC1 driver in Linux).

Anyway he will review your patch for Linux, with more details,
and I merge this patch without modification for U-Boot.

Patrick

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/1/20 3:52 PM, Patrick DELAUNAY wrote:
> Hi,
> 
>> From: Marek Vasut <marex@denx.de>
>> Sent: mercredi 1 avril 2020 14:53
>> To: Patrice CHOTARD <patrice.chotard@st.com>; Patrick DELAUNAY
>> <patrick.delaunay@st.com>; u-boot at lists.denx.de; Pascal PAILLET-LME
>> <p.paillet@st.com>
>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>; Alexandre
>> TORGUE <alexandre.torgue@st.com>
>> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
>> AV96
>> Importance: High
>>
>> On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
>>>
>>> On 4/1/20 1:06 PM, Marek Vasut wrote:
>>>> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
>>>>> Hi Marek and Pascal,
>>>> Hi,
>>>>
>>>> [...]
> [...]
>>>>>>  			vdd: buck3 {
>>>>>>  				regulator-name = "vdd";
>>>>>> -				regulator-min-microvolt = <3300000>;
>>>>>> -				regulator-max-microvolt = <3300000>;
>>>>>> +				regulator-min-microvolt = <2900000>;
>>>>>> +				regulator-max-microvolt = <2900000>;
>>>>>>  				regulator-always-on;
>>>>>>  				st,mask_reset;
>>>>>>  				regulator-initial-mode = <0>;
>>>>>> @@ -268,6 +279,7 @@
>>>>>>  				regulator-name = "vbus_otg";
>>>>>>  				interrupts = <IT_OCP_OTG 0>;
>>>>>>  				interrupt-parent = <&pmic>;
>>>>>> +				regulator-active-discharge = <1>;
>>>>> It seems this setting introduced other-consumption, it should not be used.
>>>> Other-consumption ? What does that mean ?
>>>
>>> It's a typo, Patrick means over-consumption.
>>
>> Ah. Do you have any details on that ?
> 
> Sorry for typo.
> 
> No details on my side, it was a Pascal Paillet's direct feedback
> (Maintainer of STPMIC1 driver in Linux).
> 
> Anyway he will review your patch for Linux, with more details,
> and I merge this patch without modification for U-Boot.

OK

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Pascal PAILLET-LME]

Hi Marek,


> -----Original Message-----
> From: Patrick DELAUNAY <patrick.delaunay@st.com>
> Sent: mercredi 1 avril 2020 15:52
> To: Marek Vasut <marex@denx.de>; Patrice CHOTARD
> <patrice.chotard@st.com>; u-boot at lists.denx.de; Pascal PAILLET-LME
> <p.paillet@st.com>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>;
> Alexandre TORGUE <alexandre.torgue@st.com>
> Subject: RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
> AV96
> 
> Hi,
> 
> > From: Marek Vasut <marex@denx.de>
> > Sent: mercredi 1 avril 2020 14:53
> > To: Patrice CHOTARD <patrice.chotard@st.com>; Patrick DELAUNAY
> > <patrick.delaunay@st.com>; u-boot at lists.denx.de; Pascal PAILLET-LME
> > <p.paillet@st.com>
> > Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>;
> > Alexandre TORGUE <alexandre.torgue@st.com>
> > Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC
> > configuration on
> > AV96
> > Importance: High
> >
> > On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
> > >
> > > On 4/1/20 1:06 PM, Marek Vasut wrote:
> > >> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> > >>> Hi Marek and Pascal,
> > >> Hi,
> > >>
> > >> [...]
> [...]
> > >>>>  			vdd: buck3 {
> > >>>>  				regulator-name = "vdd";
> > >>>> -				regulator-min-microvolt = <3300000>;
> > >>>> -				regulator-max-microvolt = <3300000>;
> > >>>> +				regulator-min-microvolt = <2900000>;
> > >>>> +				regulator-max-microvolt = <2900000>;
> > >>>>  				regulator-always-on;
> > >>>>  				st,mask_reset;
> > >>>>  				regulator-initial-mode = <0>; @@ -
> 268,6 +279,7 @@
> > >>>>  				regulator-name = "vbus_otg";
> > >>>>  				interrupts = <IT_OCP_OTG 0>;
> > >>>>  				interrupt-parent = <&pmic>;
> > >>>> +				regulator-active-discharge = <1>;
> > >>> It seems this setting introduced other-consumption, it should not be
> used.
> > >> Other-consumption ? What does that mean ?
> > >
> > > It's a typo, Patrick means over-consumption.
> >
> > Ah. Do you have any details on that ?
> 
> Sorry for typo.
> 
> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer of
> STPMIC1 driver in Linux).
You can enable the active discharge on the STPMIC1's VBUSOTG. But, as soon as a USB host peripheral (such as laptop) will attach and provide VBUS, there will be a ~8mA continuous power consumption on VBUS through this OTG active discharge. There is no functional issue behind this 8mA; but you need to know that 8mA is not compliant with the USB suspend constraint (2.5mA max).
> 
> Anyway he will review your patch for Linux, with more details, and I merge
> this patch without modification for U-Boot.
> 
> Patrick

Pascal

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/2/20 2:53 PM, Pascal PAILLET-LME wrote:
> Hi Marek,

Hi,
[...]
>>>>>>>  			vdd: buck3 {
>>>>>>>  				regulator-name = "vdd";
>>>>>>> -				regulator-min-microvolt = <3300000>;
>>>>>>> -				regulator-max-microvolt = <3300000>;
>>>>>>> +				regulator-min-microvolt = <2900000>;
>>>>>>> +				regulator-max-microvolt = <2900000>;
>>>>>>>  				regulator-always-on;
>>>>>>>  				st,mask_reset;
>>>>>>>  				regulator-initial-mode = <0>; @@ -
>> 268,6 +279,7 @@
>>>>>>>  				regulator-name = "vbus_otg";
>>>>>>>  				interrupts = <IT_OCP_OTG 0>;
>>>>>>>  				interrupt-parent = <&pmic>;
>>>>>>> +				regulator-active-discharge = <1>;
>>>>>> It seems this setting introduced other-consumption, it should not be
>> used.
>>>>> Other-consumption ? What does that mean ?
>>>>
>>>> It's a typo, Patrick means over-consumption.
>>>
>>> Ah. Do you have any details on that ?
>>
>> Sorry for typo.
>>
>> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer of
>> STPMIC1 driver in Linux).
> You can enable the active discharge on the STPMIC1's VBUSOTG. But, as soon as a USB host peripheral (such as laptop) will attach and provide VBUS, there will be a ~8mA continuous power consumption on VBUS through this OTG active discharge. There is no functional issue behind this 8mA; but you need to know that 8mA is not compliant with the USB suspend constraint (2.5mA max).

So why is it in there ?

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Pascal PAILLET-LME]

> -----Original Message-----
> From: Marek Vasut <marex@denx.de>
> Sent: jeudi 2 avril 2020 15:07
> To: Pascal PAILLET-LME <p.paillet@st.com>; Patrick DELAUNAY
> <patrick.delaunay@st.com>; Patrice CHOTARD <patrice.chotard@st.com>; u-
> boot at lists.denx.de
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>;
> Alexandre TORGUE <alexandre.torgue@st.com>
> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration
> on AV96
> 
> On 4/2/20 2:53 PM, Pascal PAILLET-LME wrote:
> > Hi Marek,
> 
> Hi,
> [...]
> >>>>>>>  			vdd: buck3 {
> >>>>>>>  				regulator-name = "vdd";
> >>>>>>> -				regulator-min-microvolt = <3300000>;
> >>>>>>> -				regulator-max-microvolt = <3300000>;
> >>>>>>> +				regulator-min-microvolt = <2900000>;
> >>>>>>> +				regulator-max-microvolt = <2900000>;
> >>>>>>>  				regulator-always-on;
> >>>>>>>  				st,mask_reset;
> >>>>>>>  				regulator-initial-mode = <0>; @@ -
> >> 268,6 +279,7 @@
> >>>>>>>  				regulator-name = "vbus_otg";
> >>>>>>>  				interrupts = <IT_OCP_OTG 0>;
> >>>>>>>  				interrupt-parent = <&pmic>;
> >>>>>>> +				regulator-active-discharge = <1>;
> >>>>>> It seems this setting introduced other-consumption, it should not be
> >> used.
> >>>>> Other-consumption ? What does that mean ?
> >>>>
> >>>> It's a typo, Patrick means over-consumption.
> >>>
> >>> Ah. Do you have any details on that ?
> >>
> >> Sorry for typo.
> >>
> >> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer
> of
> >> STPMIC1 driver in Linux).
> > You can enable the active discharge on the STPMIC1's VBUSOTG. But, as
> soon as a USB host peripheral (such as laptop) will attach and provide VBUS,
> there will be a ~8mA continuous power consumption on VBUS through this
> OTG active discharge. There is no functional issue behind this 8mA; but you
> need to know that 8mA is not compliant with the USB suspend constraint
> (2.5mA max).
> 
> So why is it in there ?
Sorry, I'm not sure to catch your point... The property is available because the stpmic1
Propose this feature (enable a pull down resistor when VBUS_OTG is disabled). We have
Found during some test that it is better to not enable active discharge on vbus_otg.
I hope it answers,
pascal

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Marek Vasut]

On 4/2/20 3:43 PM, Pascal PAILLET-LME wrote:
Hi,

[...]

>>>> No details on my side, it was a Pascal Paillet's direct feedback (Maintainer
>> of
>>>> STPMIC1 driver in Linux).
>>> You can enable the active discharge on the STPMIC1's VBUSOTG. But, as
>> soon as a USB host peripheral (such as laptop) will attach and provide VBUS,
>> there will be a ~8mA continuous power consumption on VBUS through this
>> OTG active discharge. There is no functional issue behind this 8mA; but you
>> need to know that 8mA is not compliant with the USB suspend constraint
>> (2.5mA max).
>>
>> So why is it in there ?
> Sorry, I'm not sure to catch your point... The property is available because the stpmic1
> Propose this feature (enable a pull down resistor when VBUS_OTG is disabled). We have
> Found during some test that it is better to not enable active discharge on vbus_otg.
> I hope it answers,
> pascal

Can you go into a bit more detail on what you found during your tests
and why it was a problem ?

[PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The core and vdd PMIC buck regulators were misconfigured, which caused
> instability of the board and malfunction of high-speed interfaces, like the RGMII.
> Configure the PMIC correctly to repair these problems. Also, model the missing
> Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Marek Vasut]

The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
can not easily divide the clock down to e.g. 50 MHz for high speed
SD and eMMC devices, so those devices end up running at 30 MHz as
that is 120 MHz / 4. Adjust the PLL4 settings such that both PLL4P
and PLL4R run at 100 MHz instead, which is easy to divide to 50MHz
for optimal operation of both SD and eMMC, SPDIF clock are not that
much slower and FDCAN is also unaffected.

Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: Move this patch before the split of AV96 into SoM and carrier
V3: No change
---
 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
index 2c7dc509a3..320132a01e 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
@@ -130,11 +130,11 @@
 		u-boot,dm-pre-reloc;
 	};
 
-	/* VCO = 480.0 MHz => P = 120, Q = 40, R = 96 */
+	/* VCO = 600.0 MHz => P = 100, Q = 50, R = 100 */
 	pll4: st,pll at 3 {
 		compatible = "st,stm32mp1-pll";
 		reg = <3>;
-		cfg = < 1 39 3 11 4 PQR(1,1,1) >;
+		cfg = < 1 49 5 11 5 PQR(1,1,1) >;
 		u-boot,dm-pre-reloc;
 	};
 };
-- 
2.25.1

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Patrick DELAUNAY]

Hi Gerald and Manivannan,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which can not
> easily divide the clock down to e.g. 50 MHz for high speed SD and eMMC
> devices, so those devices end up running at 30 MHz as that is 120 MHz / 4.
> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100 MHz
> instead, which is easy to divide to 50MHz for optimal operation of both SD and
> eMMC, SPDIF clock are not that much slower and FDCAN is also unaffected.
> 
> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: Move this patch before the split of AV96 into SoM and carrier
> V3: No change
> ---

This patch update the PLL4 frequency used on AV96 board,
with different of reference clock tree used on ST board,
this new setting allow to optimize the SDMMC frequency (50MHz vs 30Mz).

I don't know why the previous PLL4 frequency was chosen as a compromise
on reference clock-tree  (PLL4 is used by mostly all the peripheral,
with display and audio requirements).

Can you cross check the proposed clock tree and ack this patch
if these ST requirements are not applicable on AV96 board.

Anyway the code is correct.

Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>

Thanks

Patrick

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Marek Vasut]

On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> Hi Gerald and Manivannan,

Hi,

>> From: Marek Vasut <marex@denx.de>
>> Sent: mardi 31 mars 2020 19:52
>>
>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which can not
>> easily divide the clock down to e.g. 50 MHz for high speed SD and eMMC
>> devices, so those devices end up running at 30 MHz as that is 120 MHz / 4.
>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100 MHz
>> instead, which is easy to divide to 50MHz for optimal operation of both SD and
>> eMMC, SPDIF clock are not that much slower and FDCAN is also unaffected.
>>
>> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
>> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Cc: Patrick Delaunay <patrick.delaunay@st.com>
>> Cc: Patrice Chotard <patrice.chotard@st.com>
>> ---
>> V2: Move this patch before the split of AV96 into SoM and carrier
>> V3: No change
>> ---
> 
> This patch update the PLL4 frequency used on AV96 board,
> with different of reference clock tree used on ST board,
> this new setting allow to optimize the SDMMC frequency (50MHz vs 30Mz).
> 
> I don't know why the previous PLL4 frequency was chosen as a compromise
> on reference clock-tree  (PLL4 is used by mostly all the peripheral,
> with display and audio requirements).
> 
> Can you cross check the proposed clock tree and ack this patch
> if these ST requirements are not applicable on AV96 board.
> 
> Anyway the code is correct.

Likely because these PLL settings are being copied from reference
platform to other platforms etc.

But I did notice one odd thing, which is when running the SD1 in SDR104,
the read data transfers can be unstable, which I suspect is because the
bus runs at actual 100 MHz instead of some 60 MHz. I need to look at
that with a scope, so that's to be checked. For now I turned the SDR104 off.

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Gerald BAEZA]

Hi Marek and Patrick

> From: Marek Vasut <marex@denx.de>
> Sent: mercredi 1 avril 2020 13:09
> 
> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> > Hi Gerald and Manivannan,
> 
> Hi,
> 
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: mardi 31 mars 2020 19:52
> >>
> >> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> >> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
> >> can not easily divide the clock down to e.g. 50 MHz for high speed SD
> >> and eMMC devices, so those devices end up running at 30 MHz as that is
> 120 MHz / 4.
> >> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
> >> MHz instead, which is easy to divide to 50MHz for optimal operation
> >> of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
> also unaffected.

As far as I see, SPDIF is not supported on Avenger board so we don't care for this one.
FDCAN can be supported via the expansion connector, so better to keep it high (and < 100 MHz).
Be careful because the LTDC pixel clock also comes from the PLL4Q and it is used for the HDMI on Avenger.
The pixel clock is very constraint and I am surprised by the initial 40 MHz configuration (that becomes 50 MHz with your patch).
I would recommend to align the Avenger configuration to ST boards one, that is the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for HDMI):
	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
	pll4: st,pll at 3 {
		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
		u-boot,dm-pre-reloc;
	};

> >> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> >> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> >> Signed-off-by: Marek Vasut <marex@denx.de>
> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> >> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> >> Cc: Patrice Chotard <patrice.chotard@st.com>
> >> ---
> >> V2: Move this patch before the split of AV96 into SoM and carrier
> >> V3: No change
> >> ---
> >
> > This patch update the PLL4 frequency used on AV96 board, with
> > different of reference clock tree used on ST board, this new setting
> > allow to optimize the SDMMC frequency (50MHz vs 30Mz).
> >
> > I don't know why the previous PLL4 frequency was chosen as a
> > compromise on reference clock-tree  (PLL4 is used by mostly all the
> > peripheral, with display and audio requirements).
> >
> > Can you cross check the proposed clock tree and ack this patch if
> > these ST requirements are not applicable on AV96 board.
> >
> > Anyway the code is correct.
> 
> Likely because these PLL settings are being copied from reference platform
> to other platforms etc.

As far as I remember, we never had this configuration for PLL4 on ST boards, so the copy certainly comes from somewhere else.

> But I did notice one odd thing, which is when running the SD1 in SDR104, the
> read data transfers can be unstable, which I suspect is because the bus runs
> at actual 100 MHz instead of some 60 MHz. I need to look at that with a
> scope, so that's to be checked. For now I turned the SDR104 off.

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Manivannan Sadhasivam]

Hi,

On Wed, Apr 01, 2020 at 04:49:45PM +0000, Gerald BAEZA wrote:
> Hi Marek and Patrick
> 
> > From: Marek Vasut <marex@denx.de>
> > Sent: mercredi 1 avril 2020 13:09
> > 
> > On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> > > Hi Gerald and Manivannan,
> > 
> > Hi,
> > 
> > >> From: Marek Vasut <marex@denx.de>
> > >> Sent: mardi 31 mars 2020 19:52
> > >>
> > >> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> > >> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
> > >> can not easily divide the clock down to e.g. 50 MHz for high speed SD
> > >> and eMMC devices, so those devices end up running at 30 MHz as that is
> > 120 MHz / 4.
> > >> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
> > >> MHz instead, which is easy to divide to 50MHz for optimal operation
> > >> of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
> > also unaffected.
> 
> As far as I see, SPDIF is not supported on Avenger board so we don't care for this one.
> FDCAN can be supported via the expansion connector, so better to keep it high (and < 100 MHz).
> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is used for the HDMI on Avenger.
> The pixel clock is very constraint and I am surprised by the initial 40 MHz configuration (that becomes 50 MHz with your patch).
> I would recommend to align the Avenger configuration to ST boards one, that is the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for HDMI):
> 	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> 	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> 	pll4: st,pll at 3 {
> 		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> 		u-boot,dm-pre-reloc;
> 	};
> 

This looks good to me.

> > >> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
> > >> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
> > >> Signed-off-by: Marek Vasut <marex@denx.de>
> > >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> > >> Cc: Patrice Chotard <patrice.chotard@st.com>
> > >> ---
> > >> V2: Move this patch before the split of AV96 into SoM and carrier
> > >> V3: No change
> > >> ---
> > >
> > > This patch update the PLL4 frequency used on AV96 board, with
> > > different of reference clock tree used on ST board, this new setting
> > > allow to optimize the SDMMC frequency (50MHz vs 30Mz).
> > >
> > > I don't know why the previous PLL4 frequency was chosen as a
> > > compromise on reference clock-tree  (PLL4 is used by mostly all the
> > > peripheral, with display and audio requirements).
> > >
> > > Can you cross check the proposed clock tree and ack this patch if
> > > these ST requirements are not applicable on AV96 board.
> > >
> > > Anyway the code is correct.
> > 
> > Likely because these PLL settings are being copied from reference platform
> > to other platforms etc.
> 
> As far as I remember, we never had this configuration for PLL4 on ST boards, so the copy certainly comes from somewhere else.
> 

I took the PLL settings from Downstream code done by Arrow at that time. Since
I never had access to PMIC info, I just used them blindly since that worked for
initial upstream bringup on old board. We had several discussions about PMIC
at that time but never touched PLL4.

So feel free to modify it as Gerald suggested.

Thanks,
Mani

> > But I did notice one odd thing, which is when running the SD1 in SDR104, the
> > read data transfers can be unstable, which I suspect is because the bus runs
> > at actual 100 MHz instead of some 60 MHz. I need to look at that with a
> > scope, so that's to be checked. For now I turned the SDR104 off.
> 

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Marek Vasut]

On 4/1/20 6:49 PM, Gerald BAEZA wrote:
> Hi Marek and Patrick

Hi,

>> From: Marek Vasut <marex@denx.de>
>> Sent: mercredi 1 avril 2020 13:09
>>
>> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
>>> Hi Gerald and Manivannan,
>>
>> Hi,
>>
>>>> From: Marek Vasut <marex@denx.de>
>>>> Sent: mardi 31 mars 2020 19:52
>>>>
>>>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
>>>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
>>>> can not easily divide the clock down to e.g. 50 MHz for high speed SD
>>>> and eMMC devices, so those devices end up running at 30 MHz as that is
>> 120 MHz / 4.
>>>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
>>>> MHz instead, which is easy to divide to 50MHz for optimal operation
>>>> of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
>> also unaffected.
> 
> As far as I see, SPDIF is not supported on Avenger board so we don't care for this one.
> FDCAN can be supported via the expansion connector, so better to keep it high (and < 100 MHz).

Why < 100 MHz and not <= 100 MHz ?

> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is used for the HDMI on Avenger.
> The pixel clock is very constraint and I am surprised by the initial 40 MHz configuration (that becomes 50 MHz with your patch).

Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
reconfigure them anyway, so the 50 MHz is not the final value.

> I would recommend to align the Avenger configuration to ST boards one, that is the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for HDMI):

Why is this better than 100/50/100 ?

> 	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> 	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> 	pll4: st,pll at 3 {
> 		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> 		u-boot,dm-pre-reloc;
> 	};
[...]

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Gerald BAEZA]

Hi Marek

> From: Marek Vasut <marex@denx.de>
> Sent: mercredi 1 avril 2020 20:49
> 
> On 4/1/20 6:49 PM, Gerald BAEZA wrote:
> > Hi Marek and Patrick
> 
> Hi,
> 
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: mercredi 1 avril 2020 13:09
> >>
> >> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> >>> Hi Gerald and Manivannan,
> >>
> >> Hi,
> >>
> >>>> From: Marek Vasut <marex@denx.de>
> >>>> Sent: mardi 31 mars 2020 19:52
> >>>>
> >>>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> >>>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
> >>>> can not easily divide the clock down to e.g. 50 MHz for high speed
> >>>> SD and eMMC devices, so those devices end up running at 30 MHz as
> >>>> that is
> >> 120 MHz / 4.
> >>>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
> >>>> MHz instead, which is easy to divide to 50MHz for optimal operation
> >>>> of both SD and eMMC, SPDIF clock are not that much slower and
> FDCAN
> >>>> is
> >> also unaffected.
> >
> > As far as I see, SPDIF is not supported on Avenger board so we don't care
> for this one.
> > FDCAN can be supported via the expansion connector, so better to keep it
> high (and < 100 MHz).
> 
> Why < 100 MHz and not <= 100 MHz ?

You're right, it is <= 100 MHz and it is important to be precise since you were exactly on 100 MHz :)

> > Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
> used for the HDMI on Avenger.
> > The pixel clock is very constraint and I am surprised by the initial 40 MHz
> configuration (that becomes 50 MHz with your patch).
> 
> Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
> reconfigure them anyway, so the 50 MHz is not the final value.

The kernel set_rate() changes the PLL output divisor, so it will indeed be able to switch back to (600/15=) 40 MHz from an initial (600/12=) 50 MHz.

> > I would recommend to align the Avenger configuration to ST boards one,
> that is the best compromise found so far (99 MHz for SDMMC and 74.250
> MHz for HDMI):
> 
> Why is this better than 100/50/100 ?
> 
> > 	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> > 	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> > 	pll4: st,pll at 3 {
> > 		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> > 		u-boot,dm-pre-reloc;
> > 	};
> [...]

The simplest explanation I found is here:
https://timetoexplore.net/blog/video-timings-vga-720p-1080p
(you can also look for "74.25" in the HDMI specification but there is more text to read)

So 74.250 MHz is the needed pixel clock for 720p resolution in HDMI, that is quite common, so this frequency is wished for interoperability with a maximum of TVs.
This frequency cannot be reached from the initial or your proposed PLL4 configuration, that is why I proposed to change this and align on ST board clock tree.

For the other displays we are supporting on ST boards, the kernel is tuning (down) this 74.250 MHz frequency via the set_rate (that changes the PLL output divisor).

Best regards

G?rald

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Marek Vasut]

On 4/2/20 9:44 AM, Gerald BAEZA wrote:
> Hi Marek
> 
>> From: Marek Vasut <marex@denx.de>
>> Sent: mercredi 1 avril 2020 20:49
>>
>> On 4/1/20 6:49 PM, Gerald BAEZA wrote:
>>> Hi Marek and Patrick
>>
>> Hi,
>>
>>>> From: Marek Vasut <marex@denx.de>
>>>> Sent: mercredi 1 avril 2020 13:09
>>>>
>>>> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
>>>>> Hi Gerald and Manivannan,
>>>>
>>>> Hi,
>>>>
>>>>>> From: Marek Vasut <marex@denx.de>
>>>>>> Sent: mardi 31 mars 2020 19:52
>>>>>>
>>>>>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
>>>>>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
>>>>>> can not easily divide the clock down to e.g. 50 MHz for high speed
>>>>>> SD and eMMC devices, so those devices end up running at 30 MHz as
>>>>>> that is
>>>> 120 MHz / 4.
>>>>>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
>>>>>> MHz instead, which is easy to divide to 50MHz for optimal operation
>>>>>> of both SD and eMMC, SPDIF clock are not that much slower and
>> FDCAN
>>>>>> is
>>>> also unaffected.
>>>
>>> As far as I see, SPDIF is not supported on Avenger board so we don't care
>> for this one.
>>> FDCAN can be supported via the expansion connector, so better to keep it
>> high (and < 100 MHz).
>>
>> Why < 100 MHz and not <= 100 MHz ?
> 
> You're right, it is <= 100 MHz and it is important to be precise since you were exactly on 100 MHz :)
> 
>>> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
>> used for the HDMI on Avenger.
>>> The pixel clock is very constraint and I am surprised by the initial 40 MHz
>> configuration (that becomes 50 MHz with your patch).
>>
>> Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
>> reconfigure them anyway, so the 50 MHz is not the final value.
> 
> The kernel set_rate() changes the PLL output divisor, so it will indeed be able to switch back to (600/15=) 40 MHz from an initial (600/12=) 50 MHz.
> 
>>> I would recommend to align the Avenger configuration to ST boards one,
>> that is the best compromise found so far (99 MHz for SDMMC and 74.250
>> MHz for HDMI):
>>
>> Why is this better than 100/50/100 ?
>>
>>> 	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
>>> 	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
>>> 	pll4: st,pll at 3 {
>>> 		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
>>> 		u-boot,dm-pre-reloc;
>>> 	};
>> [...]
> 
> The simplest explanation I found is here:
> https://timetoexplore.net/blog/video-timings-vga-720p-1080p
> (you can also look for "74.25" in the HDMI specification but there is more text to read)
> 
> So 74.250 MHz is the needed pixel clock for 720p resolution in HDMI, that is quite common, so this frequency is wished for interoperability with a maximum of TVs.
> This frequency cannot be reached from the initial or your proposed PLL4 configuration, that is why I proposed to change this and align on ST board clock tree.
> 
> For the other displays we are supporting on ST boards, the kernel is tuning (down) this 74.250 MHz frequency via the set_rate (that changes the PLL output divisor).

The article you found is focused on FPGA, where the FPGA is connected
directly to the HDMI TMDS signals without transceiver, so the FPGA has
to generate very precise clock. I don't think this is our case here.

The ADV7513 datasheet says nothing about such specific clock rate, it
only mentions maximum clock per resolution to be 82.5 MHz and that it
can do pixel repeat to meet the timing requirements.

(Note to self, PLL4R should run at 99 MHz too, to run FDCAN fast enough.)

[PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96

[Patrick DELAUNAY]

Hi,

> From: Marek Vasut <marex@denx.de>
> Sent: jeudi 2 avril 2020 15:05
> 
> On 4/2/20 9:44 AM, Gerald BAEZA wrote:
> > Hi Marek
> >
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: mercredi 1 avril 2020 20:49
> >>
> >> On 4/1/20 6:49 PM, Gerald BAEZA wrote:
> >>> Hi Marek and Patrick
> >>
> >> Hi,
> >>
> >>>> From: Marek Vasut <marex@denx.de>
> >>>> Sent: mercredi 1 avril 2020 13:09
> >>>>
> >>>> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> >>>>> Hi Gerald and Manivannan,
> >>>>
> >>>> Hi,
> >>>>
> >>>>>> From: Marek Vasut <marex@denx.de>
> >>>>>> Sent: mardi 31 mars 2020 19:52
> >>>>>>
> >>>>>> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz
> and
> >>>>>> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces,
> >>>>>> which can not easily divide the clock down to e.g. 50 MHz for
> >>>>>> high speed SD and eMMC devices, so those devices end up running
> >>>>>> at 30 MHz as that is
> >>>> 120 MHz / 4.
> >>>>>> Adjust the PLL4 settings such that both PLL4P and PLL4R run at
> >>>>>> 100 MHz instead, which is easy to divide to 50MHz for optimal
> >>>>>> operation of both SD and eMMC, SPDIF clock are not that much
> >>>>>> slower and
> >> FDCAN
> >>>>>> is
> >>>> also unaffected.
> >>>
> >>> As far as I see, SPDIF is not supported on Avenger board so we don't
> >>> care
> >> for this one.
> >>> FDCAN can be supported via the expansion connector, so better to
> >>> keep it
> >> high (and < 100 MHz).
> >>
> >> Why < 100 MHz and not <= 100 MHz ?
> >
> > You're right, it is <= 100 MHz and it is important to be precise since
> > you were exactly on 100 MHz :)
> >
> >>> Be careful because the LTDC pixel clock also comes from the PLL4Q
> >>> and it is
> >> used for the HDMI on Avenger.
> >>> The pixel clock is very constraint and I am surprised by the initial
> >>> 40 MHz
> >> configuration (that becomes 50 MHz with your patch).
> >>
> >> Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel
> >> will reconfigure them anyway, so the 50 MHz is not the final value.
> >
> > The kernel set_rate() changes the PLL output divisor, so it will indeed be able to
> switch back to (600/15=) 40 MHz from an initial (600/12=) 50 MHz.
> >
> >>> I would recommend to align the Avenger configuration to ST boards
> >>> one,
> >> that is the best compromise found so far (99 MHz for SDMMC and 74.250
> >> MHz for HDMI):
> >>
> >> Why is this better than 100/50/100 ?
> >>
> >>> 	https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> >>> 	/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> >>> 	pll4: st,pll at 3 {
> >>> 		cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> >>> 		u-boot,dm-pre-reloc;
> >>> 	};
> >> [...]
> >
> > The simplest explanation I found is here:
> > https://timetoexplore.net/blog/video-timings-vga-720p-1080p
> > (you can also look for "74.25" in the HDMI specification but there is
> > more text to read)
> >
> > So 74.250 MHz is the needed pixel clock for 720p resolution in HDMI, that is
> quite common, so this frequency is wished for interoperability with a maximum of
> TVs.
> > This frequency cannot be reached from the initial or your proposed PLL4
> configuration, that is why I proposed to change this and align on ST board clock
> tree.
> >
> > For the other displays we are supporting on ST boards, the kernel is tuning
> (down) this 74.250 MHz frequency via the set_rate (that changes the PLL output
> divisor).
> 
> The article you found is focused on FPGA, where the FPGA is connected directly
> to the HDMI TMDS signals without transceiver, so the FPGA has to generate very
> precise clock. I don't think this is our case here.
> 
> The ADV7513 datasheet says nothing about such specific clock rate, it only
> mentions maximum clock per resolution to be 82.5 MHz and that it can do pixel
> repeat to meet the timing requirements.
> 
> (Note to self, PLL4R should run at 99 MHz too, to run FDCAN fast enough.)

Without more requirement on the clock tree, the new PLL4 is acceptable.

Applied to u-boot-stm/master, thanks!

Regards

Patrick

[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

[Marek Vasut]

The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top
of an AV96 reference board. Split the DTs to reflect that and make
sure to DHCOR SoM can be reused on other boards easily.

It is also highly recommended to configure the board for the DHCOM
make stm32mp15_dhcom_basic_defconfig
make DEVICE_TREE=stm32mp15xx-dhcor-avenger96
as that permits reusing the board code for the DH components, like
accessing and reading out the ethernet MAC from EEPROM.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
---
V2: No change
V3: No change
---
 arch/arm/dts/Makefile                         |   3 +-
 arch/arm/dts/stm32mp157a-avenger96.dts        | 421 +-----------------
 .../stm32mp15xx-dhcor-avenger96-u-boot.dtsi   |  80 ++++
 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts  | 211 +++++++++
 ...oot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} |  79 +---
 arch/arm/dts/stm32mp15xx-dhcor.dtsi           | 231 ++++++++++
 doc/board/st/stm32mp1.rst                     |   8 +-
 7 files changed, 535 insertions(+), 498 deletions(-)
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
 rename arch/arm/dts/{stm32mp157a-avenger96-u-boot.dtsi => stm32mp15xx-dhcor-u-boot.dtsi} (75%)
 create mode 100644 arch/arm/dts/stm32mp15xx-dhcor.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9c593b2c98..2564f790de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -884,7 +884,8 @@ dtb-$(CONFIG_STM32MP15x) += \
 	stm32mp157c-dk2.dtb \
 	stm32mp157c-ed1.dtb \
 	stm32mp157c-ev1.dtb \
-	stm32mp15xx-dhcom-pdk2.dtb
+	stm32mp15xx-dhcom-pdk2.dtb \
+	stm32mp15xx-dhcor-avenger96.dtb
 
 dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb k3-am654-r5-base-board.dtb
 dtb-$(CONFIG_SOC_K3_J721E) += k3-j721e-common-proc-board.dtb \
diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts
index 97ff40144e..9c165104fb 100644
--- a/arch/arm/dts/stm32mp157a-avenger96.dts
+++ b/arch/arm/dts/stm32mp157a-avenger96.dts
@@ -4,422 +4,5 @@
  * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
  */
 
-/dts-v1/;
-
-#include "stm32mp157c.dtsi"
-#include "stm32mp157xac-pinctrl.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/mfd/st,stpmic1.h>
-
-/ {
-	model = "Arrow Electronics STM32MP157A Avenger96 board";
-	compatible = "arrow,stm32mp157a-avenger96", "st,stm32mp157";
-
-	aliases {
-		ethernet0 = &ethernet0;
-		mmc0 = &sdmmc1;
-		serial0 = &uart4;
-		serial1 = &uart7;
-		spi0 = &qspi;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	memory at c0000000 {
-		device_type = "memory";
-		reg = <0xc0000000 0x40000000>;
-	};
-
-	led {
-		compatible = "gpio-leds";
-		led1 {
-			label = "green:user1";
-			gpios = <&gpioz 7 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "heartbeat";
-			default-state = "off";
-		};
-
-		led2 {
-			label = "green:user2";
-			gpios = <&gpiof 3 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "mmc0";
-			default-state = "off";
-		};
-
-		led3 {
-			label = "green:user3";
-			gpios = <&gpiog 0 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "mmc1";
-			default-state = "off";
-		};
-
-		led4 {
-			label = "green:user3";
-			gpios = <&gpiog 1 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "none";
-			default-state = "off";
-			panic-indicator;
-		};
-
-		led5 {
-			label = "yellow:wifi";
-			gpios = <&gpioz 3 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "phy0tx";
-			default-state = "off";
-		};
-
-		led6 {
-			label = "blue:bt";
-			gpios = <&gpioz 6 GPIO_ACTIVE_HIGH>;
-			linux,default-trigger = "bluetooth-power";
-			default-state = "off";
-		};
-	};
-
-	sd_switch: regulator-sd_switch {
-		compatible = "regulator-gpio";
-		regulator-name = "sd_switch";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <2900000>;
-		regulator-type = "voltage";
-		regulator-always-on;
-
-		gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
-		gpios-states = <0>;
-		states = <1800000 0x1>,
-			 <2900000 0x0>;
-	};
-
-	/* Enpirion EP3A8LQI U2 on the DHCOR */
-	vdd_io: regulator-buck-io {
-		compatible = "regulator-fixed";
-		regulator-name = "buck-io";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		regulator-always-on;
-		regulator-boot-on;
-		vin-supply = <&vdd>;
-	};
-};
-
-&ethernet0 {
-	status = "okay";
-	pinctrl-0 = <&ethernet0_rgmii_pins_b>;
-	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_b>;
-	pinctrl-names = "default", "sleep";
-	phy-mode = "rgmii";
-	max-speed = <1000>;
-	phy-handle = <&phy0>;
-	phy-reset-gpios = <&gpioz 2 GPIO_ACTIVE_LOW>;
-
-	mdio0 {
-		#address-cells = <1>;
-		#size-cells = <0>;
-		compatible = "snps,dwmac-mdio";
-		phy0: ethernet-phy at 7 {
-			reg = <7>;
-		};
-	};
-};
-
-&i2c1 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&i2c1_pins_b>;
-	i2c-scl-rising-time-ns = <185>;
-	i2c-scl-falling-time-ns = <20>;
-	status = "okay";
-	/delete-property/dmas;
-	/delete-property/dma-names;
-};
-
-&i2c2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&i2c2_pins_b1 &i2c2_pins_b2>;
-	i2c-scl-rising-time-ns = <185>;
-	i2c-scl-falling-time-ns = <20>;
-	status = "okay";
-	/delete-property/dmas;
-	/delete-property/dma-names;
-};
-
-&i2c4 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&i2c4_pins_a>;
-	i2c-scl-rising-time-ns = <185>;
-	i2c-scl-falling-time-ns = <20>;
-	status = "okay";
-	/delete-property/dmas;
-	/delete-property/dma-names;
-
-	pmic: stpmic at 33 {
-		compatible = "st,stpmic1";
-		reg = <0x33>;
-		interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
-		interrupt-controller;
-		#interrupt-cells = <2>;
-		status = "okay";
-
-		st,main-control-register = <0x04>;
-		st,vin-control-register = <0xc0>;
-		st,usb-control-register = <0x30>;
-
-		regulators {
-			compatible = "st,stpmic1-regulators";
-
-			ldo1-supply = <&v3v3>;
-			ldo2-supply = <&v3v3>;
-			ldo3-supply = <&vdd_ddr>;
-			ldo5-supply = <&v3v3>;
-			ldo6-supply = <&v3v3>;
-			pwr_sw1-supply = <&bst_out>;
-			pwr_sw2-supply = <&bst_out>;
-
-			vddcore: buck1 {
-				regulator-name = "vddcore";
-				regulator-min-microvolt = <800000>;
-				regulator-max-microvolt = <1350000>;
-				regulator-always-on;
-				regulator-initial-mode = <0>;
-				regulator-over-current-protection;
-			};
-
-			vdd_ddr: buck2 {
-				regulator-name = "vdd_ddr";
-				regulator-min-microvolt = <1350000>;
-				regulator-max-microvolt = <1350000>;
-				regulator-always-on;
-				regulator-initial-mode = <0>;
-				regulator-over-current-protection;
-			};
-
-			vdd: buck3 {
-				regulator-name = "vdd";
-				regulator-min-microvolt = <2900000>;
-				regulator-max-microvolt = <2900000>;
-				regulator-always-on;
-				st,mask_reset;
-				regulator-initial-mode = <0>;
-				regulator-over-current-protection;
-			};
-
-			v3v3: buck4 {
-				regulator-name = "v3v3";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
-				regulator-always-on;
-				regulator-over-current-protection;
-				regulator-initial-mode = <0>;
-			};
-
-			vdda: ldo1 {
-				regulator-name = "vdda";
-				regulator-min-microvolt = <2900000>;
-				regulator-max-microvolt = <2900000>;
-				interrupts = <IT_CURLIM_LDO1 0>;
-				interrupt-parent = <&pmic>;
-			};
-
-			v2v8: ldo2 {
-				regulator-name = "v2v8";
-				regulator-min-microvolt = <2800000>;
-				regulator-max-microvolt = <2800000>;
-				interrupts = <IT_CURLIM_LDO2 0>;
-				interrupt-parent = <&pmic>;
-			};
-
-			vtt_ddr: ldo3 {
-				regulator-name = "vtt_ddr";
-				regulator-min-microvolt = <500000>;
-				regulator-max-microvolt = <750000>;
-				regulator-always-on;
-				regulator-over-current-protection;
-			};
-
-			vdd_usb: ldo4 {
-				regulator-name = "vdd_usb";
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
-				interrupts = <IT_CURLIM_LDO4 0>;
-				interrupt-parent = <&pmic>;
-			};
-
-			vdd_sd: ldo5 {
-				regulator-name = "vdd_sd";
-				regulator-min-microvolt = <2900000>;
-				regulator-max-microvolt = <2900000>;
-				interrupts = <IT_CURLIM_LDO5 0>;
-				interrupt-parent = <&pmic>;
-				regulator-boot-on;
-			};
-
-			v1v8: ldo6 {
-				regulator-name = "v1v8";
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-				interrupts = <IT_CURLIM_LDO6 0>;
-				interrupt-parent = <&pmic>;
-				regulator-enable-ramp-delay = <300000>;
-			};
-
-			vref_ddr: vref_ddr {
-				regulator-name = "vref_ddr";
-				regulator-always-on;
-				regulator-over-current-protection;
-			};
-
-			bst_out: boost {
-				regulator-name = "bst_out";
-				interrupts = <IT_OCP_BOOST 0>;
-				interrupt-parent = <&pmic>;
-			};
-
-			vbus_otg: pwr_sw1 {
-				regulator-name = "vbus_otg";
-				interrupts = <IT_OCP_OTG 0>;
-				interrupt-parent = <&pmic>;
-				regulator-active-discharge = <1>;
-			};
-
-			vbus_sw: pwr_sw2 {
-				regulator-name = "vbus_sw";
-				interrupts = <IT_OCP_SWOUT 0>;
-				interrupt-parent = <&pmic>;
-				regulator-active-discharge = <1>;
-			};
-		};
-
-		onkey {
-			compatible = "st,stpmic1-onkey";
-			interrupts = <IT_PONKEY_F 0>, <IT_PONKEY_R 1>;
-			interrupt-names = "onkey-falling", "onkey-rising";
-			status = "okay";
-		};
-
-		watchdog {
-			compatible = "st,stpmic1-wdt";
-			status = "disabled";
-		};
-	};
-
-	eeprom at 53 {
-		compatible = "atmel,24c02";
-		reg = <0x53>;
-		pagesize = <16>;
-	};
-};
-
-&iwdg2 {
-	timeout-sec = <32>;
-	status = "okay";
-};
-
-&pwr_regulators {
-	vdd-supply = <&vdd_io>;
-	vdd_3v3_usbfs-supply = <&vdd_usb>;
-};
-
-&qspi {
-	pinctrl-names = "default", "sleep";
-	pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
-	pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
-	reg = <0x58003000 0x1000>, <0x70000000 0x200000>;
-	#address-cells = <1>;
-	#size-cells = <0>;
-	status = "okay";
-
-	flash0: spi-flash at 0 {
-		compatible = "jedec,spi-nor";
-		reg = <0>;
-		spi-rx-bus-width = <4>;
-		spi-max-frequency = <108000000>;
-		#address-cells = <1>;
-		#size-cells = <1>;
-	};
-};
-
-&rng1 {
-	status = "okay";
-};
-
-&rtc {
-	status = "okay";
-};
-
-&sdmmc1 {
-	pinctrl-names = "default", "opendrain", "sleep";
-	pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_b>;
-	pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_b>;
-	pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_b>;
-	cd-gpios = <&gpioi 8 GPIO_ACTIVE_LOW>;
-	disable-wp;
-	st,sig-dir;
-	st,neg-edge;
-	st,use-ckin;
-	sd-uhs-sdr104;
-	bus-width = <4>;
-	vmmc-supply = <&vdd_sd>;
-	vqmmc-supply = <&sd_switch>;
-	status = "okay";
-};
-
-&sdmmc2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc2_b4_pins_a &sdmmc2_d47_pins_b>;
-	non-removable;
-	no-sd;
-	no-sdio;
-	st,neg-edge;
-	bus-width = <8>;
-	vmmc-supply = <&v3v3>;
-	mmc-ddr-3_3v;
-	status = "okay";
-};
-
-&spi2 {
-	pinctrl-names = "default";
-	pinctrl-0 = <&spi2_pins_a>;
-	status = "okay";
-};
-
-&uart4 {
-	/* On Low speed expansion header */
-	label = "LS-UART1";
-	pinctrl-names = "default";
-	pinctrl-0 = <&uart4_pins_b>;
-	status = "okay";
-};
-
-&uart7 {
-	/* On Low speed expansion header */
-	label = "LS-UART0";
-	pinctrl-names = "default";
-	pinctrl-0 = <&uart7_pins_a>;
-	status = "okay";
-};
-
-&usbh_ehci {
-	phys = <&usbphyc_port0>;
-	phy-names = "usb";
-	status = "okay";
-};
-
-&usbotg_hs {
-	dr_mode = "peripheral";
-	phys = <&usbphyc_port1 0>;
-	phy-names = "usb2-phy";
-	status = "okay";
-};
-
-&usbphyc {
-	status = "okay";
-};
-
-&usbphyc_port0 {
-	phy-supply = <&vdd_usb>;
-};
-
-&usbphyc_port1 {
-	phy-supply = <&vdd_usb>;
-};
+/* This is kept for backward compatibility and will be removed */
+#include "stm32mp15xx-dhcor-avenger96.dts"
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
new file mode 100644
index 0000000000..4207a96618
--- /dev/null
+++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause
+/*
+ * Copyright (C) 2020 Marek Vasut <marex@denx.de>
+ */
+
+#include "stm32mp15xx-dhcor-u-boot.dtsi"
+
+/ {
+	aliases {
+		mmc0 = &sdmmc1;
+		mmc1 = &sdmmc2;
+		usb0 = &usbotg_hs;
+	};
+
+	config {
+		u-boot,boot-led = "led1";
+		u-boot,error-led = "led4";
+	};
+};
+
+&sdmmc1 {
+	u-boot,dm-spl;
+};
+
+&sdmmc1_b4_pins_a {
+	u-boot,dm-spl;
+	pins {
+		u-boot,dm-spl;
+	};
+};
+
+&sdmmc1_dir_pins_b {
+	u-boot,dm-spl;
+	pins1 {
+		u-boot,dm-spl;
+	};
+	pins2 {
+		u-boot,dm-spl;
+	};
+};
+
+&sdmmc2 {
+	u-boot,dm-spl;
+};
+
+&sdmmc2_b4_pins_a {
+	u-boot,dm-spl;
+	pins1 {
+		u-boot,dm-spl;
+	};
+	pins2 {
+		u-boot,dm-spl;
+	};
+};
+
+&sdmmc2_d47_pins_b {
+	u-boot,dm-spl;
+	pins {
+		u-boot,dm-spl;
+	};
+};
+
+&uart4 {
+	u-boot,dm-pre-reloc;
+};
+
+&uart4_pins_b {
+	u-boot,dm-pre-reloc;
+	pins1 {
+		u-boot,dm-pre-reloc;
+	};
+	pins2 {
+		u-boot,dm-pre-reloc;
+	};
+};
+
+&usbotg_hs {
+	u-boot,force-b-session-valid;
+	hnp-srp-disable;
+};
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
new file mode 100644
index 0000000000..9d859e1d09
--- /dev/null
+++ b/arch/arm/dts/stm32mp15xx-dhcor-avenger96.dts
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
+ * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ * Copyright (C) 2020 Marek Vasut <marex@denx.de>
+ */
+
+/dts-v1/;
+
+#include "stm32mp15xx-dhcor.dtsi"
+#include "stm32mp15xx-dhcor-avenger96-u-boot.dtsi"
+
+/ {
+	model = "Arrow Electronics STM32MP15xx Avenger96 board";
+	compatible = "arrow,stm32mp15xx-avenger96", "st,stm32mp15x";
+
+	aliases {
+		eeprom0 = &eeprom0;
+		ethernet0 = &ethernet0;
+		mmc0 = &sdmmc1;
+		serial0 = &uart4;
+		serial1 = &uart7;
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	led {
+		compatible = "gpio-leds";
+		led1 {
+			label = "green:user1";
+			gpios = <&gpioz 7 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+			default-state = "off";
+		};
+
+		led2 {
+			label = "green:user2";
+			gpios = <&gpiof 3 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "mmc0";
+			default-state = "off";
+		};
+
+		led3 {
+			label = "green:user3";
+			gpios = <&gpiog 0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "mmc1";
+			default-state = "off";
+		};
+
+		led4 {
+			label = "green:user3";
+			gpios = <&gpiog 1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "none";
+			default-state = "off";
+			panic-indicator;
+		};
+
+		led5 {
+			label = "yellow:wifi";
+			gpios = <&gpioz 3 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "phy0tx";
+			default-state = "off";
+		};
+
+		led6 {
+			label = "blue:bt";
+			gpios = <&gpioz 6 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "bluetooth-power";
+			default-state = "off";
+		};
+	};
+
+	sd_switch: regulator-sd_switch {
+		compatible = "regulator-gpio";
+		regulator-name = "sd_switch";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <2900000>;
+		regulator-type = "voltage";
+		regulator-always-on;
+
+		gpios = <&gpioi 5 GPIO_ACTIVE_HIGH>;
+		gpios-states = <0>;
+		states = <1800000 0x1>,
+			 <2900000 0x0>;
+	};
+};
+
+&ethernet0 {
+	status = "okay";
+	pinctrl-0 = <&ethernet0_rgmii_pins_b>;
+	pinctrl-1 = <&ethernet0_rgmii_pins_sleep_b>;
+	pinctrl-names = "default", "sleep";
+	phy-mode = "rgmii";
+	max-speed = <1000>;
+	phy-handle = <&phy0>;
+	phy-reset-gpios = <&gpioz 2 GPIO_ACTIVE_LOW>;
+
+	mdio0 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		compatible = "snps,dwmac-mdio";
+		phy0: ethernet-phy at 7 {
+			reg = <7>;
+		};
+	};
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins_b>;
+	i2c-scl-rising-time-ns = <185>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+	/delete-property/dmas;
+	/delete-property/dma-names;
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins_b1 &i2c2_pins_b2>;
+	i2c-scl-rising-time-ns = <185>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+	/delete-property/dmas;
+	/delete-property/dma-names;
+};
+
+&i2c4 {
+	eeprom0: eeprom at 53 {
+		compatible = "atmel,24c02";
+		reg = <0x53>;
+		pagesize = <16>;
+	};
+};
+
+&sdmmc1 {
+	pinctrl-names = "default", "opendrain", "sleep";
+	pinctrl-0 = <&sdmmc1_b4_pins_a &sdmmc1_dir_pins_b>;
+	pinctrl-1 = <&sdmmc1_b4_od_pins_a &sdmmc1_dir_pins_b>;
+	pinctrl-2 = <&sdmmc1_b4_sleep_pins_a &sdmmc1_dir_sleep_pins_b>;
+	disable-wp;
+	st,sig-dir;
+	st,neg-edge;
+	st,use-ckin;
+	bus-width = <4>;
+	vmmc-supply = <&vdd_sd>;
+	vqmmc-supply = <&sd_switch>;
+	status = "okay";
+};
+
+&sdmmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&sdmmc2_b4_pins_a &sdmmc2_d47_pins_b>;
+	non-removable;
+	no-sd;
+	no-sdio;
+	st,neg-edge;
+	bus-width = <8>;
+	vmmc-supply = <&v3v3>;
+	mmc-ddr-3_3v;
+	status = "okay";
+};
+
+&spi2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&spi2_pins_a>;
+	status = "okay";
+};
+
+&uart4 {
+	/* On Low speed expansion header */
+	label = "LS-UART1";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart4_pins_b>;
+	status = "okay";
+};
+
+&uart7 {
+	/* On Low speed expansion header */
+	label = "LS-UART0";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart7_pins_a>;
+	status = "okay";
+};
+
+&usbh_ehci {
+	phys = <&usbphyc_port0>;
+	phy-names = "usb";
+	status = "okay";
+};
+
+&usbotg_hs {
+	dr_mode = "peripheral";
+	phys = <&usbphyc_port1 0>;
+	phy-names = "usb2-phy";
+	status = "okay";
+};
+
+&usbphyc {
+	status = "okay";
+};
+
+&usbphyc_port0 {
+	phy-supply = <&vdd_usb>;
+};
+
+&usbphyc_port1 {
+	phy-supply = <&vdd_usb>;
+};
diff --git a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
similarity index 75%
rename from arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
rename to arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index 320132a01e..02dad81b0b 100644
--- a/arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -4,25 +4,13 @@
  *
  * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
  * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ * Copyright (C) 2020 Marek Vasut <marex@denx.de>
  */
 
 #include <dt-bindings/clock/stm32mp1-clksrc.h>
 #include "stm32mp157-u-boot.dtsi"
 #include "stm32mp15-ddr3-2x4Gb-1066-binG.dtsi"
 
-/ {
-	aliases {
-		mmc0 = &sdmmc1;
-		mmc1 = &sdmmc2;
-		usb0 = &usbotg_hs;
-	};
-
-	config {
-		u-boot,boot-led = "led1";
-		u-boot,error-led = "led4";
-	};
-};
-
 &i2c4 {
 	u-boot,dm-pre-reloc;
 };
@@ -38,6 +26,10 @@
 	u-boot,dm-pre-reloc;
 };
 
+&qspi {
+	u-boot,dm-spl;
+};
+
 &rcc {
 	st,clksrc = <
 		CLK_MPU_PLL1P
@@ -139,67 +131,6 @@
 	};
 };
 
-&sdmmc1 {
-	u-boot,dm-spl;
-};
-
-&sdmmc1_b4_pins_a {
-	u-boot,dm-spl;
-	pins {
-		u-boot,dm-spl;
-	};
-};
-
-&sdmmc1_dir_pins_b {
-	u-boot,dm-spl;
-	pins1 {
-		u-boot,dm-spl;
-	};
-	pins2 {
-		u-boot,dm-spl;
-	};
-};
-
-&sdmmc2 {
-	u-boot,dm-spl;
-};
-
-&sdmmc2_b4_pins_a {
-	u-boot,dm-spl;
-	pins1 {
-		u-boot,dm-spl;
-	};
-	pins2 {
-		u-boot,dm-spl;
-	};
-};
-
-&sdmmc2_d47_pins_b {
-	u-boot,dm-spl;
-	pins {
-		u-boot,dm-spl;
-	};
-};
-
-&uart4 {
-	u-boot,dm-pre-reloc;
-};
-
-&uart4_pins_b {
-	u-boot,dm-pre-reloc;
-	pins1 {
-		u-boot,dm-pre-reloc;
-	};
-	pins2 {
-		u-boot,dm-pre-reloc;
-	};
-};
-
-&usbotg_hs {
-	u-boot,force-b-session-valid;
-	hnp-srp-disable;
-};
-
 &v3v3 {
 	regulator-always-on;
 };
diff --git a/arch/arm/dts/stm32mp15xx-dhcor.dtsi b/arch/arm/dts/stm32mp15xx-dhcor.dtsi
new file mode 100644
index 0000000000..9d4e92ebb1
--- /dev/null
+++ b/arch/arm/dts/stm32mp15xx-dhcor.dtsi
@@ -0,0 +1,231 @@
+// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
+/*
+ * Copyright (C) Linaro Ltd 2019 - All Rights Reserved
+ * Author: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
+ * Copyright (C) 2020 Marek Vasut <marex@denx.de>
+ */
+/dts-v1/;
+
+#include "stm32mp157c.dtsi"
+#include "stm32mp157xac-pinctrl.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/mfd/st,stpmic1.h>
+
+/ {
+	aliases {
+		spi0 = &qspi;
+	};
+
+	memory at c0000000 {
+		device_type = "memory";
+		reg = <0xc0000000 0x40000000>;
+	};
+
+	/* Enpirion EP3A8LQI U2 on the DHCOR */
+	vdd_io: regulator-buck-io {
+		compatible = "regulator-fixed";
+		regulator-name = "buck-io";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd>;
+	};
+};
+
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c4_pins_a>;
+	i2c-scl-rising-time-ns = <185>;
+	i2c-scl-falling-time-ns = <20>;
+	status = "okay";
+	/delete-property/dmas;
+	/delete-property/dma-names;
+
+	pmic: stpmic at 33 {
+		compatible = "st,stpmic1";
+		reg = <0x33>;
+		interrupts-extended = <&exti 55 IRQ_TYPE_EDGE_FALLING>;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		status = "okay";
+
+		st,main-control-register = <0x04>;
+		st,vin-control-register = <0xc0>;
+		st,usb-control-register = <0x30>;
+
+		regulators {
+			compatible = "st,stpmic1-regulators";
+
+			ldo1-supply = <&v3v3>;
+			ldo2-supply = <&v3v3>;
+			ldo3-supply = <&vdd_ddr>;
+			ldo5-supply = <&v3v3>;
+			ldo6-supply = <&v3v3>;
+			pwr_sw1-supply = <&bst_out>;
+			pwr_sw2-supply = <&bst_out>;
+
+			vddcore: buck1 {
+				regulator-name = "vddcore";
+				regulator-min-microvolt = <800000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-always-on;
+				regulator-initial-mode = <0>;
+				regulator-over-current-protection;
+			};
+
+			vdd_ddr: buck2 {
+				regulator-name = "vdd_ddr";
+				regulator-min-microvolt = <1350000>;
+				regulator-max-microvolt = <1350000>;
+				regulator-always-on;
+				regulator-initial-mode = <0>;
+				regulator-over-current-protection;
+			};
+
+			vdd: buck3 {
+				regulator-name = "vdd";
+				regulator-min-microvolt = <2900000>;
+				regulator-max-microvolt = <2900000>;
+				regulator-always-on;
+				st,mask_reset;
+				regulator-initial-mode = <0>;
+				regulator-over-current-protection;
+			};
+
+			v3v3: buck4 {
+				regulator-name = "v3v3";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				regulator-always-on;
+				regulator-over-current-protection;
+				regulator-initial-mode = <0>;
+			};
+
+			vdda: ldo1 {
+				regulator-name = "vdda";
+				regulator-min-microvolt = <2900000>;
+				regulator-max-microvolt = <2900000>;
+				interrupts = <IT_CURLIM_LDO1 0>;
+				interrupt-parent = <&pmic>;
+			};
+
+			v2v8: ldo2 {
+				regulator-name = "v2v8";
+				regulator-min-microvolt = <2800000>;
+				regulator-max-microvolt = <2800000>;
+				interrupts = <IT_CURLIM_LDO2 0>;
+				interrupt-parent = <&pmic>;
+			};
+
+			vtt_ddr: ldo3 {
+				regulator-name = "vtt_ddr";
+				regulator-min-microvolt = <500000>;
+				regulator-max-microvolt = <750000>;
+				regulator-always-on;
+				regulator-over-current-protection;
+			};
+
+			vdd_usb: ldo4 {
+				regulator-name = "vdd_usb";
+				regulator-min-microvolt = <3300000>;
+				regulator-max-microvolt = <3300000>;
+				interrupts = <IT_CURLIM_LDO4 0>;
+				interrupt-parent = <&pmic>;
+			};
+
+			vdd_sd: ldo5 {
+				regulator-name = "vdd_sd";
+				regulator-min-microvolt = <2900000>;
+				regulator-max-microvolt = <2900000>;
+				interrupts = <IT_CURLIM_LDO5 0>;
+				interrupt-parent = <&pmic>;
+				regulator-boot-on;
+			};
+
+			v1v8: ldo6 {
+				regulator-name = "v1v8";
+				regulator-min-microvolt = <1800000>;
+				regulator-max-microvolt = <1800000>;
+				interrupts = <IT_CURLIM_LDO6 0>;
+				interrupt-parent = <&pmic>;
+				regulator-enable-ramp-delay = <300000>;
+			};
+
+			vref_ddr: vref_ddr {
+				regulator-name = "vref_ddr";
+				regulator-always-on;
+				regulator-over-current-protection;
+			};
+
+			bst_out: boost {
+				regulator-name = "bst_out";
+				interrupts = <IT_OCP_BOOST 0>;
+				interrupt-parent = <&pmic>;
+			};
+
+			vbus_otg: pwr_sw1 {
+				regulator-name = "vbus_otg";
+				interrupts = <IT_OCP_OTG 0>;
+				interrupt-parent = <&pmic>;
+				regulator-active-discharge = <1>;
+			};
+
+			vbus_sw: pwr_sw2 {
+				regulator-name = "vbus_sw";
+				interrupts = <IT_OCP_SWOUT 0>;
+				interrupt-parent = <&pmic>;
+				regulator-active-discharge = <1>;
+			};
+		};
+
+		onkey {
+			compatible = "st,stpmic1-onkey";
+			interrupts = <IT_PONKEY_F 0>, <IT_PONKEY_R 1>;
+			interrupt-names = "onkey-falling", "onkey-rising";
+			status = "okay";
+		};
+
+		watchdog {
+			compatible = "st,stpmic1-wdt";
+			status = "disabled";
+		};
+	};
+};
+
+&iwdg2 {
+	timeout-sec = <32>;
+	status = "okay";
+};
+
+&pwr_regulators {
+	vdd-supply = <&vdd_io>;
+	vdd_3v3_usbfs-supply = <&vdd_usb>;
+};
+
+&qspi {
+	pinctrl-names = "default", "sleep";
+	pinctrl-0 = <&qspi_clk_pins_a &qspi_bk1_pins_a>;
+	pinctrl-1 = <&qspi_clk_sleep_pins_a &qspi_bk1_sleep_pins_a>;
+	reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	flash0: spi-flash at 0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-rx-bus-width = <4>;
+		spi-max-frequency = <108000000>;
+		#address-cells = <1>;
+		#size-cells = <1>;
+	};
+};
+
+&rng1 {
+	status = "okay";
+};
+
+&rtc {
+	status = "okay";
+};
diff --git a/doc/board/st/stm32mp1.rst b/doc/board/st/stm32mp1.rst
index 1640bf910e..73195134f1 100644
--- a/doc/board/st/stm32mp1.rst
+++ b/doc/board/st/stm32mp1.rst
@@ -43,11 +43,11 @@ And the necessary drivers
 
 Currently the following boards are supported:
 
- + stm32mp157a-avenger96.dts
  + stm32mp157a-dk1.dts
  + stm32mp157c-dk2.dts
  + stm32mp157c-ed1.dts
  + stm32mp157c-ev1.dts
+ + stm32mp15xx-dhcor-avenger96.dts
 
 Boot Sequences
 --------------
@@ -145,9 +145,9 @@ the supported device trees for STM32MP15x are:
 
    + stm32mp157c-dk2
 
-+ avenger96: Avenger96 board from Arrow Electronics
++ avenger96: Avenger96 board from Arrow Electronics based on DH Elec. DHCOR SoM
 
-   + stm32mp157a-avenger96
+   + stm32mp15xx-dhcor-avenger96
 
 Build Procedure
 ---------------
@@ -229,7 +229,7 @@ Build Procedure
 
      # export KBUILD_OUTPUT=stm32mp15_basic
      # make stm32mp15_basic_defconfig
-     # make DEVICE_TREE=stm32mp157a-avenger96 all
+     # make DEVICE_TREE=stm32mp15xx-dhcor-avenger96 all
 
 6. Output files
 
-- 
2.25.1

[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

[Patrick DELAUNAY]

Dear Marek,

> From: Marek Vasut <marex@denx.de>
> Sent: mardi 31 mars 2020 19:52
> 
> The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top of an
> AV96 reference board. Split the DTs to reflect that and make sure to DHCOR SoM
> can be reused on other boards easily.
> 
> It is also highly recommended to configure the board for the DHCOM make
> stm32mp15_dhcom_basic_defconfig make DEVICE_TREE=stm32mp15xx-dhcor-
> avenger96
> as that permits reusing the board code for the DH components, like accessing and
> reading out the ethernet MAC from EEPROM.
> 
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> Cc: Patrice Chotard <patrice.chotard@st.com>
> ---
> V2: No change
> V3: No change
> ---

Applied to u-boot-stm/master, with few modifications:

arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi

-
-&v3v3 {
-	regulator-always-on;
-};

Not needed as already present in arch/arm/dts/stm32mp15xx-dhcor.dtsi

I solve rebase conflict on arch/arm/dts/stm32mp15xx-dhcor.dtsi

-	reg = <0x58003000 0x1000>, <0x70000000 0x4000000>;
+	reg = <0x58003000 0x1000>, <0x70000000 0x200000>;

And issue after kernel device tree alignment :

arch/arm/dts/stm32mp15xx-dhcor-avenger96-u-boot.dtsi 
 
 &sdmmc1_b4_pins_a {
 	u-boot,dm-spl;
-	pins {
+	pins1 {
+		u-boot,dm-spl;
+	};
+	pins2 {
 		u-boot,dm-spl;
 	};
 };

Regards

Patrick

[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

[Marek Vasut]

On 4/24/20 4:31 PM, Patrick DELAUNAY wrote:
> Dear Marek,
> 
>> From: Marek Vasut <marex@denx.de>
>> Sent: mardi 31 mars 2020 19:52
>>
>> The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top of an
>> AV96 reference board. Split the DTs to reflect that and make sure to DHCOR SoM
>> can be reused on other boards easily.
>>
>> It is also highly recommended to configure the board for the DHCOM make
>> stm32mp15_dhcom_basic_defconfig make DEVICE_TREE=stm32mp15xx-dhcor-
>> avenger96
>> as that permits reusing the board code for the DH components, like accessing and
>> reading out the ethernet MAC from EEPROM.
>>
>> Signed-off-by: Marek Vasut <marex@denx.de>
>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Cc: Patrick Delaunay <patrick.delaunay@st.com>
>> Cc: Patrice Chotard <patrice.chotard@st.com>
>> ---
>> V2: No change
>> V3: No change
>> ---
> 
> Applied to u-boot-stm/master, with few modifications:
> 
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> 
> -
> -&v3v3 {
> -	regulator-always-on;
> -};

It seems this patch was applied incorrectly and the 1V8 and 3V3
differentiation between the SoMs is completely missing from mainline. I
will send a subsequent patch to correct that.

[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

[Patrick DELAUNAY]

Dear Marek,

> From: Marek Vasut <marex@denx.de>
> Sent: lundi 27 avril 2020 12:30
> 
> On 4/24/20 4:31 PM, Patrick DELAUNAY wrote:
> > Dear Marek,
> >
> >> From: Marek Vasut <marex@denx.de>
> >> Sent: mardi 31 mars 2020 19:52
> >>
> >> The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top of
> >> an
> >> AV96 reference board. Split the DTs to reflect that and make sure to
> >> DHCOR SoM can be reused on other boards easily.
> >>
> >> It is also highly recommended to configure the board for the DHCOM
> >> make stm32mp15_dhcom_basic_defconfig make
> >> DEVICE_TREE=stm32mp15xx-dhcor-
> >> avenger96
> >> as that permits reusing the board code for the DH components, like
> >> accessing and reading out the ethernet MAC from EEPROM.
> >>
> >> Signed-off-by: Marek Vasut <marex@denx.de>
> >> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> >> Cc: Patrick Delaunay <patrick.delaunay@st.com>
> >> Cc: Patrice Chotard <patrice.chotard@st.com>
> >> ---
> >> V2: No change
> >> V3: No change
> >> ---
> >
> > Applied to u-boot-stm/master, with few modifications:
> >
> > arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> >
> > -
> > -&v3v3 {
> > -	regulator-always-on;
> > -};
> 
> It seems this patch was applied incorrectly and the 1V8 and 3V3 differentiation
> between the SoMs is completely missing from mainline. I will send a subsequent
> patch to correct that.

Strange, I don't remember conflict on this patch....

And 1.8V was present for the dhcor.dtsi in initial patch,
I miss something I thing when I apply the patch:

+++ b/arch/arm/dts/stm32mp15xx-dhcor.dtsi
@@ -0,0 +1,231 @@
+
+	/* Enpirion EP3A8LQI U2 on the DHCOR */
+	vdd_io: regulator-buck-io {
+		compatible = "regulator-fixed";
+		regulator-name = "buck-io";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		regulator-boot-on;
+		vin-supply = <&vdd>;
+	};
[...]
+
+&pwr_regulators {
+	vdd-supply = <&vdd_io>;
+	vdd_3v3_usbfs-supply = <&vdd_usb>;
+};

Anyway thanks to the check and the correction.

Regards

Patrick

[PATCH V3 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board

[Marek Vasut]

On 4/27/20 4:00 PM, Patrick DELAUNAY wrote:
> Dear Marek,
> 
>> From: Marek Vasut <marex@denx.de>
>> Sent: lundi 27 avril 2020 12:30
>>
>> On 4/24/20 4:31 PM, Patrick DELAUNAY wrote:
>>> Dear Marek,
>>>
>>>> From: Marek Vasut <marex@denx.de>
>>>> Sent: mardi 31 mars 2020 19:52
>>>>
>>>> The AV96 is in fact an assembly of DH Electronics DHCOR SoM on top of
>>>> an
>>>> AV96 reference board. Split the DTs to reflect that and make sure to
>>>> DHCOR SoM can be reused on other boards easily.
>>>>
>>>> It is also highly recommended to configure the board for the DHCOM
>>>> make stm32mp15_dhcom_basic_defconfig make
>>>> DEVICE_TREE=stm32mp15xx-dhcor-
>>>> avenger96
>>>> as that permits reusing the board code for the DH components, like
>>>> accessing and reading out the ethernet MAC from EEPROM.
>>>>
>>>> Signed-off-by: Marek Vasut <marex@denx.de>
>>>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>>> Cc: Patrick Delaunay <patrick.delaunay@st.com>
>>>> Cc: Patrice Chotard <patrice.chotard@st.com>
>>>> ---
>>>> V2: No change
>>>> V3: No change
>>>> ---
>>>
>>> Applied to u-boot-stm/master, with few modifications:
>>>
>>> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>>>
>>> -
>>> -&v3v3 {
>>> -	regulator-always-on;
>>> -};
>>
>> It seems this patch was applied incorrectly and the 1V8 and 3V3 differentiation
>> between the SoMs is completely missing from mainline. I will send a subsequent
>> patch to correct that.
> 
> Strange, I don't remember conflict on this patch....
> 
> And 1.8V was present for the dhcor.dtsi in initial patch,
> I miss something I thing when I apply the patch:
> 
> +++ b/arch/arm/dts/stm32mp15xx-dhcor.dtsi
> @@ -0,0 +1,231 @@
> +
> +	/* Enpirion EP3A8LQI U2 on the DHCOR */
> +	vdd_io: regulator-buck-io {
> +		compatible = "regulator-fixed";
> +		regulator-name = "buck-io";
> +		regulator-min-microvolt = <1800000>;
> +		regulator-max-microvolt = <1800000>;
> +		regulator-always-on;
> +		regulator-boot-on;
> +		vin-supply = <&vdd>;
> +	};
> [...]
> +
> +&pwr_regulators {
> +	vdd-supply = <&vdd_io>;
> +	vdd_3v3_usbfs-supply = <&vdd_usb>;
> +};
> 
> Anyway thanks to the check and the correction.

The thing is, there are two versions of the SoM that's soldered on the
bottom of the AV96. The one on AV96 has that regulator populated, but
that is optional, so for other devices you can just opt for 3V3 IO and
the regulator won't be there. That's why there are the two DTs (io1v8
and io3v3).