[PATCH V3 00/14] ARM: stm32: Fix Avenger96
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
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; }; };
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
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 */
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
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>; + }; };
ðernet0 { @@ -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"; };
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
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 */
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
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;
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
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@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"; };
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
Hi,
-----Original Message----- From: Marek Vasut marex@denx.de Sent: mardi 31 mars 2020 19:51 To: u-boot@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
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@c0000000 { device_type = "memory"; reg = <0xC0000000 0x40000000>; @@ -187,7 +191,7 @@ }; };
- eeprom@50 { + eeprom0: eeprom@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@5c002000/eeprom@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;
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
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@53 { + compatible = "atmel,24c02"; + reg = <0x53>; + pagesize = <16>; + }; };
&iwdg2 {
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@53) to be compatible with previous patch "ARM: dts: stm32: Use DT alias for the configuration EEPROM"
Regards
Patrick
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@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.
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 */
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
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 @@
ðernet0 { status = "okay"; - pinctrl-0 = <ðernet0_rgmii_pins_a>; - pinctrl-1 = <ðernet0_rgmii_pins_sleep_a>; + pinctrl-0 = <ðernet0_rgmii_pins_b>; + pinctrl-1 = <ðernet0_rgmii_pins_sleep_b>; pinctrl-names = "default", "sleep"; phy-mode = "rgmii"; max-speed = <1000>;
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
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>;
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
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>; + }; };
ðernet0 { @@ -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>; };
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>;- };
};
ðernet0 { @@ -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
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 ?
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
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 ?
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@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
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@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
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@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@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
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 ?
-----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@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
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 ?
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
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@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; }; };
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
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.
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@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.
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@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.
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@3 { cfg = < 3 98 5 7 7 PQR(1,1,1) >; u-boot,dm-pre-reloc; };
[...]
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@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
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@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.)
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@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
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 = ðernet0; - mmc0 = &sdmmc1; - serial0 = &uart4; - serial1 = &uart7; - spi0 = &qspi; - }; - - chosen { - stdout-path = "serial0:115200n8"; - }; - - memory@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>; - }; -}; - -ðernet0 { - status = "okay"; - pinctrl-0 = <ðernet0_rgmii_pins_b>; - pinctrl-1 = <ðernet0_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@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@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@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@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 = ðernet0; + 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>; + }; +}; + +ðernet0 { + status = "okay"; + pinctrl-0 = <ðernet0_rgmii_pins_b>; + pinctrl-1 = <ðernet0_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@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@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@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@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@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
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
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.
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
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).
participants (6)
-
Gerald BAEZA -
Manivannan Sadhasivam -
Marek Vasut -
Pascal PAILLET-LME -
Patrice CHOTARD -
Patrick DELAUNAY