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.

=Failure cases= The tests so far only handled successful transfers. ECC failures could not be directly tested because a failing SD card could not be obtained or created (although a few TB have been written to a small 64MB (sic!) card). However, with an SD tester available inside Renesas ECC failures could be simulated.

These tests have shown that in Linux, a connection between the R1 response ECC failure bit and the error code of the MMC core needs to be created. It is currently discussed with the MMC maintainer, if this is better done in the driver or the core. The code itself is trivial and can reasonably be expected to land upstream in v4.12 as well. Once the decision is made where to put this code, this wiki page and the topic branch will be updated.