Hi Ulf, On Mon, Jan 13, 2014 at 9:01 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 17 December 2013 09:16, Dong Aisheng <b29396@xxxxxxxxxxxxx> wrote: >> Patch 1~4 mainly fixes the issue that the max timeout counter for uSDHC is >> 1 << 28 rather than 1 << 27. 1~2 fix getting the max timeout counter >> while 3~4 fix setting the max timeout. >> Thus it introduces two new platform hook: get_max_timeout_count and set_timeout >> for those platform which have different timeout setting. >> >> This issue is firstly reported here by Ed Sutter: >> http://www.spinics.net/lists/linux-mmc/msg23375.html >> The root cause is the max_discard_to got from uSDHC is too small, only 677ms, >> which cause the max_discard_bytes for eMMC is only 512, then the discard operation >> of mkfs.ext3 for an eMMC card is too slow, just like dead. >> With above patches, the issue can be fixed. >> >> Patch 5 adds the capability to calcalute the max_discard_to dynamically >> for SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK. >> >> Originally the max_discard_to for a high speed sdhc card may be: >> mmc1: new high speed SDHC card at address aaaa >> mmc1: calculated max. discard sectors 49152 for timeout 1355 ms >> After fix: >> mmc1: new high speed SDHC card at address aaaa >> mmc1: calculated max. discard sectors 712704 for timeout 5422 ms >> >> It also improves the card discard performance a lot due to max_discard_sectors >> increase a lot. >> >> There's also discussion about remove max_discard_to limit here: >> http://www.spinics.net/lists/linux-mmc/msg23395.html >> But it does not help for uSDHC since we can observe data timeout >> on a Toshiba SD3.0 cards if we do not disable data timeout interrupt. > > Just some more input to this discussion. > > As you probably know, I am working on a solution which in principle > means we will fall back to use R1 responses instead of R1B. > Particularly in those cases were the host driver supports > MMC_CAP_WAIT_WHILE_BUSY and when it can't support the requested busy > detection timeout. In other words, we will fall back to use poll with > CMD13 instead, which is what happens already for those not supporting > MMC_CAP_WAIT_WHILE_BUSY. > Will be glad to see your patches for that feature. This patch series is intend to fix different issues, it does not depend on your work. Patch 1~4 is totally for fixing imx timeout issues. Patch 5 is to add the capability to calcalute the max_discard_to dynamically. This is also a fix of calculating max_discard_to for controllers using SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK. It's especially useful for controllers using hw timeout with big timeout capability. They should be needed no matter whether polling way is used or not. Regards Dong Aisheng > Kind regards > Ulf Hansson > >> >> ChangeLog: >> v1->v2: >> 1. change .get_max_timeout to .get_max_timeout_count to reuse some code >> 2. some other minor changes based on Shawn's comment. >> 3. patch 6 in v1 is dropped since not need anymore after change 1 >> >> >> >> Dong Aisheng (5): >> mmc: sdhci: add platfrom get_max_timeout_count hook >> mmc: sdhci-esdhc-imx: fix incorrect max_discard_to for uSDHC >> mmc: sdhci: add platform set_timeout hook >> mmc: sdhci-esdhc-imx: set the correct max timeout value for uSDHC >> mmc: sdhci: calculate max_discard_to dynamically for >> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK >> >> drivers/mmc/host/sdhci-esdhc-imx.c | 20 +++++++++++ >> drivers/mmc/host/sdhci.c | 66 +++++++++++++++++++++++------------ >> drivers/mmc/host/sdhci.h | 3 ++ >> 3 files changed, 66 insertions(+), 23 deletions(-) >> >> -- >> 1.7.2.rc3 >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
