> -----Original Message----- > From: linux-mmc-owner@xxxxxxxxxxxxxxx [mailto:linux-mmc- > owner@xxxxxxxxxxxxxxx] On Behalf Of Tim Harvey > Sent: Saturday, April 08, 2017 3:55 AM > To: David Haworth <dave@xxxxxxxxxx> > Cc: Linux MMC List <linux-mmc@xxxxxxxxxxxxxxx>; Fabio Estevam > <fabio.estevam@xxxxxxx>; Ulf Hansson <ulf.hansson@xxxxxxxxxx>; Weijun > Yang <york.yang@xxxxxxx> > Subject: Re: IMX6 ESDHC mmc with UHS-I occasional failure with DDR50 cards > > On Tue, Apr 4, 2017 at 3:00 PM, David Haworth <dave@xxxxxxxxxx> wrote: > > Hi Tim, > > > > This looks uncomfortably familiar. > > I've been having problems with "some" micro-SDHC cards, but in > > different circumstances: mmc_spi on a raspberry pi. > > > > "Good" cards sign on as "mmcblk1: mmc1:0000 00000 7.35 GiB" > > "Bad" cards sign on as "mmcblk1: mmc1:0000 SU08G 7.40 GiB" > > and eventually return a bit shifted response. > > > > The "bad" cards are all SanDisk cards. The "good" cards are cheap > > cards with one exception that is marked as SanDisk but looks like a > > fake. > > > > More details here: > > > https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=172562&p=11039 > > 43#p1103943 > > if you can read it. > > Unfortunately I don't have a solution. > > > > All the best > > Dave > > > > Dave, > > Thanks for the response, but I don't think this is the same thing because in your > case I don't see any tuning or transfer errors reported. > > 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) 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. Best Regards, Haibo > Tim > -- > To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
