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>
Subject: Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards
Date: Tue, 11 Apr 2017 07:21:39 -0700	[thread overview]
Message-ID: <CAJ+vNU3gRG3K94V31EG1ufRsngsYG6hWq_97P2szZ2oATOd3=g@mail.gmail.com> (raw)
In-Reply-To: <AM4PR0401MB23245B9B41978D09DAD9FD8D90000@AM4PR0401MB2324.eurprd04.prod.outlook.com>

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?

Regards,

Tim

  reply	other threads:[~2017-04-11 14:21 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 [this message]
2017-04-14  7:41         ` Bough Chen
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='CAJ+vNU3gRG3K94V31EG1ufRsngsYG6hWq_97P2szZ2oATOd3=g@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=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.