Re: [PATCH 1/4] imx8mp: phyboard-pollux-rdk: Convert to DM_PMIC

Teresa Remmet
2026-03-26T08:45:06Z

Hello Peng,

Am Donnerstag, dem 26.03.2026 um 16:05 +0800 schrieb Peng Fan:
> Hi Teresa,
>
> On Wed, Mar 25, 2026 at 12:35:59PM +0100, Frieder Schrempf wrote:
> > Hi Peng,
> >
> > On 25.03.26 12:12, Peng Fan wrote:
> > > Hi Frieder,
> > >
> > > On Wed, Mar 25, 2026 at 08:40:26AM +0100, Frieder Schrempf wrote:
> > > > On 25.03.26 04:50, Peng Fan wrote:
> > > > > > Subject: Re: [PATCH 1/4] imx8mp: phyboard-pollux-rdk:
> > > > > > Convert to
> > > > > > DM_PMIC
> > > > > >
> > > > > > Hello Peng,
> > > > > > Hello Yannic,
> > > > > >
> > > > > > Am Dienstag, dem 24.03.2026 um 13:33 +0000 schrieb Peng
> > > > > > Fan:
> > > > > > > Hi Yannic,
> > > > > > >
> > > > > > > > Subject: Re: [PATCH 1/4] imx8mp: phyboard-pollux-rdk:
> > > > > > > > Convert to
> > > > > > > > DM_PMIC
> > > > > > > >
> > > > > > > > Hi Peng,
> > > > > > > >
> > > > > > > > On Tue, 2026-03-24 at 18:30 +0800, Peng Fan (OSS)
> > > > > > > > wrote:
> > > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > > >
> > > > > > > > > Convert the board to use DM_PMIC instead of the
> > > > > > > > > legacy SPL
> > > > > > > > I2C/PMIC
> > > > > > > > > handling.
> > > > > > > > >
> > > > > > > > > Changes include:
> > > > > > > > > - Enable DM_PMIC, DM_PMIC_PCA9450, and
> > > > > > > > SPL_DM_PMIC_PCA9450 in defconfig.
> > > > > > > > > - Drop legacy SPL I2C and PMIC options.
> > > > > > > > > - Remove manual I2C1 pad setup and legacy
> > > > > > > > > power_pca9450_init()
> > > > > > > > usage.
> > > > > > > > > - Use DM-based pmic_get() with the DT node "pmic@25".
> > > > > > > > > - Update PMIC register programming to use struct
> > > > > > > > > udevice API.
> > > > > > > >
> > > > > > > > these changes break something.
> > > > > > > >
> > > > > > > > Getting
> > > > > > > >
> > > > > > > > Loading Environment from MMC... Card did not respond to
> > > > > > > > voltage
> > > > > > > > select! : -110
> > > > > > > > *** Warning - No block device, using default
> > > > > > > > environment
> > > > > > > >
> > > > > > > > and SD card is not accessible as a result. I also
> > > > > > > > worked on this
> > > > > > > > modernization and got the same result as with your
> > > > > > > > commit. Have
> > > > > > not
> > > > > > > > had time to investigate the cause, yet.
> > > > > > >
> > > > > > > This change should not impact sd, unless pmic not probe
> > > > > > > correctly.
> > > > > > > You may give a look on "regulators", "pmic" in U-Boot
> > > > > > > shell, to see
> > > > > > > whether pmic is good.
> > > > > > >
> > > > > > > And you may also need to confirm, whether SD works or not
> > > > > > > without
> > > > > > this
> > > > > > > migration to DM_PMIC.
> > > > > >
> > > > > > I see the same issue. The error is gone when the patch is
> > > > > > reverted again.
> > > > > > PMIC probing is working but the voltage change of SD-Card
> > > > > > is probably
> > > > > > not.
> > > > > > We have set
> > > > > > dts/upstream/src/arm64/freescale/imx8mp-phycore-fpsc.dtsi:
> > > > > > vqmmc-supply = <&ldo5>;
> > > > > >
> > > > > > which references the PMIC.
> > > > > > The evk is not using this property.
> > > > >
> > > > > I tried to add vqmmc-supply for i.MX8MP-EVK, I not see
> > > > > issues.
> > > > > Not sure why this property impacts phycore-fpsc.
> > > > >
> > > > > The only suspecting point is
> > > > >
> > > > > -
> > > > > MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0xc0
> > > > > +
> > > > > MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT 0x1c0
> > > > >
> > > > > No more ideas as of now.
> > > >
> > > > I'm pretty sure this issue is related to the VSELECT signal in
> > > > some way.
> > > >
> > > > With MX8MP_IOMUXC_GPIO1_IO04__USDHC2_VSELECT being set, the
> > > > SDHC
> > > > controller controls the VSELECT signal that goes into the
> > > > SD_VSEL input
> > > > of the PMIC and switches the LDO5 between 1.8V and 3.3V.
> > > > Internally the
> > > > PMIC uses the state of SD_VSEL to decide which one of two
> > > > voltage
> > > > registers for LDO5 is used.
> > > >
> > > > When vqmmc-supply is set, the driver additionally sets the
> > > > voltage by
> > > > writing to the PMIC LDO5 voltage register. This can potentially
> > > > cause
> > > > conflicts and lead to an invalid state, where the driver thinks
> > > > the card
> > > > is in 1.8V state but the voltage is set to 3.3V or the other
> > > > way round.
> > > >
> > > > One way to handle this, is to set the SION bit for the VSELECT
> > > > signal
> > > > and specify the sd-vsel-gpios property in the ldo5 node. This
> > > > allows the
> > > > PMIC driver to know about the current state of the VSELECT
> > > > signal and
> > > > use the correct voltage register when setting or getting the
> > > > LDO5 voltage.
> > > >
> > > > Below you can find some pointers for additional information. I
> > > > hope this
> > > > helps to solve the issue on your board.
> > >
> > > Thanks for the detailed information. But I still have a question:
> > > For current phyboard-pollux-rdk, vqmmc-supply will always use
> > > PCA9450_LDO5CTRL_H for regulator value configuration.
> > >
> > > In drivers/mmc/fsl_esdhc_imx.c, when configure with 3.3V,
> > > PCA9450_LDO5CTRL_H
> > > will configured to 3.3V, but SD_VSEL is low, so no impact. When
> > > configure
> > > with 1.8V, PCA9450_LDO5CTRL_H will be configured to 1.8V, and
> > > SD_VSEL is high,
> > > so it should work.
> > >
> > > or I may miss something.
> >
> > I think you are right. The process is the same as in Linux and I
> > never
> > saw any issue there. Just the fact that when reading back the
> > voltage of
> > the LDO5 regulator in Linux or U-Boot you could get a wrong value.
> > This
> > can be fixed as described before.
> >
> > So I'm really not sure what the actual problem is. I remember
> > having a
> > similar or the same issue with our Kontron boards before switching
> > to
> > the upstream DTS with sd-vsel-gpios. So it might also fix this
> > issue
> > here, but of course it would be good to know the actual reason.
>
> If possible, please help do a test. After applying the conver to
> DM_PMIC
> patch, then apply below patch to see whether you issue is gone.
>
> diff --git a/drivers/mmc/fsl_esdhc_imx.c
> b/drivers/mmc/fsl_esdhc_imx.c
> index 335b44a8a1a..f92c0c91c4d 100644
> --- a/drivers/mmc/fsl_esdhc_imx.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -1454,8 +1454,11 @@ static int fsl_esdhc_of_to_plat(struct udevice
> *dev)
>                         return ret;
>                 }
>
> -               if (regulator_get_value(vqmmc_dev) == 1800000)
> +               if (regulator_get_value(vqmmc_dev) == 1800000) {
> +                       printf("value is 1.8V?????????????\n");
>                         priv->vs18_enable = 1;
> +               }
> +               priv->vs18_enable = 0;
>         }
>         return 0;
>  }
>
> If issue gone, I think issue is clear, driver think it is 1.8v, but
> it is
> 3.3v actually.

With your Convert DM_PMIC patchstack and the change above (and without
Frieders dt changes) the issue is gone:

[...]
U-Boot 2026.04-rc5-00005-g548f723f63d9-dirty (Mar 26 2026 - 09:34:32
+0100)

CPU: NXP i.MX8MP[8] Rev1.1 A53 at 1200 MHz
CPU: Industrial temperature grade (-40C to 105C) at 31C
Model: PHYTEC phyBOARD-Pollux i.MX8MP
DRAM: 2 GiB
I/TC: Reserved shared memory is enabled
I/TC: Dynamic shared memory is enabled
I/TC: Normal World virtualization support is disabled
I/TC: Asynchronous notifications are disabled
Core: 254 devices, 32 uclasses, devicetree: separate
WDT: Started watchdog@30280000 with servicing every 1000ms (60s
timeout)
MMC: value is 1.8V?????????????
FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Reading from MMC(1)... OK
In: serial@30860000
Out: serial@30860000
Err: serial@30860000
SEC0: RNG instantiated
Net: eth0: ethernet@30be0000
Hit any key to stop autoboot: 0

>
> Frieder's fix is still the best for your platform, you could go with
> that.
> Other platforms using vqmmc may also needs same fix.

Okay, thanks. We will then create the dt patch.

Thanks,
Teresa

>
> Thanks,
> Peng
>
> >
> > Best regards
> > Frieder
> >
> >

--
PHYTEC Messtechnik GmbH | Barcelona-Allee 1 | 55129 Mainz, Germany

Geschäftsführer: Dipl.-Ing. Michael Mitezki, Dipl.-Ing. Bodo Huber,
Dipl.-Ing. (FH) Markus Lickes | Handelsregister Mainz HRB 4656 |
Finanzamt Mainz | St.Nr. 26/665/00608, DE 149059855