Tests:SDHI-autocmd12-responses

This document describes how to test for SDHI that the R1 responses of automatically created CMD12 messages are processed.

=Setup=

Kernel Version and Configuration
Support for this feature is expected to land upstream in v4.12. It is currently available in a topic branch:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/sdhi-autocmd12-resp

It is critical that CONFIG_MMC_SDHI and CONFIG_MMC_DEBUG is enabled for these tests. All debug messages examined in this test are automatically created during boot. There is no need to trigger the messages by some event.

Hardware Environment

 * Lager/r8a7790 (R-Car H2 SoC) with a microSD card inserted into CN8 (SDHI0)

=Testing=

Testing upstream kernel *without* this topic branch
First, the behaviour of an unmodified kernel is examined. From the bootlog, after inserting an SD card, look for any output starting with mmc1: req done (CMD18):.

mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900 mmc1:    4096 bytes transferred: 0 mmc1:    (CMD12): 0: 00000000 00000000 00000000 00000000

On the last line, you can see which suitable stop command for this transfer was provided by the MMC core (CMD12). It's response registers are reported back to the MMC core to be all 0. This is not correctly filled since at least the CURRENT_STATE bits of a R1 command will be non-0.

Testing upstream kernel with this topic branch
The bootlog output now looks like this: mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900 mmc1:    4096 bytes transferred: 0 mmc1:    (CMD12): 0: 00000b00 00000000 00000000 00000000

We can see now on the last line, that a proper value was reported back to the MMC core. The value 0x00000b00 means the card is in DATA state and is ready for new data.

Verifying this against another driver (MMCIF)
If we compare this output to the output of the MMCIF driver accessing the on-board eMMC, we see the same values: mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000 mmc0:    4096 bytes transferred: 0 mmc0:    (CMD12): 0: 00000b00 00000000 00000000 00000000 Note that the preceeding mmc0 here denotes access to the eMMC while mmc1 denotes the SD card in CN8. So, both drivers provide the same sensible responses back to the MMC core.

=TBD: ECC failure case= The tests so far only handled successful transfers. It is expected that the MMC core will act accordingly if one of the R1 responses from the automatically genereated CMD12 will have an error bit set. However, this could not be tested yet because a failing SD card could not be obtained or created (although I have written more than 1TB to an old and small 64MB card, but I'll keep going).

Tests with manually setting error bits in the SDHI driver code seemed to work. This testing is not considered reliable, though, because it is unknown if the additions to the driver really match the behaviour of an SD card. So, the search for an error inducing SD card continues.