On Fri, 23 Aug 2019 at 11:36, Jan Kaisrlik <ja.kaisrlik@xxxxxxxxx> wrote: > > čt 22. 8. 2019 v 15:59 odesílatel Ulf Hansson <ulf.hansson@xxxxxxxxxx> napsal: > > > > + some meson driver folkz > > > > On Thu, 22 Aug 2019 at 10:27, Jan Kaisrlik <ja.kaisrlik@xxxxxxxxx> wrote: > > > > > > st 21. 8. 2019 v 17:12 odesílatel Ulf Hansson <ulf.hansson@xxxxxxxxxx> napsal: > > > > > > > > + Chaotian Jing > > > > > > > > On Tue, 20 Aug 2019 at 13:42, <ja.kaisrlik@xxxxxxxxx> wrote: > > > > > > > > > > From: Jan Kaisrlik <ja.kaisrlik@xxxxxxxxx> > > > > > > > > > > This reverts commit 3a0681c7448b174e5dcfd19e9079cdd281c35f1a. > > > > > > > > > > Turns out the patch breaks initialization of Toshiba THGBMNG5. > > > > > [ 1.648951] mmc0: mmc_select_hs200 failed, error -84 > > > > > [ 1.648988] mmc0: error -84 whilst initialising MMC card > > > > > > > > For exactly this reason, when getting CRC errors on the first attempt, > > > > doing a retry makes little sense. > > > > > > > > I have looped in Chaotian who has some more details about the problem. > > > > > > > > In any case, Jan, what HW and mmc controller are you using? > > > > > > It's a custom board based on Amlogic A113D. The compatibility in dts > > > is set to "alogic,meson-axg-mmc". > > > > Good. I have looped in some of the relevant developers/maintainers. > > > > > > > > In the different revision of HW we are using Kingston EMMC04G. The > > > card has no such problem and is working fine without this patch. > > > We observed it only on mention Toshiba card. > > > > I see. Of course it would also be interesting to see what CMD6 command > > that is that fails. Would you mind adding some debug/trace to find out > > what command it is that fails? > > Providing a log with following debug option `dyndbg="func mmc_mrq_pr_debug +p` Thanks! > > # dmesg | grep mmc0 > [ 1.557984] mmc0: starting CMD52 arg 00000c00 flags 00000195 > [ 1.563989] mmc0: starting CMD52 arg 80000c08 flags 00000195 > [ 1.575219] mmc0: starting CMD0 arg 00000000 flags 000000c0 > [ 1.593142] mmc0: starting CMD8 arg 000001aa flags 000002f5 > [ 1.604439] mmc0: starting CMD5 arg 00000000 flags 000002e1 > [ 1.623875] mmc0: starting CMD55 arg 00000000 flags 000000f5 > [ 1.631024] mmc0: starting CMD55 arg 00000000 flags 000000f5 > [ 1.640221] mmc0: starting CMD55 arg 00000000 flags 000000f5 > [ 1.646802] mmc0: starting CMD55 arg 00000000 flags 000000f5 > [ 1.652397] mmc0: starting CMD1 arg 00000000 flags 000000e1 > [ 1.669894] mmc0: starting CMD1 arg 40ff8080 flags 000000e1 > [ 1.682925] mmc0: starting CMD1 arg 40ff8080 flags 000000e1 > [ 1.697073] mmc0: starting CMD1 arg 40ff8080 flags 000000e1 > [ 1.704327] mmc0: starting CMD0 arg 00000000 flags 000000c0 > [ 1.722251] mmc0: starting CMD1 arg 40200000 flags 000000e1 > [ 1.745317] mmc0: starting CMD1 arg 40200000 flags 000000e1 > [ 1.752813] mmc0: starting CMD2 arg 00000000 flags 00000007 > [ 1.771731] mmc0: starting CMD3 arg 00010000 flags 00000015 > [ 1.784771] mmc0: starting CMD9 arg 00010000 flags 00000007 > [ 1.790433] mmc0: starting CMD7 arg 00010000 flags 00000015 > [ 1.795691] mmc0: starting CMD8 arg 00000000 flags 000000b5 > [ 1.800800] mmc0: blksz 512 blocks 1 flags 00000200 tsac 50 ms nsac 0 > [ 1.818402] mmc0: starting CMD6 arg 03af0101 flags 0000049d > [ 1.818845] mmc0: starting CMD13 arg 00010000 flags 00000195 > [ 1.824349] mmc0: starting CMD6 arg 03220101 flags 0000049d > [ 1.829992] mmc0: starting CMD13 arg 00010000 flags 00000195 > [ 1.835493] mmc0: starting CMD6 arg 03b70201 flags 0000049d > [ 1.841119] mmc0: starting CMD13 arg 00010000 flags 00000195 > [ 1.846628] mmc0: starting CMD8 arg 00000000 flags 000000b5 > [ 1.851719] mmc0: blksz 512 blocks 1 flags 00000200 tsac 50 ms nsac 0 > [ 1.860347] mmc0: starting CMD6 arg 03b90201 flags 0000049d > [ 1.864421] mmc0: mmc_select_hs200 failed, error -84 > [ 1.868892] mmc0: error -84 whilst initialising MMC card Alright, so the CMD6 command that tries to switch the card into HS200 mode is the one that fails. > > I cannot provide more verbose logs. When I enable more it (f.e. file > core.c) the initialization of card was successful. That's an interesting observation! Perhaps the card is still in some kind of busy state, after the CMD8 has been sent to read the EXT_CSD, when verifying the earlier bus width switch (mmc_compare_ext_csds()). > If you want to see any another logs fell free to ask. Would you mind trying one thing, in a way to narrow down the problem? Add a delay (msleep() or usleep_range() with some different values up to 50 ms) somewhere after mmc_compare_ext_csds() has been executed, but also before having mmc_select_bus_width() to return the error code? Kind regards Uffe
