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

Frieder Schrempf
2026-03-25T11:36:12Z

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.

Best regards
Frieder