From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Date: Sat, 29 Aug 2015 13:55:36 +0200 Subject: [U-Boot] [PATCH 1/2] mmc: dw_mmc: Increase timeout to 20 seconds In-Reply-To: <201508282355.17660.marex@denx.de> References: <1440769821-24005-1-git-send-email-l.majewski@samsung.com> <201508282355.17660.marex@denx.de> Message-ID: <20150829135536.62b41b03@jawa> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, 28 Aug 2015 23:55:17 +0200 Marek Vasut wrote: > On Friday, August 28, 2015 at 03:50:20 PM, Lukasz Majewski wrote: > > The commit: d9dbb97be0e4a550457aec5f11afefb446169c90 > > "mmc: dw_mmc: Zap endless timeout" removed endless loop waiting for > > end of dw mmc transfer. > > > > For some workloads - dfu test @ Odroid XU3 (sending 8MiB file) - > > and SD cards (e.g. MicroSD Kingston 4GiB, Adata 4GiB) > > the default timeout is to short. > > > > The new value - 20 seconds - takes into account the situation when > > SD card triggers internal clean up. Such process may take more than > > 10 seconds on some cards. > > What happens if you pull the SD card out of the slot during such a > process? Then we would wait 20 seconds :-) to proceed. To be clear - the mentioned patch introduced regression. It works for small files on a commonly available SD cards (like 4 GiB Kingston/Adata). When I ran DFU tests I've discovered that there is a problem with storing 8MiB file (dat_8M.img). Even worse - when one wants to store Image.itb file (which might be 4-6 MiB) it sometimes works and sometimes not. Nightmare for debugging. Please correct me if I'm wrong - but is seems like we are now using 1 second timeout for detection if SD card has been removed? Shouldn't we use polling on the card detect IO pin instead? We could add such polling in several places in the MMC subsystem (like we do it with watchdog). Marek, Pantelis, what do you think about this? > > Also, where did you find out there is such "cleanup" mechanism > please ? Internally we did some tests with several SD cards. We were stunned when it turned out that for some workloads it took up to 15 seconds to end write operation for small data. The culprit is the SD Card embedded controller responsible for FTL - flash translation layer. It allows NAND memory on the card to be visible as the block device. More importantly it also takes care of wear leveling and bad block management. Hence, we don't know when it would start housekeeping operations. We can only poll/wait until this controller finishes it work. The code as it was (with the indefinite loop) was taking this situation into account. The 1 second timeout is apparently too short and makes using SD card non-deterministic and error prone in u-boot. Even worse, many devices use SD card as the only storage device. > > > Signed-off-by: Lukasz Majewski > > Cc: Marek Vasut > > Cc: Pantelis Antoniou > > Cc: Tom Rini > > --- > > drivers/mmc/dw_mmc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c > > index 77b87e0..21a92d2 100644 > > --- a/drivers/mmc/dw_mmc.c > > +++ b/drivers/mmc/dw_mmc.c > > @@ -213,7 +213,7 @@ static int dwmci_send_cmd(struct mmc *mmc, > > struct mmc_cmd *cmd, > > > > if (data) { > > start = get_timer(0); > > - timeout = 1000; > > + timeout = 20000; > > for (;;) { > > mask = dwmci_readl(host, DWMCI_RINTSTS); > > /* Error during data transfer. */ > > Best regards, > Marek Vasut Best regards, Lukasz Majewski -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: