[U-Boot] [PATCH] OMAP MMC: Add delay before waiting for status
Loading kernel from MMC created the following error message reproducable:
| reading uImage | mmc_send_cmd: timedout waiting for stat! | | 2860468 bytes read
Tested on overo with OMAP3530: * OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz Die ID #470e000400000000040398d31402100c * OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz Die ID #112000040000000004035c140101b011
Signed-off-by: Andreas Müller schnitzeltony@gmx.de --- drivers/mmc/omap_hsmmc.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index c38b9e6..ac91e5d 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -197,6 +197,10 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, unsigned int flags, mmc_stat; ulong start;
+ /* Delay added before checking the status */ + if (cmd->cmdidx == MMC_CMD_SEND_STATUS) + udelay(1); /* wait 1 us */ + start = get_timer(0); while ((readl(&mmc_base->pstate) & DATI_MASK) == DATI_CMDDIS) { if (get_timer(0) - start > MAX_RETRY_MS) {
On Thu, Dec 22, 2011 at 2:56 AM, Andreas Müller schnitzeltony@gmx.de wrote:
Loading kernel from MMC created the following error message reproducable:
| reading uImage | mmc_send_cmd: timedout waiting for stat! | | 2860468 bytes read
Tested on overo with OMAP3530:
- OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
Die ID #470e000400000000040398d31402100c
- OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
Die ID #112000040000000004035c140101b011
Signed-off-by: Andreas Müller schnitzeltony@gmx.de
OK, I'm going to NAK this as-is. Over at https://lists.yoctoproject.org/pipermail/meta-ti/2012-January/000316.html Andreas has provided more details about what he saw (thread is about someone else who hit this problem on a beagleboard xM). I've done a bit more poking at the other MMC drivers and it seems that the "send the mmc command" function has anywhere from a 10ms timeout (sdhci.c) to 1ms (omap, fsl).
Now, digging more, I see that the kernel sets the mmc timeout to 20ms and has since the driver went in, so this is presumably a more safe value to use. I've updated the code to use that, have a more clear comment and name (and some related cleanup) and I've sent some test binaries to someone internally that's reported the problem. I'll post a patch and cc Andreas and Peter and see if this change also fixes the problem (it really should, but lets be safe).
Thanks folks!
participants (2)
-
Andreas Müller -
Tom Rini