* [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
@ 2020-10-15 23:11 Michael Walle
2020-10-16 8:45 ` Adrian Hunter
2020-10-16 10:53 ` Ulf Hansson
0 siblings, 2 replies; 6+ messages in thread
From: Michael Walle @ 2020-10-15 23:11 UTC (permalink / raw)
To: linux-mmc, linux-kernel
Cc: Yangbo Lu, Adrian Hunter, Ulf Hansson, Michael Walle
On rare occations there is the following error:
mmc0: Tuning timeout, falling back to fixed sampling clock
There are SD cards which takes a significant longer time to reply to the
first CMD19 command. The eSDHC takes the data timeout value into account
during the tuning period. The SDHCI core doesn't explicitly set this
timeout for the tuning procedure. Thus on the slow cards, there might be
a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
sequence of events. In the end this will lead to an unsuccessful tuning
procedure and to the above error.
To workaround this, set the timeout to the maximum value (which is the
best we can do) and the SDHCI core will take care of the proper timeout
handling.
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/mmc/host/sdhci-of-esdhc.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
index 0b45eff6fed4..baf7801a1804 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -1052,6 +1052,17 @@ static int esdhc_execute_tuning(struct mmc_host *mmc, u32 opcode)
esdhc_tuning_block_enable(host, true);
+ /*
+ * The eSDHC controller takes the data timeout value into account
+ * during tuning. If the SD card is too slow sending the response, the
+ * timer will expire and a "Buffer Read Ready" interrupt without data
+ * is triggered. This leads to tuning errors.
+ *
+ * Just set the timeout to the maximum value because the core will
+ * already take care of it in sdhci_send_tuning().
+ */
+ sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
+
hs400_tuning = host->flags & SDHCI_HS400_TUNING;
do {
--
2.20.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
2020-10-15 23:11 [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning Michael Walle
@ 2020-10-16 8:45 ` Adrian Hunter
2020-10-16 10:53 ` Ulf Hansson
1 sibling, 0 replies; 6+ messages in thread
From: Adrian Hunter @ 2020-10-16 8:45 UTC (permalink / raw)
To: Michael Walle, linux-mmc, linux-kernel; +Cc: Yangbo Lu, Ulf Hansson
On 16/10/20 2:11 am, Michael Walle wrote:
> On rare occations there is the following error:
>
> mmc0: Tuning timeout, falling back to fixed sampling clock
>
> There are SD cards which takes a significant longer time to reply to the
> first CMD19 command. The eSDHC takes the data timeout value into account
> during the tuning period. The SDHCI core doesn't explicitly set this
> timeout for the tuning procedure. Thus on the slow cards, there might be
> a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
> sequence of events. In the end this will lead to an unsuccessful tuning
> procedure and to the above error.
>
> To workaround this, set the timeout to the maximum value (which is the
> best we can do) and the SDHCI core will take care of the proper timeout
> handling.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index 0b45eff6fed4..baf7801a1804 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1052,6 +1052,17 @@ static int esdhc_execute_tuning(struct mmc_host *mmc, u32 opcode)
>
> esdhc_tuning_block_enable(host, true);
>
> + /*
> + * The eSDHC controller takes the data timeout value into account
> + * during tuning. If the SD card is too slow sending the response, the
> + * timer will expire and a "Buffer Read Ready" interrupt without data
> + * is triggered. This leads to tuning errors.
> + *
> + * Just set the timeout to the maximum value because the core will
> + * already take care of it in sdhci_send_tuning().
> + */
> + sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
> +
> hs400_tuning = host->flags & SDHCI_HS400_TUNING;
>
> do {
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
2020-10-15 23:11 [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning Michael Walle
2020-10-16 8:45 ` Adrian Hunter
@ 2020-10-16 10:53 ` Ulf Hansson
2020-10-16 12:50 ` Michael Walle
1 sibling, 1 reply; 6+ messages in thread
From: Ulf Hansson @ 2020-10-16 10:53 UTC (permalink / raw)
To: Michael Walle
Cc: linux-mmc, Linux Kernel Mailing List, Yangbo Lu, Adrian Hunter
On Fri, 16 Oct 2020 at 01:12, Michael Walle <michael@walle.cc> wrote:
>
> On rare occations there is the following error:
>
> mmc0: Tuning timeout, falling back to fixed sampling clock
>
> There are SD cards which takes a significant longer time to reply to the
> first CMD19 command. The eSDHC takes the data timeout value into account
> during the tuning period. The SDHCI core doesn't explicitly set this
> timeout for the tuning procedure. Thus on the slow cards, there might be
> a spurious "Buffer Read Ready" interrupt, which in turn triggers a wrong
> sequence of events. In the end this will lead to an unsuccessful tuning
> procedure and to the above error.
>
> To workaround this, set the timeout to the maximum value (which is the
> best we can do) and the SDHCI core will take care of the proper timeout
> handling.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
Sound like this should be tagged for stable, right?
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index 0b45eff6fed4..baf7801a1804 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1052,6 +1052,17 @@ static int esdhc_execute_tuning(struct mmc_host *mmc, u32 opcode)
>
> esdhc_tuning_block_enable(host, true);
>
> + /*
> + * The eSDHC controller takes the data timeout value into account
> + * during tuning. If the SD card is too slow sending the response, the
> + * timer will expire and a "Buffer Read Ready" interrupt without data
> + * is triggered. This leads to tuning errors.
> + *
> + * Just set the timeout to the maximum value because the core will
> + * already take care of it in sdhci_send_tuning().
> + */
> + sdhci_writeb(host, 0xe, SDHCI_TIMEOUT_CONTROL);
> +
> hs400_tuning = host->flags & SDHCI_HS400_TUNING;
>
> do {
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
2020-10-16 10:53 ` Ulf Hansson
@ 2020-10-16 12:50 ` Michael Walle
2020-10-21 15:04 ` Ulf Hansson
0 siblings, 1 reply; 6+ messages in thread
From: Michael Walle @ 2020-10-16 12:50 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Linux Kernel Mailing List, Yangbo Lu, Adrian Hunter
Am 2020-10-16 12:53, schrieb Ulf Hansson:
> On Fri, 16 Oct 2020 at 01:12, Michael Walle <michael@walle.cc> wrote:
>>
>> On rare occations there is the following error:
>>
>> mmc0: Tuning timeout, falling back to fixed sampling clock
>>
>> There are SD cards which takes a significant longer time to reply to
>> the
>> first CMD19 command. The eSDHC takes the data timeout value into
>> account
>> during the tuning period. The SDHCI core doesn't explicitly set this
>> timeout for the tuning procedure. Thus on the slow cards, there might
>> be
>> a spurious "Buffer Read Ready" interrupt, which in turn triggers a
>> wrong
>> sequence of events. In the end this will lead to an unsuccessful
>> tuning
>> procedure and to the above error.
>>
>> To workaround this, set the timeout to the maximum value (which is the
>> best we can do) and the SDHCI core will take care of the proper
>> timeout
>> handling.
>>
>> Signed-off-by: Michael Walle <michael@walle.cc>
>
> Sound like this should be tagged for stable, right?
Yes, but I was unsure about that. I didn't find a lot of Fixes: tags in
the history of this driver (eg. for errata etc.)
I could repost a v2 with a fixes tag if you like.
-michael
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
2020-10-16 12:50 ` Michael Walle
@ 2020-10-21 15:04 ` Ulf Hansson
2020-10-21 17:29 ` Michael Walle
0 siblings, 1 reply; 6+ messages in thread
From: Ulf Hansson @ 2020-10-21 15:04 UTC (permalink / raw)
To: Michael Walle
Cc: linux-mmc, Linux Kernel Mailing List, Yangbo Lu, Adrian Hunter
On Fri, 16 Oct 2020 at 14:50, Michael Walle <michael@walle.cc> wrote:
>
> Am 2020-10-16 12:53, schrieb Ulf Hansson:
> > On Fri, 16 Oct 2020 at 01:12, Michael Walle <michael@walle.cc> wrote:
> >>
> >> On rare occations there is the following error:
> >>
> >> mmc0: Tuning timeout, falling back to fixed sampling clock
> >>
> >> There are SD cards which takes a significant longer time to reply to
> >> the
> >> first CMD19 command. The eSDHC takes the data timeout value into
> >> account
> >> during the tuning period. The SDHCI core doesn't explicitly set this
> >> timeout for the tuning procedure. Thus on the slow cards, there might
> >> be
> >> a spurious "Buffer Read Ready" interrupt, which in turn triggers a
> >> wrong
> >> sequence of events. In the end this will lead to an unsuccessful
> >> tuning
> >> procedure and to the above error.
> >>
> >> To workaround this, set the timeout to the maximum value (which is the
> >> best we can do) and the SDHCI core will take care of the proper
> >> timeout
> >> handling.
> >>
> >> Signed-off-by: Michael Walle <michael@walle.cc>
> >
> > Sound like this should be tagged for stable, right?
>
> Yes, but I was unsure about that. I didn't find a lot of Fixes: tags in
> the history of this driver (eg. for errata etc.)
>
> I could repost a v2 with a fixes tag if you like.
If this is regression and you can point to a specific commit it fixes,
then please yes!
Kind regards
Uffe
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning
2020-10-21 15:04 ` Ulf Hansson
@ 2020-10-21 17:29 ` Michael Walle
0 siblings, 0 replies; 6+ messages in thread
From: Michael Walle @ 2020-10-21 17:29 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-mmc, Linux Kernel Mailing List, Yangbo Lu, Adrian Hunter
Am 2020-10-21 17:04, schrieb Ulf Hansson:
> On Fri, 16 Oct 2020 at 14:50, Michael Walle <michael@walle.cc> wrote:
>>
>> Am 2020-10-16 12:53, schrieb Ulf Hansson:
>> > On Fri, 16 Oct 2020 at 01:12, Michael Walle <michael@walle.cc> wrote:
>> >>
>> >> On rare occations there is the following error:
>> >>
>> >> mmc0: Tuning timeout, falling back to fixed sampling clock
>> >>
>> >> There are SD cards which takes a significant longer time to reply to
>> >> the
>> >> first CMD19 command. The eSDHC takes the data timeout value into
>> >> account
>> >> during the tuning period. The SDHCI core doesn't explicitly set this
>> >> timeout for the tuning procedure. Thus on the slow cards, there might
>> >> be
>> >> a spurious "Buffer Read Ready" interrupt, which in turn triggers a
>> >> wrong
>> >> sequence of events. In the end this will lead to an unsuccessful
>> >> tuning
>> >> procedure and to the above error.
>> >>
>> >> To workaround this, set the timeout to the maximum value (which is the
>> >> best we can do) and the SDHCI core will take care of the proper
>> >> timeout
>> >> handling.
>> >>
>> >> Signed-off-by: Michael Walle <michael@walle.cc>
>> >
>> > Sound like this should be tagged for stable, right?
>>
>> Yes, but I was unsure about that. I didn't find a lot of Fixes: tags
>> in
>> the history of this driver (eg. for errata etc.)
>>
>> I could repost a v2 with a fixes tag if you like.
>
> If this is regression and you can point to a specific commit it fixes,
> then please yes!
That would be commit ba49cbd0936e ("mmc: sdhci-of-esdhc: add tuning
support"). But as of today it isn't much left of that original code.
So I don't know if adding that fixes tag will help a lot. Correct me
if I'm wrong.
-michael
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-10-21 17:29 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-15 23:11 [PATCH] mmc: sdhci-of-esdhc: set timeout to max before tuning Michael Walle
2020-10-16 8:45 ` Adrian Hunter
2020-10-16 10:53 ` Ulf Hansson
2020-10-16 12:50 ` Michael Walle
2020-10-21 15:04 ` Ulf Hansson
2020-10-21 17:29 ` Michael Walle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.