[U-Boot] [PATCH] mmc: sdhci: Fixed timeout for sdhci_send_command()

[Andy Fleming <afleming@gmail.com>]

On Fri, Jun 27, 2014 at 4:37 AM, Pantelis Antoniou <
pantelis.antoniou@gmail.com> 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 <eli.billauer@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.
>
>
I suspect the timeout of 100ms is fine (though it's always nice when we tie
such numbers to something more concrete than: "it works if I make it wait
longer"). My main point was that this actually *adds* 100ms to the
preexisting timeout, instead of making the timeout ~100ms. If we reduced
the number of checks and increased the delay, the delay would completely
dominate the timeout loop, and total time would become closer to ~100ms.

Andy