[PATCH 4/7] aw_mmc: recover a clock update stuck behind an unsolicited data transfer

[vice-shore-grid_duck.com]

Summary

On the PineTab the eMMC is left in bus-test mode by U-Boot (last command
CMD14, 8 bytes pending) and streams its buffer as soon as it receives a
clock. The controller then considers a data transfer in progress and
the PRG_CLK that enabled the clock never completes; every later request
times out and, at boot, the SD card holding the root file system is not
found in time. The hardware reset pulse asserts and deasserts RST_n
back to back; the eMMC specification requires the line low for at
least 1us and 200us before the first command. This PR adds the delay.

[mmel]

sys/arm/allwinner/aw_mmc.c

1314

This doesn't make sense to me. Could you please explain why calling aw_mmc_reset() in aw_mmc_attach() is not sufficient and must be repeated, or how an unfinished transfer in the eMMC card can survive CMD00? Also, please explain how issuing aw_mmc_reset() can work at all after the interface voltage is switched to 1.8 V.