sdhci-esdhc-imx -- MMC 10x slower than it should be
Pavel Machek
pma at sysgo.com
Wed Jun 15 05:40:01 EDT 2011
Hi!
We are seeing issues with sdhci-esdhc-imx in 2.6.39; performance is
not what it should be; it is about 10x lower in fact.
(
2.6.39 -mostly-vanilla:
dd if=/dev/mmcblk0 of=/dev/null bs=1024 count=10240
<7>sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x00000001
takes cca 17 seconds.
2.6.34 -with-freescale-patches:
dd if=/dev/mmcblk0 of=/dev/null bs=1024 count=10240
takes about 1 second.
)
I could not pinpoint why; I found following issues while debugging:
When the core asks for 52MHz, code seems to select 40MHz even when it
can do 48MHz. I was able to work around with this:
diff -u -r1.1 sdhci-esdhc.h
--- sdhci-esdhc.h 14 Jun 2011 13:04:27 -0000 1.1
+++ sdhci-esdhc.h 15 Jun 2011 08:28:25 -0000
@@ -59,10 +59,12 @@
while (host->max_clk / pre_div / 16 > clock && pre_div < 256)
pre_div *= 2;
+ pre_div /= 2;
+
while (host->max_clk / pre_div / div > clock && div < 16)
div++;
...but then it sometimes produces higher frequency then
requested. mx_sdhci driver does something way more complex here.
+++ sdhci-esdhc-imx.c 15 Jun 2011 08:28:25 -0000
@@ -164,11 +166,24 @@
*/
return;
case SDHCI_HOST_CONTROL:
/* FSL messed up here, so we can just keep those two */
new_val = val & (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);
...any idea what this comment means? I'd like to eventualy support
8BITBUS...
Part of the problem is that esdhc_writeb_le() does translation of bits
into breescale format; but readb() does not do translation back, and
core code uses read-modify-write on the register, for example when
turning on the LED. What to do there? Translate back? Add shadow
variable? Get rid of read-modify-write?
Any ideas why it is slow?
Pavel
More information about the linux-arm-kernel
mailing list