* [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata
@ 2018-03-27 9:29 Masahiro Yamada
2018-04-04 7:35 ` Ulf Hansson
0 siblings, 1 reply; 5+ messages in thread
From: Masahiro Yamada @ 2018-03-27 9:29 UTC (permalink / raw
To: linux-mmc
Cc: Piotr Sroka, Masahiro Yamada, linux-kernel, Adrian Hunter,
Ulf Hansson
Cadence sent out an errata report to their customers of this IP.
This errata is not so severe, but the tune request should be sent
twice to avoid the potential issue.
Quote from the report:
Problem Summary
---------------
The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
This issue may lead to an incorrect values of read/write pointers of
the synchronization FIFO. Such a situation can happen at the SDR104
and HS200 tuning procedure when the PHY is requested to change a phase
of sampling clock when moving to the next tuning iteration.
Workarounds
-----------
The following are valid workarounds to resolve the issue:
1. In eMMC mode, software sends tune request twice instead of once at
each iteration. This means that the clock phase is not changed on
the second request so there is no potential for clock instability.
2. In SD mode, software must not use the hardware tuning and instead
perform an almost identical procedure to eMMC, using the HRS34 Tune
Force register.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mmc/host/sdhci-cadence.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
index 0f589e2..bc30d16 100644
--- a/drivers/mmc/host/sdhci-cadence.c
+++ b/drivers/mmc/host/sdhci-cadence.c
@@ -253,6 +253,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS06;
u32 tmp;
+ int i, ret;
if (WARN_ON(!FIELD_FIT(SDHCI_CDNS_HRS06_TUNE, val)))
return -EINVAL;
@@ -260,11 +261,24 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
tmp = readl(reg);
tmp &= ~SDHCI_CDNS_HRS06_TUNE;
tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_TUNE, val);
- tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
- writel(tmp, reg);
- return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
- 0, 1);
+ /*
+ * Workaround for IP errata:
+ * The IP6116 SD/eMMC PHY design has a timing issue on receive data
+ * path. Send tune request twice.
+ */
+ for (i = 0; i < 2; i++) {
+ tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
+ writel(tmp, reg);
+
+ ret = readl_poll_timeout(reg, tmp,
+ !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
+ 0, 1);
+
+ return ret;
+ }
+
+ return 0;
}
static int sdhci_cdns_execute_tuning(struct mmc_host *mmc, u32 opcode)
--
2.7.4
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata
2018-03-27 9:29 [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata Masahiro Yamada
@ 2018-04-04 7:35 ` Ulf Hansson
2018-04-04 9:05 ` Masahiro Yamada
0 siblings, 1 reply; 5+ messages in thread
From: Ulf Hansson @ 2018-04-04 7:35 UTC (permalink / raw
To: Masahiro Yamada
Cc: linux-mmc@vger.kernel.org, Piotr Sroka, Linux Kernel Mailing List,
Adrian Hunter
On 27 March 2018 at 11:29, Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
> Cadence sent out an errata report to their customers of this IP.
> This errata is not so severe, but the tune request should be sent
> twice to avoid the potential issue.
>
> Quote from the report:
>
> Problem Summary
> ---------------
> The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
> This issue may lead to an incorrect values of read/write pointers of
> the synchronization FIFO. Such a situation can happen at the SDR104
> and HS200 tuning procedure when the PHY is requested to change a phase
> of sampling clock when moving to the next tuning iteration.
>
> Workarounds
> -----------
> The following are valid workarounds to resolve the issue:
>
> 1. In eMMC mode, software sends tune request twice instead of once at
> each iteration. This means that the clock phase is not changed on
> the second request so there is no potential for clock instability.
> 2. In SD mode, software must not use the hardware tuning and instead
> perform an almost identical procedure to eMMC, using the HRS34 Tune
> Force register.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Do you want this to be tagged for stable as well? And perhaps you
could add a fixes tag?
Kind regards
Uffe
> ---
>
> drivers/mmc/host/sdhci-cadence.c | 22 ++++++++++++++++++----
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-cadence.c b/drivers/mmc/host/sdhci-cadence.c
> index 0f589e2..bc30d16 100644
> --- a/drivers/mmc/host/sdhci-cadence.c
> +++ b/drivers/mmc/host/sdhci-cadence.c
> @@ -253,6 +253,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
> struct sdhci_cdns_priv *priv = sdhci_cdns_priv(host);
> void __iomem *reg = priv->hrs_addr + SDHCI_CDNS_HRS06;
> u32 tmp;
> + int i, ret;
>
> if (WARN_ON(!FIELD_FIT(SDHCI_CDNS_HRS06_TUNE, val)))
> return -EINVAL;
> @@ -260,11 +261,24 @@ static int sdhci_cdns_set_tune_val(struct sdhci_host *host, unsigned int val)
> tmp = readl(reg);
> tmp &= ~SDHCI_CDNS_HRS06_TUNE;
> tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_TUNE, val);
> - tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
> - writel(tmp, reg);
>
> - return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
> - 0, 1);
> + /*
> + * Workaround for IP errata:
> + * The IP6116 SD/eMMC PHY design has a timing issue on receive data
> + * path. Send tune request twice.
> + */
> + for (i = 0; i < 2; i++) {
> + tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
> + writel(tmp, reg);
> +
> + ret = readl_poll_timeout(reg, tmp,
> + !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
> + 0, 1);
> +
> + return ret;
> + }
> +
> + return 0;
> }
>
> static int sdhci_cdns_execute_tuning(struct mmc_host *mmc, u32 opcode)
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata
2018-04-04 7:35 ` Ulf Hansson
@ 2018-04-04 9:05 ` Masahiro Yamada
2018-04-04 12:46 ` Ulf Hansson
0 siblings, 1 reply; 5+ messages in thread
From: Masahiro Yamada @ 2018-04-04 9:05 UTC (permalink / raw
To: Ulf Hansson
Cc: linux-mmc@vger.kernel.org, Piotr Sroka, Linux Kernel Mailing List,
Adrian Hunter
Hi.
2018-04-04 16:35 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
> On 27 March 2018 at 11:29, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> Cadence sent out an errata report to their customers of this IP.
>> This errata is not so severe, but the tune request should be sent
>> twice to avoid the potential issue.
>>
>> Quote from the report:
>>
>> Problem Summary
>> ---------------
>> The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
>> This issue may lead to an incorrect values of read/write pointers of
>> the synchronization FIFO. Such a situation can happen at the SDR104
>> and HS200 tuning procedure when the PHY is requested to change a phase
>> of sampling clock when moving to the next tuning iteration.
>>
>> Workarounds
>> -----------
>> The following are valid workarounds to resolve the issue:
>>
>> 1. In eMMC mode, software sends tune request twice instead of once at
>> each iteration. This means that the clock phase is not changed on
>> the second request so there is no potential for clock instability.
>> 2. In SD mode, software must not use the hardware tuning and instead
>> perform an almost identical procedure to eMMC, using the HRS34 Tune
>> Force register.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Do you want this to be tagged for stable as well? And perhaps you
> could add a fixes tag?
It would be nicer to make it a back-port candidate,
but this patch can not cleanly apply to the initial commit of this driver.
If you apply it for -next, it would be fine with me.
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata
2018-04-04 9:05 ` Masahiro Yamada
@ 2018-04-04 12:46 ` Ulf Hansson
0 siblings, 0 replies; 5+ messages in thread
From: Ulf Hansson @ 2018-04-04 12:46 UTC (permalink / raw
To: Masahiro Yamada
Cc: linux-mmc@vger.kernel.org, Piotr Sroka, Linux Kernel Mailing List,
Adrian Hunter
On 4 April 2018 at 11:05, Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi.
>
> 2018-04-04 16:35 GMT+09:00 Ulf Hansson <ulf.hansson@linaro.org>:
>> On 27 March 2018 at 11:29, Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>>> Cadence sent out an errata report to their customers of this IP.
>>> This errata is not so severe, but the tune request should be sent
>>> twice to avoid the potential issue.
>>>
>>> Quote from the report:
>>>
>>> Problem Summary
>>> ---------------
>>> The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
>>> This issue may lead to an incorrect values of read/write pointers of
>>> the synchronization FIFO. Such a situation can happen at the SDR104
>>> and HS200 tuning procedure when the PHY is requested to change a phase
>>> of sampling clock when moving to the next tuning iteration.
>>>
>>> Workarounds
>>> -----------
>>> The following are valid workarounds to resolve the issue:
>>>
>>> 1. In eMMC mode, software sends tune request twice instead of once at
>>> each iteration. This means that the clock phase is not changed on
>>> the second request so there is no potential for clock instability.
>>> 2. In SD mode, software must not use the hardware tuning and instead
>>> perform an almost identical procedure to eMMC, using the HRS34 Tune
>>> Force register.
>>>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> Do you want this to be tagged for stable as well? And perhaps you
>> could add a fixes tag?
>
>
> It would be nicer to make it a back-port candidate,
> but this patch can not cleanly apply to the initial commit of this driver.
>
>
> If you apply it for -next, it would be fine with me.
Okay, so I have queued it up for 4.18, thanks!
Kind regards
Uffe
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata
@ 2020-01-21 9:42 Masahiro Yamada
0 siblings, 0 replies; 5+ messages in thread
From: Masahiro Yamada @ 2020-01-21 9:42 UTC (permalink / raw
To: u-boot
Cadence sent out an errata report to their customers of this IP.
This errata is not so severe, but the tune request should be sent
twice to avoid the potential issue.
Quote from the report:
Problem Summary
---------------
The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
This issue may lead to an incorrect values of read/write pointers of
the synchronization FIFO. Such a situation can happen at the SDR104
and HS200 tuning procedure when the PHY is requested to change a phase
of sampling clock when moving to the next tuning iteration.
Workarounds
-----------
The following are valid workarounds to resolve the issue:
1. In eMMC mode, software sends tune request twice instead of once at
each iteration. This means that the clock phase is not changed on
the second request so there is no potential for clock instability.
2. In SD mode, software must not use the hardware tuning and instead
perform an almost identical procedure to eMMC, using the HRS34 Tune
Force register.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/mmc/sdhci-cadence.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/sdhci-cadence.c b/drivers/mmc/sdhci-cadence.c
index 4736263bf2a6..eb53653435df 100644
--- a/drivers/mmc/sdhci-cadence.c
+++ b/drivers/mmc/sdhci-cadence.c
@@ -170,6 +170,7 @@ static int sdhci_cdns_set_tune_val(struct sdhci_cdns_plat *plat,
{
void __iomem *reg = plat->hrs_addr + SDHCI_CDNS_HRS06;
u32 tmp;
+ int i, ret;
if (WARN_ON(!FIELD_FIT(SDHCI_CDNS_HRS06_TUNE, val)))
return -EINVAL;
@@ -177,11 +178,23 @@ static int sdhci_cdns_set_tune_val(struct sdhci_cdns_plat *plat,
tmp = readl(reg);
tmp &= ~SDHCI_CDNS_HRS06_TUNE;
tmp |= FIELD_PREP(SDHCI_CDNS_HRS06_TUNE, val);
- tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
- writel(tmp, reg);
- return readl_poll_timeout(reg, tmp, !(tmp & SDHCI_CDNS_HRS06_TUNE_UP),
- 1);
+ /*
+ * Workaround for IP errata:
+ * The IP6116 SD/eMMC PHY design has a timing issue on receive data
+ * path. Send tune request twice.
+ */
+ for (i = 0; i < 2; i++) {
+ tmp |= SDHCI_CDNS_HRS06_TUNE_UP;
+ writel(tmp, reg);
+
+ ret = readl_poll_timeout(reg, tmp,
+ !(tmp & SDHCI_CDNS_HRS06_TUNE_UP), 1);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
}
static int __maybe_unused sdhci_cdns_execute_tuning(struct udevice *dev,
--
2.17.1
^ permalink raw reply related [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-01-21 9:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-27 9:29 [PATCH] mmc: sdhci-cadence: send tune request twice to work around errata Masahiro Yamada
2018-04-04 7:35 ` Ulf Hansson
2018-04-04 9:05 ` Masahiro Yamada
2018-04-04 12:46 ` Ulf Hansson
-- strict thread matches above, loose matches on Subject: below --
2020-01-21 9:42 Masahiro Yamada
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.