[PATCH v2 0/5] mmc: sdhci: a few fixes on timeout and max_discard_to

[Dong Aisheng]

Hi Ulf,

On Mon, Jan 13, 2014 at 9:01 PM, Ulf Hansson <ulf.hansson at linaro.org> wrote:
> On 17 December 2013 09:16, Dong Aisheng <b29396 at freescale.com> 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 at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel