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

Peng Fan
2026-03-26T08:03:42Z

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.

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

Thanks,
Peng

>
>Best regards
>Frieder
>
>