forked from robimarko/openwrt
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
uboot-mvebu: backport patch to fix eMMC
v2022.01 has a regression that broke eMMC usage on most if not all Armada SoC-s, thus breaking boards like uDPU which use eMMC for storage. Fix it by backporting a recent upstream patch. Fixes: 782d4c8 ("uboot-mvebu: update to version 2022.01") Signed-off-by: Robert Marko <robert.marko@sartura.hr>
- Loading branch information
Showing
1 changed file
with
64 additions
and
0 deletions.
There are no files selected for viewing
64 changes: 64 additions & 0 deletions
64
package/boot/uboot-mvebu/patches/013-mmc-xenon_sdhci-remove-wait_dat0-SDHCI-OP.patch
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
From 0f3466f52fbacce67e147b9234e6323edff26a6d Mon Sep 17 00:00:00 2001 | ||
From: Robert Marko <robert.marko@sartura.hr> | ||
Date: Fri, 11 Mar 2022 19:14:07 +0100 | ||
Subject: [PATCH] mmc: xenon_sdhci: remove wait_dat0 SDHCI OP | ||
MIME-Version: 1.0 | ||
Content-Type: text/plain; charset=UTF-8 | ||
Content-Transfer-Encoding: 8bit | ||
|
||
Generic SDHCI driver received support for checking the busy status by | ||
polling the DAT[0] level instead of waiting for the worst MMC switch time. | ||
|
||
Unfortunately, it appears that this does not work for Xenon controllers | ||
despite being a part of the standard SDHCI registers and the Armada 3720 | ||
datasheet itself telling that BIT(20) is useful for detecting the DAT[0] | ||
busy signal. | ||
|
||
I have tried increasing the timeout value, but I have newer managed to | ||
catch DAT_LEVEL bits change from 0 at all. | ||
|
||
This issue appears to hit most if not all SoC-s supported by Xenon driver, | ||
at least A3720, A8040 and CN9130 have non working eMMC currently. | ||
|
||
So, until a better solution is found drop the wait_dat0 OP for Xenon. | ||
I was able to only test it on A3720, but it should work for others as well. | ||
|
||
Fixes: 40e6f52454fc ("drivers: mmc: Add wait_dat0 support for sdhci driver") | ||
Signed-off-by: Robert Marko <robert.marko@sartura.hr> | ||
Reviewed-by: Marek Behún <marek.behun@nic.cz> | ||
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> | ||
Reviewed-by: Stefan Roese <sr@denx.de> | ||
--- | ||
drivers/mmc/xenon_sdhci.c | 7 ++++++- | ||
1 file changed, 6 insertions(+), 1 deletion(-) | ||
|
||
--- a/drivers/mmc/xenon_sdhci.c | ||
+++ b/drivers/mmc/xenon_sdhci.c | ||
@@ -439,6 +439,8 @@ static const struct sdhci_ops xenon_sdhc | ||
.set_ios_post = xenon_sdhci_set_ios_post | ||
}; | ||
|
||
+static struct dm_mmc_ops xenon_mmc_ops; | ||
+ | ||
static int xenon_sdhci_probe(struct udevice *dev) | ||
{ | ||
struct xenon_sdhci_plat *plat = dev_get_plat(dev); | ||
@@ -452,6 +454,9 @@ static int xenon_sdhci_probe(struct udev | ||
host->mmc->dev = dev; | ||
upriv->mmc = host->mmc; | ||
|
||
+ xenon_mmc_ops = sdhci_ops; | ||
+ xenon_mmc_ops.wait_dat0 = NULL; | ||
+ | ||
/* Set quirks */ | ||
host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_32BIT_DMA_ADDR; | ||
|
||
@@ -568,7 +573,7 @@ U_BOOT_DRIVER(xenon_sdhci_drv) = { | ||
.id = UCLASS_MMC, | ||
.of_match = xenon_sdhci_ids, | ||
.of_to_plat = xenon_sdhci_of_to_plat, | ||
- .ops = &sdhci_ops, | ||
+ .ops = &xenon_mmc_ops, | ||
.bind = xenon_sdhci_bind, | ||
.probe = xenon_sdhci_probe, | ||
.remove = xenon_sdhci_remove, |