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

[Frieder Schrempf]

On 30.03.26 04:23, 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.
>>
>> Best regards
>> Frieder
>>
>> Relevant U-Boot patchset:
>> https://patchwork.ozlabs.org/project/uboot/cover/20250811131213.211124-1-frieder@fris.de/
>>
>> Relevant Kernel patchset:
>> https://patchwork.kernel.org/project/linux-arm-kernel/cover/20241218152842.97483-1-frieder@fris.de/
> 
> I think this kernel patchset might be wrong.
> 
> GPIO1_04 is muxed as SD2_VSEL, reading GPIO1_04 will not able to get the PAD
> value of SD2_VSEL.
> 
> I also tried in U-Boot on i.MX8MP-EVK.
> u-boot=> mw 0x30330024 0x11 ==> set SION and MUX as SD2_VSELECT
> u-boot=> md 0x30b500c0 1
> 30b500c0: 2000780b      ==>BIT 1 is VSEL, already 1                       .x.
> u-boot=> md 0x30330284 1
> 30330284: 000000c0                             ....
> u-boot=> mw 0x30330284 0x1d0  ==> Configure PAD
> u-boot=> md 0x30200000 4       ==>Read back GPIO1
> 30200000: 00001028 00000000 00001028 00000000  (.......(.......
> 
> value of GPIO1_IO4 is 0, not 1, but VSEL register is 1 in SDHC2.

I think you are right. I probably misinterpreted the documentation.

> 
> So with your kernel patchset, reading the voltage, it will always return 3.3v.

Not really. Reading the voltage in U-Boot works fine, which is why I
thought this is correct. But I probably also misinterpreted my test
results, as this only works by coincidence. We now always read from
LDO5CTRL_L and this seems to have the correct value even if LDO5CTRL_H
is actually in use.

UHS card:

=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
=> mmc info
Device: FSL_SDHC
Manufacturer ID: 27
OEM: 5048
Name: SD8GB
Bus Speed: 200000000
Mode: UHS SDR104 (208MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 7.2 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
=> regulator dev "NVCC_SD (LDO5)"
dev: NVCC_SD (LDO5) @ LDO5
=> regulator value
1800000 uV

HS card:

=> mmc dev 1
switch to partitions #0, OK
mmc1 is current device
=> mmc info
Device: FSL_SDHC
Manufacturer ID: 6f
OEM: 303
Name: CBADS
Bus Speed: 50000000
Mode: SD High Speed (50MHz)
Rd Block Len: 512
SD version 3.0
High Capacity: Yes
Capacity: 3.8 GiB
Bus Width: 4-bit
Erase Group Size: 512 Bytes
=> regulator value
3300000 uV