Hi Wolfram-san, > From: Wolfram Sang, Sent: Friday, August 14, 2020 4:15 PM > > > > > > + /* Tuning done, no special handling for SCC clock needed anymore */ > > > > > + priv->keep_scc_freq = false; > > > > > + > > > > > > > > Setting keep_scc_freq to false is only here. But, I'm thinking > > > > we should set it in some error paths like below somehow too: > > > > - error paths before hs400_complete() in mmc_select_hs400(). > > > > - error path of mmc_execute_tuning() in mmc_retune(). > > > > > > Hmm, I guess you are right. That would kind of spoil my approach taken > > > here. Maybe we need another flag in the core like 'doing_tune' to > > > supplement 'doing_retune', so or driver knows when any kind of tuning is > > > going on? > > > > Adding such a new flag is better, I think. > > So, I added a flag to the MMC core and I think it should work. However, > I can't test it currently because, sadly, the issue disappeared again :( I got a report from a colleague about this issue. According to the report, this issue is related to retuning. When retuning happens, the mmc core calls mmc_hs400_to_hs200() and then mmc_hs400_to_hs200() will set the clock as 52MHz at first. So, it's possible to cause the issue. It's difficult to cause retuning in normal situation. But, according to the report, if we add a code which the sdhi driver reports an error at the first CMD18 once, we can cause retuning and then the issue happens. Best regards, Yoshihiro Shimoda
