All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bough Chen <haibo.chen@nxp.com>
To: Tim Harvey <tharvey@gateworks.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
Date: Fri, 14 Apr 2017 07:41:20 +0000	[thread overview]
Message-ID: <VI1PR0401MB2335F1B3BD74C219734BA0FA90050@VI1PR0401MB2335.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <CAJ+vNU3gRG3K94V31EG1ufRsngsYG6hWq_97P2szZ2oATOd3=g@mail.gmail.com>

> -----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.

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.

Haibo Chen

> 
> Regards,
> 
> Tim

  reply	other threads:[~2017-04-14  7:41 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 [this message]
2017-04-14 14:57           ` Tim Harvey
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=VI1PR0401MB2335F1B3BD74C219734BA0FA90050@VI1PR0401MB2335.eurprd04.prod.outlook.com \
    --to=haibo.chen@nxp.com \
    --cc=adrian.hunter@intel.com \
    --cc=dave@fen-net.de \
    --cc=fabio.estevam@nxp.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    --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.