| Message ID | 1280587518-2097-1-git-send-email-fransmeulenbroeks@gmail.com |
|---|---|
| State | Rejected, archived |
| Headers | show |
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index a368fe6..f982a69 100644 --- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -208,7 +208,7 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data) /* Calculate the timeout period for data transactions */ timeout = fls(mmc->tran_speed/10) - 1; - timeout -= 13; + timeout -= 11; if (timeout > 14) timeout = 14;
some boards have problems reading from flash because the timeout is too strict. e.g. mpc8536ds had problems reading 2gb sandisk sd cl2 cards as well as 4gb transcend cl6 sdhc cards The odd thing was that a sector that sometimes could be read would not be read the next time. And the cards operate smoothly from within linux. Definitely an indication that the timeout is too strict. After increasing the timeout both cards worked like a charm. As a somewhat too large timeout does not hurt (as it is normally not reached anyway) I've reduced the timeout by changing the subtracted value from 13 to 11. Seems to work fine with me (but we could consider forgetting about tuning the value and always write 14 << 16 in the timeout register (the max timeout value). Rmember that this timeout is only used up in case of an error, so it does not delay the normal operation. Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> --- BTW: it might be that this patch crept in at this commit: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=c67bee1460a0da89ef08cbc28375171acc9a4227 This one introduced a -1 in the calculation: - timeout = __ilog2(mmc->tran_speed/10); + timeout = fls(mmc->tran_speed/10) - 1; drivers/mmc/fsl_esdhc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)