mmc: k1: multi-block SD reads in SPL and a probe failure fix

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/[email protected]/

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(-)

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/[email protected]/

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(-)

Quoted 49 lines · 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/[email protected]/

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

Quoted 8 lines

  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 <[email protected]> # Babanapi-F3

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/[email protected]/

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

Hi Peng Fan,

Quoted 41 lines · 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/[email protected]/

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

Quoted 4 lines

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]

Signature · 1 line

Yixun Lan (dlan)

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.

[...]