summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq
diff options
context:
space:
mode:
authorMichael Walle <michael@walle.cc>2020-10-23 00:23:37 +0200
committerUlf Hansson <ulf.hansson@linaro.org>2020-10-23 14:16:47 +0200
commit0add6e9b88d0632a25323aaf4987dbacb0e4ae64 (patch)
tree8957740063bdf54296dfc5fa30f52039d9e59fb2 /drivers/cpufreq
parentb3e1ea16fb39fb6e1a1cf1dbdd6738531de3dc7d (diff)
mmc: sdhci-of-esdhc: set timeout to max before tuning
On rare occations there is the following error: mmc0: Tuning timeout, falling back to fixed sampling clock There are SD cards which takes a significant longer time to reply to the first CMD19 command. The eSDHC takes the data timeout value into account during the tuning period. The SDHCI core doesn't explicitly set this timeout for the tuning procedure. Thus on the slow cards, there might be a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong sequence of events. In the end this will lead to an unsuccessful tuning procedure and to the above error. To workaround this, set the timeout to the maximum value (which is the best we can do) and the SDHCI core will take care of the proper timeout handling. Fixes: ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning support") Signed-off-by: Michael Walle <michael@walle.cc> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20201022222337.19857-1-michael@walle.cc Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Diffstat (limited to 'drivers/cpufreq')
0 files changed, 0 insertions, 0 deletions