[PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Tanmay Kathpalia]

I am taking this series over from Dave (thanks, Dave).

Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
is Dave's multi-block change, and patch 4 is Dave's probe error path
fix, narrowed to the resets because, as Yixun pointed out, the clocks
are reference counted.

Not in this version:
- v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
  should be set up with assigned-clock-parents/rates in the DT, which
  also works for Linux; that will follow separately. Hung-Chun has
  withdrawn his matching RFC.
- SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
  (there is no SPL Kconfig symbol for it yet), so it would not program
  any pads. It will follow separately once it has been tested on
  hardware.

Testing: I do not have a K1 board, so v3 itself is build-tested only.
The changes were tested piecewise in the v2 thread, and in each case
multi-block SD reads in the SPL worked: Zixian enabled
SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.

Thanks also to Anand for testing v2.

v2: https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/

Changes in v3:
- New: configs: k1: enable SPL_MMC_IO_VOLTAGE
- New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
- v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
  failures; code unchanged
- v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
  reset_release_bulk()
- Drop v2 1/3

Dave Klotz (2):
  mmc: k1: let the SPL read SD cards more than one block at a time
  mmc: k1: do not assert the shared AXI reset on probe failure

Tanmay Kathpalia (2):
  configs: k1: enable SPL_MMC_IO_VOLTAGE
  spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL

 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 10 ++++----
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 +-
 board/spacemit/k1/spl.c                   | 21 -----------------
 configs/spacemit_k1_defconfig             |  1 +
 doc/board/spacemit/k1-spl.rst             |  1 -
 drivers/mmc/spacemit_sdhci.c              | 28 ++++++++---------------
 6 files changed, 17 insertions(+), 46 deletions(-)

-- 
2.43.7

[PATCH v3 1/4] configs: k1: enable SPL_MMC_IO_VOLTAGE

[Tanmay Kathpalia]

The SD I/O rail of the K1 boards (VCC1833_MMC1, PMIC aldo1, the
vqmmc-supply of sdhci0) can run at 1.8 V or 3.3 V. Without
SPL_MMC_IO_VOLTAGE the MMC core in the SPL never sets it:
mmc_set_signal_voltage() is an empty stub, so the card is driven at
whatever voltage the rail was left at, which is 1.8 V from
pmic_init(). SD Default and High Speed use 3.3 V signalling.

Single-block reads happen to work at 1.8 V, and the SPL reads SD cards
one block at a time, which hid this. With multi-block reads, a 32-block
read on a Banana Pi BPI-F3 aborted part-way with a Data End Bit error,
while U-Boot proper, which sets 3.3 V, read the same blocks without
error.

Enable SPL_MMC_IO_VOLTAGE so that the SPL sets the rail to 3.3 V
through vqmmc-supply before it talks to the card.

Reported-by: Zixian Zeng <sycamoremoon376@gmail.com>
Closes: https://lore.kernel.org/u-boot/20261005T135733-0400.mmc-v2-0002.DaveWK225@protonmail.com/
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
Changes in v3:
- New patch
---
 configs/spacemit_k1_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/spacemit_k1_defconfig b/configs/spacemit_k1_defconfig
index 39c490438d3..b67b9f3058a 100644
--- a/configs/spacemit_k1_defconfig
+++ b/configs/spacemit_k1_defconfig
@@ -83,6 +83,7 @@ CONFIG_SPL_I2C_EEPROM=y
 CONFIG_MMC=y
 CONFIG_SUPPORT_EMMC_BOOT=y
 CONFIG_MMC_IO_VOLTAGE=y
+CONFIG_SPL_MMC_IO_VOLTAGE=y
 CONFIG_MMC_HS400_ES_SUPPORT=y
 CONFIG_MMC_HS400_SUPPORT=y
 CONFIG_MMC_SDHCI=y
-- 
2.43.7

[PATCH v3 2/4] spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL

[Tanmay Kathpalia]

set_vdd_mmc() sets PMIC aldo1 to 1.8 V. On the K1 boards aldo1 is
VCC1833_MMC1, the I/O rail of the SD card pads (vqmmc-supply of
sdhci0), and SD Default and High Speed signal at 3.3 V. The BootROM
sets it to 3.3 V on a cold boot, and with SPL_MMC_IO_VOLTAGE the MMC
core sets it before talking to the card, so the board code should not
touch it.

Drop set_vdd_mmc() and the U-Boot-only "vdd_1v8_mmc" name it looked
up, and the matching line in the sample SPL log. aldo1 keeps
bootph-pre-ram, as the SPL needs it as the vqmmc-supply.

Fixes: 80aa3d316060 ("board: k1: enable pmic in spl")
Suggested-by: Yixun Lan <dlan@kernel.org>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
Changes in v3:
- New patch
---
 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 10 +++++-----
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 +-
 board/spacemit/k1/spl.c                   | 21 ---------------------
 doc/board/spacemit/k1-spl.rst             |  1 -
 4 files changed, 6 insertions(+), 28 deletions(-)

diff --git a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
index 3077cdee55d..36c1bfc12fb 100644
--- a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
+++ b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
@@ -57,10 +57,11 @@
 };
 
 /*
- * The kernel pmic@41 nodes use the standard regulator-* properties only;
- * U-Boot's regulator framework looks up suppliers by `regulator-name`.
- * Carry the U-Boot-specific names (vdd_core / vdd_1v8 / vdd_1v8_mmc) here
- * so SPL can program the bucks that DDR training depends on.
+ * The kernel pmic@41 nodes use the standard regulator-* properties only.
+ * The SPL board code looks up the bucks that DDR training depends on by
+ * `regulator-name`, so carry the U-Boot-specific names (vdd_core /
+ * vdd_1v8) here. aldo1 is the vqmmc-supply of sdhci0 and is needed in
+ * SPL as well.
  */
 &i2c8 {
 	bootph-pre-ram;
@@ -80,7 +81,6 @@
 			};
 
 			aldo1 {
-				regulator-name = "vdd_1v8_mmc";
 				bootph-pre-ram;
 			};
 		};
diff --git a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
index d6299c96949..200836cc204 100644
--- a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
+++ b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
@@ -105,9 +105,9 @@
 				regulator-name = "vdd_1v8";
 			};
 
+			/* vqmmc-supply of sdhci0, set by the MMC core in SPL */
 			aldo1 {
 				bootph-pre-ram;
-				regulator-name = "vdd_1v8_mmc";
 			};
 
 		};
diff --git a/board/spacemit/k1/spl.c b/board/spacemit/k1/spl.c
index ef23db62d6c..87fde0293a9 100644
--- a/board/spacemit/k1/spl.c
+++ b/board/spacemit/k1/spl.c
@@ -275,26 +275,6 @@ static void set_vdd_1v8(void)
 	log_info("vdd_1v8, value:%d\n", ret);
 }
 
-static void set_vdd_mmc(void)
-{
-	struct udevice *dev;
-	int ret;
-
-	ret = regulator_get_by_platname("vdd_1v8_mmc", &dev);
-	if (ret)
-		panic("Fail to detect vdd_1v8_mmc (%d)\n", ret);
-	ret = regulator_set_value(dev, 1800000);
-	if (ret)
-		log_warning("Fail to set vdd_1v8_mmc as 1800000 (%d)\n", ret);
-	ret = regulator_set_enable(dev, true);
-	if (ret)
-		log_warning("Fail to enable vdd_1v8_mmc (%d)\n", ret);
-	ret = regulator_get_value(dev);
-	if (ret < 0)
-		log_warning("Fail to read vdd_1v8_mmc (%d)\n", ret);
-	log_info("vdd_1v8_mmc, value:%d\n", ret);
-}
-
 void pmic_init(void)
 {
 	struct udevice *pmic_dev;
@@ -305,7 +285,6 @@ void pmic_init(void)
 		panic("Fail to detect PMIC (%d)\n", ret);
 	set_vdd_core();
 	set_vdd_1v8();
-	set_vdd_mmc();
 }
 
 /* Set default value for DDR chips */
diff --git a/doc/board/spacemit/k1-spl.rst b/doc/board/spacemit/k1-spl.rst
index 187eed56e8e..69ebfc5ccb9 100644
--- a/doc/board/spacemit/k1-spl.rst
+++ b/doc/board/spacemit/k1-spl.rst
@@ -211,7 +211,6 @@ shows output like::
     Fail to detect board:-19
     vdd_core, value:900000
     vdd_1v8, value:1800000
-    vdd_1v8_mmc, value:1800000
     DDR firmware: [0xc0815840]:0xf0227179, size:0x8d98
     DDR is ready
     SPL: Unsupported Boot Device!
-- 
2.43.7

[PATCH v3 3/4] mmc: k1: let the SPL read SD cards more than one block at a time

[Tanmay Kathpalia]

From: Dave Klotz <DaveWK225@protonmail.com>

spacemit_sdhci_get_b_max() limits every SD read in the SPL to a single
block, so loading a 1 MiB u-boot.itb takes about 2000 commands. The
limit came with the driver without a recorded hardware reason. The
driver uses PIO and does not advertise MMC_CAP_CMD23, so a multi-block
read is a CMD18 followed by a CMD12.

Multi-block reads in the SPL failed on the Banana Pi BPI-F3 with a
Data End Bit error and returned no blocks on the Milk-V Jupiter. Both
failures came from the SD I/O rail being left at 1.8 V; with the rail
at 3.3 V, multi-block reads in the SPL work on both boards. The SPL
now sets the rail to 3.3 V through vqmmc-supply.

Drop the limit and use the host's b_max.

Signed-off-by: Dave Klotz <DaveWK225@protonmail.com>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
Changes in v3:
- Commit message explains the BPI-F3 and Jupiter failures and the
  CMD18/CMD12 sequence; code unchanged
---
 drivers/mmc/spacemit_sdhci.c | 11 -----------
 1 file changed, 11 deletions(-)

diff --git a/drivers/mmc/spacemit_sdhci.c b/drivers/mmc/spacemit_sdhci.c
index f5578f38bdd..d3748847e48 100644
--- a/drivers/mmc/spacemit_sdhci.c
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -324,16 +324,6 @@ static int spacemit_sdhci_wait_dat0(struct udevice *dev, int state,
 	return 0;
 }
 
-static int spacemit_sdhci_get_b_max(struct udevice *dev, void *dst,
-				    lbaint_t blkcnt)
-{
-	struct mmc *mmc = mmc_get_mmc_dev(dev);
-
-	if (IS_ENABLED(CONFIG_SPL_BUILD) && mmc && IS_SD(mmc))
-		return 1;
-	return mmc->cfg->b_max;
-}
-
 static void spacemit_sdhci_set_control_reg(struct sdhci_host *host)
 {
 	struct mmc *mmc = host->mmc;
@@ -574,7 +564,6 @@ static int spacemit_sdhci_probe(struct udevice *dev)
 
 	spacemit_mmc_ops = sdhci_ops;
 	spacemit_mmc_ops.wait_dat0 = spacemit_sdhci_wait_dat0;
-	spacemit_mmc_ops.get_b_max = spacemit_sdhci_get_b_max;
 
 	ret = clk_get_bulk(dev, &plat->clks);
 	if (ret) {
-- 
2.43.7

[PATCH v3 4/4] mmc: k1: do not assert the shared AXI reset on probe failure

[Tanmay Kathpalia]

From: Dave Klotz <DaveWK225@protonmail.com>

All three SDHCI controllers of the K1 share the SDH AXI reset, which
is the "axi" entry of every node's resets. When a probe fails, the
error path calls reset_release_bulk(), which asserts each reset.
Resets are not reference counted, so this holds the AXI bus of the
controllers that already probed in reset. mmc_probe() probes the
controllers by sequence number and then again in uclass order, so a
failing controller asserts the reset again after the others have
probed, whichever one it is, and the next access to another
controller hangs the hart.

The clocks are reference counted, so releasing them only drops this
controller's reference. Keep that, and leave the resets deasserted.
The SpacemiT reset driver has no rfree, so nothing leaks.

Fixes: 18e9745c9327 ("mmc: k1: add sdhci platform driver")
Signed-off-by: Dave Klotz <DaveWK225@protonmail.com>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia@altera.com>
---
Changes in v3:
- Keep clk_release_bulk(); only drop reset_release_bulk()
- Merge the err_reset label into err_clk
- Reworded the commit message
---
 drivers/mmc/spacemit_sdhci.c | 17 ++++++++++-------
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/spacemit_sdhci.c b/drivers/mmc/spacemit_sdhci.c
index d3748847e48..fdedb9a301a 100644
--- a/drivers/mmc/spacemit_sdhci.c
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -586,19 +586,19 @@ static int spacemit_sdhci_probe(struct udevice *dev)
 	ret = reset_deassert_bulk(&plat->resets);
 	if (ret) {
 		log_err("Failed to reset: %d\n", ret);
-		goto err_reset;
+		goto err_clk;
 	}
 
 	ret = clk_get_by_index(dev, 1, &clk);
 	if (ret) {
 		log_err("Can't get io clk: %d\n", ret);
-		goto err_reset;
+		goto err_clk;
 	}
 
 	ret = clk_set_rate(&clk, plat->cfg.f_max);
 	if (ret) {
 		log_err("Failed to set io clk: %d\n", ret);
-		goto err_reset;
+		goto err_clk;
 	}
 
 	/* Set quirks */
@@ -613,17 +613,20 @@ static int spacemit_sdhci_probe(struct udevice *dev)
 	ret = sdhci_setup_cfg(&plat->cfg, host, plat->cfg.f_max,
 			      SDHC_MIN_CLOCK);
 	if (ret)
-		goto err_reset;
+		goto err_clk;
 
 	ret = sdhci_probe(dev);
 	if (ret)
-		goto err_reset;
+		goto err_clk;
 
 	spacemit_sdhci_phy_init(dev, host);
 	return 0;
 
-err_reset:
-	reset_release_bulk(&plat->resets);
+	/*
+	 * Leave the resets deasserted: the "axi" reset is shared by all
+	 * three SDHCI controllers and is not reference counted, so
+	 * asserting it would hold the bus of the others in reset.
+	 */
 err_clk:
 	clk_release_bulk(&plat->clks);
 	return ret;
-- 
2.43.7

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Yixun Lan]

Hi Tanmay Kathpalia,

On 14:54 Sat 31 Oct     , Tanmay Kathpalia wrote:
> I am taking this series over from Dave (thanks, Dave).
> 
> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
> is Dave's multi-block change, and patch 4 is Dave's probe error path
> fix, narrowed to the resets because, as Yixun pointed out, the clocks
> are reference counted.
> 
> Not in this version:
> - v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
>   should be set up with assigned-clock-parents/rates in the DT, which
>   also works for Linux; that will follow separately. Hung-Chun has
>   withdrawn his matching RFC.
> - SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
>   (there is no SPL Kconfig symbol for it yet), so it would not program
>   any pads. It will follow separately once it has been tested on
>   hardware.
> 
> Testing: I do not have a K1 board, so v3 itself is build-tested only.
> The changes were tested piecewise in the v2 thread, and in each case
> multi-block SD reads in the SPL worked: Zixian enabled
> SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
> a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
> Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.
> 
> Thanks also to Anand for testing v2.
> 
> v2: https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/
> 
> Changes in v3:
> - New: configs: k1: enable SPL_MMC_IO_VOLTAGE
> - New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
> - v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
>   failures; code unchanged
> - v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
>   reset_release_bulk()
> - Drop v2 1/3
> 
> Dave Klotz (2):
>   mmc: k1: let the SPL read SD cards more than one block at a time
>   mmc: k1: do not assert the shared AXI reset on probe failure
> 
> Tanmay Kathpalia (2):
>   configs: k1: enable SPL_MMC_IO_VOLTAGE
>   spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
> 
>  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 10 ++++----
>  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 +-
>  board/spacemit/k1/spl.c                   | 21 -----------------
>  configs/spacemit_k1_defconfig             |  1 +
>  doc/board/spacemit/k1-spl.rst             |  1 -
>  drivers/mmc/spacemit_sdhci.c              | 28 ++++++++---------------
>  6 files changed, 17 insertions(+), 46 deletions(-)
> 

The series looks good to me, also tested on BPI-F3 board

Tested-by: Yixun Lan <dlan@kernel.org>
Reviewed-by: Yixun Lan <dlan@kernel.org>

-- 
Yixun Lan (dlan)

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Zixian Zeng]

On 2026/11/1 05:54, Tanmay Kathpalia wrote:
> I am taking this series over from Dave (thanks, Dave).
> 
> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
> is Dave's multi-block change, and patch 4 is Dave's probe error path
> fix, narrowed to the resets because, as Yixun pointed out, the clocks
> are reference counted.
> 
> Not in this version:
> - v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
>    should be set up with assigned-clock-parents/rates in the DT, which
>    also works for Linux; that will follow separately. Hung-Chun has
>    withdrawn his matching RFC.
> - SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
>    (there is no SPL Kconfig symbol for it yet), so it would not program
>    any pads. It will follow separately once it has been tested on
>    hardware.
> 
> Testing: I do not have a K1 board, so v3 itself is build-tested only.
> The changes were tested piecewise in the v2 thread, and in each case
> multi-block SD reads in the SPL worked: Zixian enabled
> SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
> a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
> Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.
> 
> Thanks also to Anand for testing v2.
> 
> v2: https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/
> 
> Changes in v3:
> - New: configs: k1: enable SPL_MMC_IO_VOLTAGE
> - New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
> - v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
>    failures; code unchanged
> - v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
>    reset_release_bulk()
> - Drop v2 1/3
> 
> Dave Klotz (2):
>    mmc: k1: let the SPL read SD cards more than one block at a time
>    mmc: k1: do not assert the shared AXI reset on probe failure
> 
> Tanmay Kathpalia (2):
>    configs: k1: enable SPL_MMC_IO_VOLTAGE
>    spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
> 
>   arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 10 ++++----
>   arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 +-
>   board/spacemit/k1/spl.c                   | 21 -----------------
>   configs/spacemit_k1_defconfig             |  1 +
>   doc/board/spacemit/k1-spl.rst             |  1 -
>   drivers/mmc/spacemit_sdhci.c              | 28 ++++++++---------------
>   6 files changed, 17 insertions(+), 46 deletions(-)
> 

Working fine, sorry for late testing.

Tested-by: Zixian Zeng <sycamoremoon376@gmail.com> # Babanapi-F3

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Yixun Lan]

Hi Peng Fan,

On 14:54 Sat 31 Oct     , Tanmay Kathpalia wrote:
> I am taking this series over from Dave (thanks, Dave).
> 
> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
> is Dave's multi-block change, and patch 4 is Dave's probe error path
> fix, narrowed to the resets because, as Yixun pointed out, the clocks
> are reference counted.
> 
> Not in this version:
> - v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
>   should be set up with assigned-clock-parents/rates in the DT, which
>   also works for Linux; that will follow separately. Hung-Chun has
>   withdrawn his matching RFC.
> - SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
>   (there is no SPL Kconfig symbol for it yet), so it would not program
>   any pads. It will follow separately once it has been tested on
>   hardware.
> 
> Testing: I do not have a K1 board, so v3 itself is build-tested only.
> The changes were tested piecewise in the v2 thread, and in each case
> multi-block SD reads in the SPL worked: Zixian enabled
> SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
> a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
> Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.
> 
> Thanks also to Anand for testing v2.
> 
> v2: https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/
> 
> Changes in v3:
> - New: configs: k1: enable SPL_MMC_IO_VOLTAGE
> - New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
> - v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
>   failures; code unchanged
> - v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
>   reset_release_bulk()
> - Drop v2 1/3
> 
> Dave Klotz (2):
>   mmc: k1: let the SPL read SD cards more than one block at a time
>   mmc: k1: do not assert the shared AXI reset on probe failure
> 
Generally ping for mmc patches, would it be Ok if I take patch-3,4
through spacemit's custodian tree[1], I'd genuinely appreciate an
Acked-by if that's fine with you..

Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit [1]

-- 
Yixun Lan (dlan)

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Kathpalia, Tanmay]

Hi Yixun, Zixian,

On 05-11-2026 20:10, Zixian Zeng wrote:
> On 2026/11/1 05:54, Tanmay Kathpalia wrote:
>> I am taking this series over from Dave (thanks, Dave).
>>
>> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
>> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
>> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
>> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
>> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
>> is Dave's multi-block change, and patch 4 is Dave's probe error path
>> fix, narrowed to the resets because, as Yixun pointed out, the clocks
>> are reference counted.
>>
>> Not in this version:
>> - v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
>>    should be set up with assigned-clock-parents/rates in the DT, which
>>    also works for Linux; that will follow separately. Hung-Chun has
>>    withdrawn his matching RFC.
>> - SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
>>    (there is no SPL Kconfig symbol for it yet), so it would not program
>>    any pads. It will follow separately once it has been tested on
>>    hardware.
>>
>> Testing: I do not have a K1 board, so v3 itself is build-tested only.
>> The changes were tested piecewise in the v2 thread, and in each case
>> multi-block SD reads in the SPL worked: Zixian enabled
>> SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
>> a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
>> Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.
>>
>> Thanks also to Anand for testing v2.
>>
>> v2: 
>> https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/
>>
>> Changes in v3:
>> - New: configs: k1: enable SPL_MMC_IO_VOLTAGE
>> - New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
>> - v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
>>    failures; code unchanged
>> - v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
>>    reset_release_bulk()
>> - Drop v2 1/3
>>
>> Dave Klotz (2):
>>    mmc: k1: let the SPL read SD cards more than one block at a time
>>    mmc: k1: do not assert the shared AXI reset on probe failure
>>
>> Tanmay Kathpalia (2):
>>    configs: k1: enable SPL_MMC_IO_VOLTAGE
>>    spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
>>
>>   arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 10 ++++----
>>   arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 +-
>>   board/spacemit/k1/spl.c                   | 21 -----------------
>>   configs/spacemit_k1_defconfig             |  1 +
>>   doc/board/spacemit/k1-spl.rst             |  1 -
>>   drivers/mmc/spacemit_sdhci.c              | 28 ++++++++---------------
>>   6 files changed, 17 insertions(+), 46 deletions(-)
>>
>
> Working fine, sorry for late testing.
>
> Tested-by: Zixian Zeng <sycamoremoon376@gmail.com> # Babanapi-F3

Thanks for testing the series on the BPI-F3, and for the Reviewed-by
and Tested-by tags (Yixun) and the Tested-by (Zixian).

Regards,
Tanmay

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Peng Fan]

On Thu, Nov 05, 2026 at 10:27:37PM +0000, Yixun Lan wrote:
>Hi Peng Fan,
>
>On 14:54 Sat 31 Oct     , Tanmay Kathpalia wrote:
>> I am taking this series over from Dave (thanks, Dave).
>> 
>> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
>> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
>> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
>> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
>> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
>> is Dave's multi-block change, and patch 4 is Dave's probe error path
>> fix, narrowed to the resets because, as Yixun pointed out, the clocks
>> are reference counted.
>> 
>> Not in this version:
>> - v2 1/3 (missing max-frequency). As Yixun suggested, the io clock
>>   should be set up with assigned-clock-parents/rates in the DT, which
>>   also works for Linux; that will follow separately. Hung-Chun has
>>   withdrawn his matching RFC.
>> - SPL_PINCTRL. On its own it links no K1 pinctrl driver into the SPL
>>   (there is no SPL Kconfig symbol for it yet), so it would not program
>>   any pads. It will follow separately once it has been tested on
>>   hardware.
>> 
>> Testing: I do not have a K1 board, so v3 itself is build-tested only.
>> The changes were tested piecewise in the v2 thread, and in each case
>> multi-block SD reads in the SPL worked: Zixian enabled
>> SPL_MMC_IO_VOLTAGE on a BPI-F3, Yixun dropped set_vdd_mmc() alone on
>> a BPI-F3, and Hung-Chun set aldo1 to 3.3 V on a Jupiter. Zixian,
>> Yixun, Hung-Chun: a Tested-by on v3 would be much appreciated.
>> 
>> Thanks also to Anand for testing v2.
>> 
>> v2: https://lore.kernel.org/u-boot/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/
>> 
>> Changes in v3:
>> - New: configs: k1: enable SPL_MMC_IO_VOLTAGE
>> - New: spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
>> - v2 2/3 -> 3/4: commit message explains the BPI-F3 and Jupiter
>>   failures; code unchanged
>> - v2 3/3 -> 4/4: keep clk_release_bulk(), only drop
>>   reset_release_bulk()
>> - Drop v2 1/3
>> 
>> Dave Klotz (2):
>>   mmc: k1: let the SPL read SD cards more than one block at a time
>>   mmc: k1: do not assert the shared AXI reset on probe failure
>> 
>Generally ping for mmc patches, would it be Ok if I take patch-3,4
>through spacemit's custodian tree[1], I'd genuinely appreciate an
>Acked-by if that's fine with you..

Acked-by: Peng Fan <peng.fan@nxp.com>

>
>Link: https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit [1]
>
>-- 
>Yixun Lan (dlan)

Re: [PATCH v3 0/4] mmc: k1: multi-block SD reads in SPL and a probe failure fix

[Yixun Lan]

On Sat, 31 Oct 2026 14:54:48 -0700, Tanmay Kathpalia wrote:
> I am taking this series over from Dave (thanks, Dave).
> 
> Testing v2 2/3 on a Banana Pi BPI-F3 and a Milk-V Jupiter showed that
> multi-block SD reads in the SPL fail because the SD I/O rail (PMIC
> aldo1) is at 1.8 V: set_vdd_mmc() sets it, and without
> SPL_MMC_IO_VOLTAGE the MMC core never sets it back to 3.3 V. Patch 1
> lets the MMC core set the rail, patch 2 drops set_vdd_mmc(), patch 3
> is Dave's multi-block change, and patch 4 is Dave's probe error path
> fix, narrowed to the resets because, as Yixun pointed out, the clocks
> are reference counted.
> 
> [...]

Applied, thanks! Queued in SpacemiT custodian tree, for-main branch

[1/4] configs: k1: enable SPL_MMC_IO_VOLTAGE
      https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/cfc62cc2890b2795ba8d8e32e63892179a7cec0b
[2/4] spacemit: k1: do not force the SD I/O rail to 1.8 V in SPL
      https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/e07305ad26367d8128a66d7c5b4f21e6427df25d
[3/4] mmc: k1: let the SPL read SD cards more than one block at a time
      https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/f0c22effafb3a03f6c3aecb231dd729864497404
[4/4] mmc: k1: do not assert the shared AXI reset on probe failure
      https://git.u-boot-project.org/u-boot/custodians/u-boot-spacemit/-/commit/3e9ab282be08a120ffc681406e72deaa7798e453

Best regards,
-- 
Yixun Lan <dlan@kernel.org>