[RFC PATCH 0/2] mmc: k1: do not require max-frequency in the device tree

[RFC PATCH 0/2] mmc: k1: do not require max-frequency in the device tree

[Hung-Chun Tseng]

The K1 SDHCI driver sets the io clock to cfg.f_max, which is only
filled in from a "max-frequency" property, so each K1 board carries
max-frequency = <204800000> for the SD and eMMC nodes in its
-u-boot.dtsi. E Shattow pointed out that this property is unlikely to
be accepted in the upstream device tree and looks like a driver issue
[1]. The Linux driver indeed does not need it: it reports the current
io clock rate as the maximum.

Patch 1 makes the U-Boot driver do the same when max-frequency is
absent. Patch 2 drops the property from the BPI-F3 and MusePi Pro
overlays.

This is an RFC because I could only build-test it: spacemit_k1_defconfig
builds (SPL and u-boot.itb), and the resulting BPI-F3 and MusePi Pro
DTBs no longer carry max-frequency on the MMC nodes. I have not run it
on hardware. The open question is what rate the io clock runs at when
SPL and U-Boot probe the controllers: if the BootROM or SPL leaves it
well below 204.8 MHz, SD and eMMC will still work but run slower, and
the driver may need a default rate instead of the current one. A test
on a BPI-F3 or MusePi Pro, or a pointer to the expected clock setup,
would be very welcome.

[1] https://lore.kernel.org/u-boot/5d323a11-da4e-4071-bdeb-ab5c03e8f85e@freeshell.de/

Hung-Chun Tseng (2):
  mmc: k1: use the io clock rate when max-frequency is absent
  riscv: dts: k1: drop max-frequency from the SD and eMMC nodes

 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi |  2 --
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 --
 drivers/mmc/spacemit_sdhci.c              | 24 +++++++++++++++++++----
 3 files changed, 20 insertions(+), 8 deletions(-)

-- 
2.43.0

[RFC PATCH 1/2] mmc: k1: use the io clock rate when max-frequency is absent

[Hung-Chun Tseng]

The driver sets the io clock to cfg.f_max, which mmc_of_parse() only
fills in from the "max-frequency" property. The compatible has no
driver data, so without that property f_max is 0 and probe asks the
clock framework for a rate of 0. Every K1 board therefore needs a
max-frequency override in its -u-boot.dtsi, and the property cannot go
into the upstream device tree because the Linux driver does not need
it: sdhci-of-k1.c reports clk_get_rate() of the io clock as the
maximum.

Do the same here. Keep setting the rate when max-frequency is present,
and otherwise use the rate the io clock already runs at.

Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
---
 drivers/mmc/spacemit_sdhci.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/spacemit_sdhci.c b/drivers/mmc/spacemit_sdhci.c
index f5578f38b..9b22ae48a 100644
--- a/drivers/mmc/spacemit_sdhci.c
+++ b/drivers/mmc/spacemit_sdhci.c
@@ -606,10 +606,26 @@ static int spacemit_sdhci_probe(struct udevice *dev)
 		goto err_reset;
 	}
 
-	ret = clk_set_rate(&clk, plat->cfg.f_max);
-	if (ret) {
-		log_err("Failed to set io clk: %d\n", ret);
-		goto err_reset;
+	/*
+	 * Without a "max-frequency" property, use the io clock at the rate
+	 * it already runs at, as the Linux driver does, rather than asking
+	 * for a rate of 0.
+	 */
+	if (plat->cfg.f_max) {
+		ret = clk_set_rate(&clk, plat->cfg.f_max);
+		if (ret) {
+			log_err("Failed to set io clk: %d\n", ret);
+			goto err_reset;
+		}
+	} else {
+		ulong rate = clk_get_rate(&clk);
+
+		if (!rate || IS_ERR_VALUE(rate)) {
+			log_err("Failed to get io clk rate: %ld\n", (long)rate);
+			ret = rate ? (int)rate : -EINVAL;
+			goto err_reset;
+		}
+		plat->cfg.f_max = rate;
 	}
 
 	/* Set quirks */
-- 
2.43.0

[RFC PATCH 2/2] riscv: dts: k1: drop max-frequency from the SD and eMMC nodes

[Hung-Chun Tseng]

The K1 SDHCI driver now falls back to the io clock rate when
max-frequency is absent, so the BPI-F3 and MusePi Pro overlays no
longer need to carry it.

Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
---
 arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi | 2 --
 arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  | 2 --
 2 files changed, 4 deletions(-)

diff --git a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
index 3077cdee5..fbbf1fb81 100644
--- a/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
+++ b/arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi
@@ -89,12 +89,10 @@
 
 &emmc {
 	bootph-pre-ram;
-	max-frequency = <204800000>;
 };
 
 &sdhci0 {
 	bootph-pre-ram;
-	max-frequency = <204800000>;
 };
 
 &binman {
diff --git a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
index d6299c969..cb0560c14 100644
--- a/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
+++ b/arch/riscv/dts/k1-musepi-pro-u-boot.dtsi
@@ -126,13 +126,11 @@
 
 &emmc {
 	bootph-pre-ram;
-	max-frequency = <204800000>;
 };
 
 &sdhci0 {
 	bootph-pre-ram;
 	cd-gpios = <&gpio K1_GPIO(80) (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
-	max-frequency = <204800000>;
 };
 
 &binman {
-- 
2.43.0

Re: [RFC PATCH 0/2] mmc: k1: do not require max-frequency in the device tree

[Yixun Lan]

Hi Hung-Chun,

On 16:44 Tue 13 Oct     , Hung-Chun Tseng wrote:
> The K1 SDHCI driver sets the io clock to cfg.f_max, which is only
> filled in from a "max-frequency" property, so each K1 board carries
> max-frequency = <204800000> for the SD and eMMC nodes in its
> -u-boot.dtsi. E Shattow pointed out that this property is unlikely to
> be accepted in the upstream device tree and looks like a driver issue
> [1]. The Linux driver indeed does not need it: it reports the current
> io clock rate as the maximum.
> 
> Patch 1 makes the U-Boot driver do the same when max-frequency is
> absent. Patch 2 drops the property from the BPI-F3 and MusePi Pro
> overlays.
> 
> This is an RFC because I could only build-test it: spacemit_k1_defconfig
> builds (SPL and u-boot.itb), and the resulting BPI-F3 and MusePi Pro
> DTBs no longer carry max-frequency on the MMC nodes. I have not run it
> on hardware. The open question is what rate the io clock runs at when
> SPL and U-Boot probe the controllers: if the BootROM or SPL leaves it
> well below 204.8 MHz, SD and eMMC will still work but run slower, and
> the driver may need a default rate instead of the current one. A test
> on a BPI-F3 or MusePi Pro, or a pointer to the expected clock setup,
> would be very welcome.
> 
> [1] https://lore.kernel.org/u-boot/5d323a11-da4e-4071-bdeb-ab5c03e8f85e@freeshell.de/
> 
Please do not start a new thread, as there is already one discussion, see
https://lore.kernel.org/all/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/

> Hung-Chun Tseng (2):
>   mmc: k1: use the io clock rate when max-frequency is absent
>   riscv: dts: k1: drop max-frequency from the SD and eMMC nodes
> 
>  arch/riscv/dts/k1-bananapi-f3-u-boot.dtsi |  2 --
>  arch/riscv/dts/k1-musepi-pro-u-boot.dtsi  |  2 --
>  drivers/mmc/spacemit_sdhci.c              | 24 +++++++++++++++++++----
>  3 files changed, 20 insertions(+), 8 deletions(-)
> 
> -- 
> 2.43.0
> 

-- 
Yixun Lan (dlan)

Re: [RFC PATCH 1/2] mmc: k1: use the io clock rate when max-frequency is absent

[Tanmay Kathpalia]

On 10/13/26 14:14, Hung-Chun Tseng wrote:
> The driver sets the io clock to cfg.f_max, which mmc_of_parse() only
> fills in from the "max-frequency" property. The compatible has no
> driver data, so without that property f_max is 0 and probe asks the
> clock framework for a rate of 0. Every K1 board therefore needs a
> max-frequency override in its -u-boot.dtsi, and the property cannot go
> into the upstream device tree because the Linux driver does not need
> it: sdhci-of-k1.c reports clk_get_rate() of the io clock as the
> maximum.
>
> Do the same here. Keep setting the rate when max-frequency is present,
> and otherwise use the rate the io clock already runs at.
>
> Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>

Similar changes are already under review in Dave's patch. I'd suggest
taking a look at it before proceeding:
https://patchwork.ozlabs.org/project/uboot/patch/20261005T135220-0400.mmc-v2-0001.DaveWK225@protonmail.com/