Tests:SDHI-CMD23
This document describes how to test for SDHI that CMD23 is issued.
Contents
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 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: 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
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. 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 <mmc1: starting CMD23 arg 00000100 flags 00000015> 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 <CMD23>: 0: 00000900 00000900 00000900 00000900 43 mmc1: req done (CMD18): 0: 00000900 00000900 00000900 00000900 44 mmc1: 131072 bytes transferred: 0
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. In lines 23+24 and 37+38, you can see the successful response to CMD18 and the data transfer, like in the previous test. In line 42, you see that the MMC core completed the request to CMD23 before completing CMD18. So, CMD23 was successfully utilized in this transfer.
Checking the bus with a logic analyzer
Here are two 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 bus width was fixed to 1-bit. This has no effect on CMD23 handling by the Linux MMC core: