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

[Frieder Schrempf]

On 26.03.26 09:05, Peng Fan wrote:
> 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 at 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 at 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;
>  }
> 

Ah, this is the part I was missing. The driver is reading the regulator
voltage to check the mode. This returns the wrong value due to the
reasons explained above.

Thanks for investigating!