Re: [MX25][MMC] mmc esdhc failure in 3.3
Interesting question is now why it worked on your older kernel? The codearound BROKEN_TIMEOUT is there for much longer, I'd think.not in fact it seems to have been broken from a long time and I think I'm responsible of that in 37865fe91582582a6f6c00652f6a2b1ff71f8a78 "mmc: sdhci-esdhc-imx: fix timeout on i.MX's sdhc" because unlike the i.MX35 it seems that the i.MX25 manages to read properly the partition table even without the timeout quirk and it seems that I didn't do more extensive tests for this patch.
Might be unrelated, however I have been keeping my eyes on the fix of ENGcm07207 quirk introduced with 16a790bcc. According to the IMX25CE.pdf, to abort data transfers on the AHB, software can reset the eSDHC by writing 1 to SYSCTL (RSTA), which currently is not done with SDHCI_QUIRK_NO_MULTIBLOCK. It sets the max_blk_count to 1 instead of 65535. Not sure if this is also limiting the speed.
I have tried putting the SD card into an ALL-in-One reader via USB and I get 6MB/s read and 15MB/s write performance. Since I didn't know the exact class of the card, this reassures me that there is nothing substantially wrong with the card per se.
So, how can we find a solution to this speed issue? Also, do you plan on submitting your patch to revert the timeout quirk for MX25?
Cheers -- Joan C. Abelaira _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[Linux ARM (vger)] [Linux ARM MSM] [Linux Omap] [Linux Arm] [Linux Tegra] [Fedora ARM] [eCos] [Linux Fastboot] [Gcc Help] [Git] [DCCP] [IETF Announce] [Security] [PDAs] [Linux] [Linux MIPS] [Yosemite Campsites] [Photos]