summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorAnton Vorontsov <avorontsov@ru.mvista.com>2009-07-29 15:04:16 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2009-07-29 19:10:36 -0700
commita9e58f25734e153b8c6516d904e2398fb8b0b23d (patch)
treeb58b2843370fb743a4877e5e40ee649533e361c4 /lib
parentcab8bd3410d448279e3bd0fbf96d31db0bf770fa (diff)
downloadlinux-3.10-a9e58f25734e153b8c6516d904e2398fb8b0b23d.tar.gz
linux-3.10-a9e58f25734e153b8c6516d904e2398fb8b0b23d.tar.bz2
linux-3.10-a9e58f25734e153b8c6516d904e2398fb8b0b23d.zip
sdhci: get rid of "frequency too high" flood when using eSDHC
Since commit 8dfd0374be84793360db7fff2e635d2cd3bbcb21 ("MMC core: limit minimum initialization frequency to 400kHz") MMC core checks for minimum frequency, and that causes following messages flood when using eSDHC controllers: ... mmc0: Minimum clock frequency too high for identification mode mmc0: Minimum clock frequency too high for identification mode ... The warnings are legitimate, since if we'd use 133 MHz clocks for standard SDHCI controllers, we'd not able to scale frequency down to 400 kHz. But eSDHC controllers have a non-standard SD clock management, so we can divide clock by 256 * 16, not just 256. This patch introduces get_min_clock() callback for sdhci core and implements it for sdhci-of driver, and thus fixes the issue. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Cc: Matt Fleming <matt@console-pimps.org> Cc: Ian Molton <ian@mnementh.co.uk> Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com> Cc: Pierre Ossman <drzeus@drzeus.cx> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'lib')
0 files changed, 0 insertions, 0 deletions