This was a nasty one because it wasn't reproducible for a long time. Recent work on the manual calibration mechanism made it show up again for me, so I could finally tackle it. The reason is that there is more SCC handling now, so we are more likely to stumble again over the problem that it may have no clock at that time. There is a patch in the BSP handling this issue, too, but it didn't work for me on at least v5.6+ kernels. Also, I thought it is way simpler to keep the last working external frequency instead of defining a default one per SoC generation. Patches are based on mmc/next as of yesterday or so. You need the 'manual calibration' patches for the issue to show up. They are not fully tested yet, so I will send them as RFC in a minute. Or just fetch this branch: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/sdhi/new_manual_calib With that branch, reading a file from eMMC works for me(tm). If you prevent 'keep_scc_freq' from being 'true', then reading a file should stall the machine. Happened here on a R-Car M3-N to me. Looking forward to comments and more tests. Thanks, Wolfram Wolfram Sang (2): mmc: core: when downgrading HS400, callback into drivers earlier mmc: renesas_sdhi: keep SCC clock active when tuning drivers/mmc/core/mmc.c | 14 +++++++------- drivers/mmc/host/renesas_sdhi.h | 1 + drivers/mmc/host/renesas_sdhi_core.c | 25 ++++++++++++++++++++++--- 3 files changed, 30 insertions(+), 10 deletions(-) -- 2.20.1
