Tested-by: Steve Rae <s...@broadcom.com> (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 <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.3Looking 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
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
