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 <eli.billa...@gmail.com>
> ---
> 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@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
