> -----Original Message----- > From: Tim Harvey [mailto:tharvey@xxxxxxxxxxxxx] > Sent: Tuesday, April 11, 2017 10:22 PM > To: Bough Chen <haibo.chen@xxxxxxx> > Cc: David Haworth <dave@xxxxxxxxxx>; Linux MMC List <linux- > mmc@xxxxxxxxxxxxxxx>; Fabio Estevam <fabio.estevam@xxxxxxx>; Ulf > Hansson <ulf.hansson@xxxxxxxxxx>; Weijun Yang <york.yang@xxxxxxx>; Adrian > Hunter <adrian.hunter@xxxxxxxxx> > 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@xxxxxxx> 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 ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
