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

Peng Fan peng.fan at oss.nxp.com
Mon Mar 30 04:23:21 CEST 2026


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.

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

Regards
Peng

>
>Example for sd-vsel-gpios:
>https://source.denx.de/u-boot/u-boot/-/blob/master/dts/upstream/src/arm64/freescale/imx8mp-kontron-osm-s.dtsi#L314
>
>Example for pinmux with SION bit:
>https://source.denx.de/u-boot/u-boot/-/blob/master/dts/upstream/src/arm64/freescale/imx8mp-kontron-osm-s.dtsi#L812


More information about the U-Boot mailing list