Difference between revisions of "Tests:SDHI-CMD23"

From eLinux.org
Jump to: navigation, search
(Applying pictures from snooping)
m (mention second test platform and sigrok project)
Line 12: Line 12:
  
 
* Lager/r8a7790 (R-Car H2 SoC) with a microSD card inserted into CN8 (SDHI0)
 
* 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=
Line 109: Line 113:
  
 
==Checking the bus with a logic analyzer==
 
==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:
+
Here are two [http://sigrok.org 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 bus width was fixed to 1-bit. This has no effect on CMD23 handling by the Linux MMC core:
  
 
[[File:wsa-snoop-cmd23.png|800x428px|CMD23 screenshot]] [[File:wsa-snoop-cmd18.png|800x428px|CMD18 screenshot]]
 
[[File:wsa-snoop-cmd23.png|800x428px|CMD23 screenshot]] [[File:wsa-snoop-cmd18.png|800x428px|CMD18 screenshot]]

Revision as of 13:11, 28 April 2017

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 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)

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, 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 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 bus width was fixed to 1-bit. This has no effect on CMD23 handling by the Linux MMC core:

CMD23 screenshot CMD18 screenshot