Three fixes for the K1 SDHCI driver that went into next with
"mmc: k1: add sdhci platform driver":
1. A node without max-frequency asks the clock framework for 0 Hz and
then fails in sdhci_setup_cfg(), and any non-zero return from
clk_set_rate() is treated as an error although it returns the rate.
2. The SPL reads SD cards one block per command, about 2000 commands
for a 1 MiB u-boot.itb. Multi-block PIO reads work in the SPL.
3. A failed probe releases the clock and reset bulks, whose first
entries are the SDH AXI clock and reset shared by all three
controllers. One controller failing then hangs the next access to
another. Patch 1 removes the trigger I hit, but the error path
should not stop the other controllers either way.
Tested on an OrangePi RV2 (upstream k1-orangepi-rv2.dts plus a board
-u-boot.dtsi and defconfig I will post separately): SPL boot from
microSD with multi-block reads, both SDHCI controllers probing in
U-Boot proper, and an EFI boot of FreeBSD from there. Before patch 3,
with the RV2's eMMC node lacking max-frequency, U-Boot hung at "MMC:".
On an OrangePi R2S booting from eMMC, the io clock change in probe
only takes effect with "clk: spacemit: ccu_mix: fix inverted condition
in ccu_mix_trigger_fc()" from the K3 clock series applied.
Dave Klotz (3):
mmc: k1: handle a missing max-frequency and clk_set_rate()'s return
value
mmc: k1: let the SPL read SD cards more than one block at a time
mmc: k1: do not release the shared AXI clock and reset on probe
failure
drivers/mmc/spacemit_sdhci.c | 45 ++++++++++++++++++++++--------------
1 file changed, 28 insertions(+), 17 deletions(-)
base-commit: a000f2af240eaa996cec92f8d44bad96fdf3f898
--
2.55.0
