Tests:SDHI-CMD23

This document describes how to test for SDHI that CMD23 is issued. =Setup=

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

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

It is critical that CONFIG_MMC_SDHI and CONFIG_MMC_DEBUG are 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)

or


 * Salvator-X/r8a7796 (R-Car M3W SoC) with on-board eMMC

=Testing=

Testing upstream kernel *without* this topic branch
First, the behaviour of an unmodified kernel is examined. From the bootlog look for any output starting with mmc: starting CMD18. The example here has prefixed line-numbers for easier explanation:

1 mmc1: starting CMD18 arg 00000018 flags 000000b5 2 mmc1:    blksz 512 blocks 8 flags 00000200 tsac 100 ms nsac 0 3 mmc1:    CMD12 arg 00000000 flags 00000095 4 setup data transfer: blocksize 00000200 nr_blocks 8 5 status: 40800401 = 6 SIGSTATE_A 7 |   8 CMD_BUSY 9 |  10 CMDRESPEND 11 12 status: 00000001 = 13 CMDRESPEND 14 15 status: 20800704 = 16 CARD_REMOVE_A 17 |  18 CARD_INSERT_A 19 |  20 SIGSTATE_A 21 |  22 ILL_FUNC 23 |  24 DATAEND 25 26 status: 00000004 = 27 DATAEND 28 29 Completed data request 30 sh_mobile_sdhi ee140000.sd: Complete Rx request e6a77c04 31 mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900 32 mmc1:    4096 bytes transferred: 0 33 mmc1:    (CMD12): 0: 00000b00 00000000 00000000 00000000

In line 1, the multiblock-transfer is started (CMD18). Lines 12+13 show the successful response to this CMD18. Lines 26+27 show the successful response to the data transfer initiated by CMD18. Line 33 shows the state after CMD12 (STOP). This is the standard case without CMD23 (SET_BLOCK_COUNT) being sent.

Testing upstream kernel with this topic branch
The bootlog output now looks like this: 1  2 mmc1: starting CMD18 arg 00002300 flags 000000b5 3 mmc1:    blksz 512 blocks 256 flags 00000200 tsac 100 ms nsac 0 4 mmc1:    CMD12 arg 00000000 flags 00000095 5 status: 20800401 = 6 SIGSTATE_A 7 |   8 ILL_FUNC 9 |  10 CMDRESPEND 11 12 status: 00000001 = 13 CMDRESPEND 14 15 setup data transfer: blocksize 00000200  nr_blocks 256 16 status: 40800401 = 17 SIGSTATE_A 18 |  19 CMD_BUSY 20 |  21 CMDRESPEND 22 23 status: 00000001 = 24 CMDRESPEND 25 26 status: 20800704 = 27 CARD_REMOVE_A 28 |  29 CARD_INSERT_A 30 |  31 SIGSTATE_A 32 |  33 ILL_FUNC 34 |  35 DATAEND 36 37 status: 00000004 = 38 DATAEND 39 40 Completed data request 41 sh_mobile_sdhi ee140000.sd: Complete Rx request e680d804 42 mmc1: req done : 0: 00000900 00000900 00000900 00000900 43 mmc1: req done (CMD18): 0: 00000900 00000900 00000900 00000900 44 mmc1:    131072 bytes transferred: 0 45 mmc1:    (CMD12): 0: 00000000 00000000 00000000 00000000

Here in line 1, you can see that the Linux MMC core issued CMD23 before CMD18 in line 2. The successful response for CMD23 is in lines 12+13. Further down, in lines 23+24 and 37+38, you can see the successful response to CMD18 and the data transfer, like in the previous case. In line 42, you see that the MMC core completed the request to CMD23 before completing CMD18. Line 45 shows no response of a CMD12, because we didn't use it here. So, CMD23 was successfully utilized in this transfer.

Checking the bus with a logic analyzer
Here are two sigrok screenshots from a mesasurement snooping the SD bus. It shows that CMD23 really went over the wire before CMD18. Note that for easier snooping, the SD bus width was fixed to 1-bit. This has no effect on CMD23 handling by the Linux MMC core: