All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: Bough Chen <haibo.chen@nxp.com>
Cc: David Haworth <dave@fen-net.de>,
	Linux MMC List <linux-mmc@vger.kernel.org>,
	Fabio Estevam <fabio.estevam@nxp.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Weijun Yang <york.yang@csr.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Shawn Guo <shawnguo@kernel.org>
Subject: Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards
Date: Fri, 14 Apr 2017 07:57:11 -0700	[thread overview]
Message-ID: <CAJ+vNU2OdVfT58DHm8g8306ZUgt9Pv1SJxhD0T6XAWKt0TvebQ@mail.gmail.com> (raw)
In-Reply-To: <VI1PR0401MB2335F1B3BD74C219734BA0FA90050@VI1PR0401MB2335.eurprd04.prod.outlook.com>

On Fri, Apr 14, 2017 at 12:41 AM, Bough Chen <haibo.chen@nxp.com> wrote:
>> -----Original Message-----
>> From: Tim Harvey [mailto:tharvey@gateworks.com]
>> Sent: Tuesday, April 11, 2017 10:22 PM
>> To: Bough Chen <haibo.chen@nxp.com>
>> Cc: David Haworth <dave@fen-net.de>; Linux MMC List <linux-
>> mmc@vger.kernel.org>; Fabio Estevam <fabio.estevam@nxp.com>; Ulf
>> Hansson <ulf.hansson@linaro.org>; Weijun Yang <york.yang@csr.com>; Adrian
>> Hunter <adrian.hunter@intel.com>
>> Subject: Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards
>>
>> On Tue, Apr 11, 2017 at 2:28 AM, Bough Chen <haibo.chen@nxp.com> wrote:
>> >> -----Original Message-----
>> <snip>
>> >>
>> >> I've moved on to 4.11-rc5 and notice that I'm always seeing that on a
>> >> failure the imx sdhc not able to determine a min/max tuning delay:
>> >>
>> >> 4.11.0-rc5:
>> >> [   48.812381] mmc0: card aaaa removed
>> >> [   49.793392] mmc0: host does not support reading read-only switch,
>> >> assuming write-enable
>> >> [   49.810294] sdhci_execute_tuning
>> >> [   49.813612] esdhc_executing_tuning
>> >> [   49.968154] sdhci-esdhc-imx 2198000.usdhc: tuning failed at 0x7f
>> >> ret -5 (min=127/max=128)
>> >> ^^^^ added debug shows -EIO returned from mmc_send_tuning although
>> >> I've also seen -84 get returned
>> >> [   49.980540] mmc0: tuning execution failed: -5
>> >> [   49.984974] mmc0: ddr50 tuning failed
>> >> [   49.989068] mmc0: new ultra high speed DDR50 SDHC card at address aaaa
>> >> [   49.999844] mmcblk0: mmc0:aaaa SL08G 7.40 GiB
>> >>
>> >> I've also found that if I revert '9faac7b mmc: sdhci: enable tuning for DDR50'
>> >> thus skipping the tuning the issue goes away however note that
>> >> occasionally I do see a transfer error that perhaps is retried [
>> >> 361.067763] mmc0: card aaaa removed [  361.412732] mmc0: host does
>> >> not support reading read-only switch, assuming write-enable [
>> >> 361.429719] mmc0: new ultra high speed DDR50 SDHC card at address
>> >> aaaa [  361.443060] mmcblk0: mmc0:aaaa SL08G 7.40 GiB [  361.465658]
>> >> mmcblk0: p1 [  362.422335] mmc0: card aaaa removed [  362.752719]
>> >> mmc0: host does not support reading read-only switch, assuming
>> >> write-enable [  362.769675] mmc0: new ultra high speed DDR50 SDHC
>> >> card at address aaaa [  362.782900] mmcblk0: mmc0:aaaa SL08G 7.40 GiB
>> >> [  362.805996]
>> >> mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response
>> >> 0x900, card status 0xb00 ^^^^ occasionally see this error but because
>> >> retries occur at the block level it still works [  362.931689]
>> >> mmcblk0: p1
>> >>
>> >> Again with 9faac7b reverted and some extra debugging:
>> >> [   33.823170] mmc0: host does not support reading read-only switch,
>> >> assuming write-enable
>> >> [   33.847185] mmc0: new ultra high speed DDR50 SDHC card at address aaaa
>> >> [   33.856063] mmcblk0: mmc0:aaaa SL08G 7.40 GiB
>> >> [   33.874227] mmcblk0: error -84 transferring data, sector 0, nr 8,
>> >> cmd response 0x900, card status 0xb00
>> >> [   33.896829] mmcblk0: error -84 transferring data, sector 0, nr 8,
>> >> cmd response 0x900, card status 0xb00
>> >> [   33.906312] mmcblk0: error -84 transferring data, sector 0, nr 8,
>> >> cmd response 0x900, card status 0xb00
>> >> [   34.022117] mmcblk0: error 0 transferring data, sector 0, nr 8, cmd
>> >> response 0x900, card status 0xb00
>> >> ^^^^ added debugging shows retries at block level and eventually all is fine
>> >> [   34.031500]  mmcblk0: p1
>> >>
>> >> So far every DDR50 card I have (several Kingston and Sandisk card
>> >> models) behaves like this.
>> >>
>> >> I tried adding a settling delay when VSELECT was changed in the
>> >> sdhci-esdhc- imx driver and that didn't help.
>> >>
>> > Hi Tim
>> >
>> > Which imx6 soc do you use?  From your log, I notice you use the MAN tuning
>> method, so I guess you use imx6qdl.
>> >
>> > imx usdhc has an IC bug. For the tuning procedure, the first pass tuning delay
>> value must bigger than 10.
>> > Due to DDR50 timing is not that rigorous, so maybe even when we just add 1
>> delay cell, tuning can pass, but this trigger the internal IC bug, then you meet
>> the following issue just as you meet:
>> >        sdhci-esdhc-imx 2198000.usdhc: tuning failed at 0x7f
>> ( min=127/max=128)
>> >
>>
>> Haibo,
>>
>> Thanks for the response.
>>
>> Yes, this issue is seen on the IMX6DQ and IMX6SDL. Can you point me to
>> information on this bug? I don't see it in the latest IMX6DQCE.pdf errata
>> document.
>>
>> > So you can change the ESDHC_TUNE_CTRL_MIN from 0 to 15, then you can
>> see the DDR50 tuning return to normal.
>> >
>> > For the STD tuning method, you can add the property 'fsl,tuning-start-tap =
>> <20>' in dts.
>> >
>> > All this make the first trying tuning delay value larger than 10, to avoid  the
>> internal IMX USDHC IC bug.
>> >
>> > SDR104 card do not has this issue, because for SDR104 card, the first pass
>> tuning value normally larger than 10.
>> >
>>
>> unfortunately, this does not resolve the issue. I tried ESDHC_TUNE_CTRL_MIN
>> of 15, 20, and 30 and they all produce the same issue around 20% of insertions:
>> sdhci-esdhc-imx 2198000.usdhc: tunning failed at 0x7f ret -84
>>
>> Here are some min/max tuning values from some various cards I have:
>> - Samsung SL08G DDR50: min=8 max=37
>> - Kingston SD8GB DDR50: min=8 max=36
>> - Sandisk SS16G DDR50: min=10 max=37
>> - Sandisk SU08G DDR50: min=9 max=36
>> - Samsung Pro 00000 SDR104: min=14 max=26
>> - Kingston SDR104 SDCIT: min=25 max=36
>>
>> All of the DDR50 cards above fail in the same way appx 20% of insertions.
>>
>> Has anyone else been able to confirm they see the same issue on IMX6 boards
>> with UHS-I support and DDR50?
>
> Hi Tim,
>
> I debug this issue these days, and find this is the I/O timing issue.
>
> Can you try to improve the pad I/O drive strength for DDR50 card? You can apply the following patch:
>
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
> index 6a1328e..4c3aeac 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -848,6 +848,7 @@ static int esdhc_change_pinstate(struct sdhci_host *host,
>
>         switch (uhs) {
>         case MMC_TIMING_UHS_SDR50:
> +       case MMC_TIMING_UHS_DDR50:
>                 pinctrl = imx_data->pins_100mhz;
>                 break;
>         case MMC_TIMING_UHS_SDR104:
>
> If this patch also test pass on your side, I will upstream it.
>

Haibo,

Yes, this does resolve the issue where DDR50 cards fail to tune 20% of
the time. Using the 100mhz pinctrl's for DDR50 passes tuning every
time with a min=1 and max=29 (as opposed to a min=8 max=36 I was
seeing on previous successes).

Please submit a patch if you don't mind. Also, stable@vger.kernel.org
should be cc'd on the patch and the patch should be applied all the
way back to Linux v4.4 where DDR50 tuning first appeared with 9faac7b
mmc: sdhci: enable tuning for DDR50.

> By the way, I just confirm with our IC guys, the IC bug I mentioned in the before mail do not impact the software tuning method (MAN_TUNING), this IC bug just impact the STD_TUNING, sorry for the mislead.
>

Ok, thanks for the info. Note still that I don't see anything in the
IMX6 errata regarding thisb.

Regards,

Tim

  reply	other threads:[~2017-04-14 14:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 21:26 Tim Harvey
2017-04-04 22:00 ` David Haworth
2017-04-07 19:55   ` Tim Harvey
2017-04-11  9:28     ` Bough Chen
2017-04-11 14:21       ` Tim Harvey
2017-04-14  7:41         ` Bough Chen
2017-04-14 14:57           ` Tim Harvey [this message]
2017-04-11 14:40     ` David Haworth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ+vNU2OdVfT58DHm8g8306ZUgt9Pv1SJxhD0T6XAWKt0TvebQ@mail.gmail.com \
    --to=tharvey@gateworks.com \
    --cc=adrian.hunter@intel.com \
    --cc=dave@fen-net.de \
    --cc=fabio.estevam@nxp.com \
    --cc=haibo.chen@nxp.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=shawnguo@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=york.yang@csr.com \
    --subject='Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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.