From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Rae Date: Fri, 4 Jul 2014 14:02:40 -0700 Subject: [U-Boot] [PATCH] mmc: sdhci: Fixed timeout for sdhci_send_command() In-Reply-To: References: <1402566069-8061-1-git-send-email-eli.billauer@gmail.com> <1402566069-8061-2-git-send-email-eli.billauer@gmail.com> Message-ID: <53B71670.5050600@broadcom.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Tested-by: Steve Rae (does resolve the issue on our board!) On 14-06-27 02:37 AM, Pantelis Antoniou wrote: > Hi Eli, > > On Jun 12, 2014, at 12:41 PM, Eli Billauer wrote: > >> The current wait loop just reads the status 10000 times, which makes the >> actual timeout period platform-dependent. The udelay() call within the loop >> makes the new timeout ~100 ms. >> >> Signed-off-by: Eli Billauer >> --- >> drivers/mmc/sdhci.c | 1 + >> 1 files changed, 1 insertions(+), 0 deletions(-) >> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c >> index 3125d13..80f3a91 100644 >> --- a/drivers/mmc/sdhci.c >> +++ b/drivers/mmc/sdhci.c >> @@ -226,6 +226,7 @@ int sdhci_send_command(struct mmc *mmc, struct mmc_cmd *cmd, >> break; >> if (--retry == 0) >> break; >> + udelay(10); >> } while ((stat & mask) != mask); >> >> if (retry == 0) { >> -- >> 1.7.2.3 > > Looking at the linux sources is no good, cause linux is interrupt driven. > This delay is used because the driver is not interrupt driven, so you have > to wait until the interrupt indication is delivered. > > The only reference to interrupt latency I found is related to tuning and is > set to 50ms which I supposed is very pessimistic. > I think a timeout of 100ms would be fine. > > Regards > > -- Pantelis > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >