rk3399-nanopi4.dtsi: enable sdmmc regulator on boot
Subsystems (2)
PATCH 1/1 rk3399-nanopi4.dtsi: enable sdmmc regulator on boot
When trying to boot a nanopi-m4 board with an SDHC-class uSD card, the boot comes to a full stop shortly after initializing the mmc subsystem. The boot can be cajoled into continuing if, after waiting a minute or so, the uSD card is ejected and re-inserted. Waiting a minute or so before ejecting and re-inserting the uSD card is crucial since the boot will not continue if the card is ejected/re-inserted too soon after the boot has stopped.
The nanopi-m4 has a uSD card and an optional eMMC module, either of which can be used for booting. In my case I don't have the optional eMMC module, therefore I'm booting from the uSD card. When booting from the uSD card, its regulator needs to be enabled at boot.
Curiously, this should have been an issue from day one, but it only started to become a problem after commit 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators") was merged. Additionally, by coincidence, I happened to be using an SDHC-class card in my device, and saw the failure. However, if I use an SDXC-class uSD card the problem does not occur.
Much thanks to Mark Brown and Javier Martinez Canillas for their assistance on irc!
--- arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 + 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +1 -0
@@ -71,6 +71,7 @@ vcc3v0_sd: vcc3v0-sd { pinctrl-names = "default"; pinctrl-0 = <&sdmmc0_pwr_h>; regulator-always-on; + regulator-boot-on; regulator-min-microvolt = <3000000>; regulator-max-microvolt = <3000000>; regulator-name = "vcc3v0_sd";
Signature · 1 line
2.30.0.rc0
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi vcc3v0_sd: vcc3v0-sd { · line 74
Quoted 5 lines · Trevor Woerner
arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +1
-0@@ -71,6 +71,7 @@ vcc3v0_sd: vcc3v0-sd { pinctrl-names = "default"; pinctrl-0 = <&sdmmc0_pwr_h>; regulator-always-on; + regulator-boot-on;
This shouldn't be required for devices that can read their status, the fact that it's always on should cause it to be powered up if it wasn't already when applying constraints. I'm therefore confused as to what this change is doing and there's probably something else going on here.