On 16/01/20 5:36 pm, Ulf Hansson wrote: > On Wed, 8 Jan 2020 at 10:37, Y.b. Lu <yangbo.lu@xxxxxxx> wrote: >> >> Hi Uffe and Adrian, >> >> Back again on this topic. Actually we are trying to make the error recovery work after data error of CMD18 in linux-4.14. >> With this patch, when CMD18 data error got, manual CMD12 would be sent. And then went into mmc_blk_cmd_recovery(). (Should be mmc_blk_mq_rw_recovery() in latest linux-5.5-rc2.) >> In mmc_blk_cmd_recovery(), re-tuning would fail before sending CMD13 on our specific board. >> This may be some issue related to specific eMMC card we are investigating. >> >> The above is just background introduction, and you may not care about that:) >> I'd like to have some queries on CMD12 usage in MMC driver. >> 1. It seems CMD12 is always not using ABORT type for sending in sdhci.c. The SDHCI_CMD_ABORTCMD hasn't been used. Is this issue? > AFAIK it is not an issue, but support for it can be added if you need it. > >> 2. In block.c, CMD12 uses R1 response for data reading and R1B response for writing. Is it ok to use R1 response for SD? The SD spec mentions only R1B response for CMD12. > > I think the specs isn't that clear on this. In this case, the R1B, is > an R1 with an *optional* busy signaling on DAT0, unless it has been > changed lately. Also SDHCI offers SDHCI_QUIRK2_STOP_WITH_TC to turn all CMD12 responses into R1B > > Additionally, as far as can tell, there have been no reports about > problems with the current approach for "reads". Are you saying there > is? > > [...] > > Kind regards > Uffe >
