summaryrefslogtreecommitdiff
path: root/drivers/mmc/omap_hsmmc.c
diff options
context:
space:
mode:
authorJean-Jacques Hiblot <jjhiblot@ti.com>2018-01-30 16:01:37 +0100
committerJaehoon Chung <jh80.chung@samsung.com>2018-02-19 16:58:54 +0900
commita4efd73773c792737dd8d1e9d18da7796418fc1f (patch)
tree0b95708c85429b59f902f501aabdcfb5cf155fb6 /drivers/mmc/omap_hsmmc.c
parent2faa1a302ba13ed65771d642eed126e458e41bf3 (diff)
mmc: omap_hsmmc: Reduce the max timeout for reset controller fsm
>From OMAP3 SoCs (OMAP3, OMAP4, OMAP5, AM572x, AM571x), the DAT/CMD lines reset procedure section in TRM suggests to first poll the SRD/SRC bit until it is set to 0x1. But looks like that bit is never set to 1 and there is an observable delay of 1sec everytime the driver tries to reset DAT/CMD. (The same is observed in linux kernel). Reduce the time the driver waits for the controller to set the SRC/SRD bits to 1 so that there is no observable delay. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
Diffstat (limited to 'drivers/mmc/omap_hsmmc.c')
-rw-r--r--drivers/mmc/omap_hsmmc.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 55232103e0..ab4a095233 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -108,6 +108,7 @@ struct omap_hsmmc_adma_desc {
/* If we fail after 1 second wait, something is really bad */
#define MAX_RETRY_MS 1000
+#define MMC_TIMEOUT_MS 20
/* DMA transfers can take a long time if a lot a data is transferred.
* The timeout must take in account the amount of data. Let's assume
@@ -598,7 +599,7 @@ static void mmc_reset_controller_fsm(struct hsmmc *mmc_base, u32 bit)
if (!(readl(&mmc_base->sysctl) & bit)) {
start = get_timer(0);
while (!(readl(&mmc_base->sysctl) & bit)) {
- if (get_timer(0) - start > MAX_RETRY_MS)
+ if (get_timer(0) - start > MMC_TIMEOUT_MS)
return;
}
}