Difference between revisions of "Tests:eMMC-fixed-drive-strength"

From eLinux.org
Jump to: navigation, search
(first very early draft)
 
(still draft, but basic pattern explained)
Line 9: Line 9:
 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/emmc-drive-strength
 
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/emmc-drive-strength
  
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.
+
It is critical that CONFIG_MMC_SDHI is enabled for these tests. Also, the kernel command line from the device tree should be used for proper setup of the dyndbg variable.
 +
 
 +
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 ==
 
== Hardware Environment ==
Line 17: Line 19:
 
=Testing=
 
=Testing=
  
==Testing upstream kernel *without* this topic branch==
+
Here is some background to understanding the debug output. The reference document is the JEDEC eMMC standard v5.1.
  
First, the behaviour of an unmodified kernel is examined. From the bootlog, look for any output starting with ''mmc0: req done (CMD18):''.
+
To select the drive strength, CMD6 (SWITCH) is used to modify the EXT_CSD, see chapter 6.6.1. The bit pattern for CMD6 can be found in chapter 6.10.4.
 +
There we can see, that bits 8-15 are the value to be written to the register while bits 16-23 are the index of the register. As described in chapter 7.4.65,
 +
the drive strength can be configured in the HS_TIMING register (index: 185/0xb9), bits 4-7.  
  
 +
So, we can use this command to find a CMD6 which writes to register 185/0xb9:
 
<pre>
 
<pre>
mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900
+
# dmesg | grep CMD6.*b9
mmc1:    4096 bytes transferred: 0
+
mmc0: starting CMD6 arg 03b91201 flags 0000049d
mmc1:    (CMD12): 0: 00000000 00000000 00000000 00000000
 
 
</pre>
 
</pre>
  
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.
+
We see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x12. Since bits 4-7 are 1, the drive strength is of type 1 here.
  
==Testing upstream kernel with this topic branch==
+
If we know remove the drive strength property from the device tree, we fall back to the default behaviour.
 +
FIXME: explain how to remove the property
  
The bootlog output now looks like this:
 
 
<pre>
 
<pre>
mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900
+
# dmesg | grep CMD6.*b9
mmc1:    4096 bytes transferred: 0
+
mmc0: starting CMD6 arg 03b90201 flags 0000049d
mmc1:    (CMD12): 0: 00000b00 00000000 00000000 00000000
 
 
</pre>
 
</pre>
  
We can see now on the last line, that a proper value was reported back to the MMC core.
+
We see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x02. Since bits 4-7 are 0, the drive strength is of type 0 here.
The value ''0x00000b00'' means the card is in DATA state and is ready for new data.
 

Revision as of 07:51, 14 September 2017

!DRAFT! This document describes how to test that setting a fixed drive strength for eMMC works properly.

Setup

Kernel Version and Configuration

Support for this feature is expected to land upstream in v4.15. It is currently available in a topic branch:

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/emmc-drive-strength

It is critical that CONFIG_MMC_SDHI is enabled for these tests. Also, the kernel command line from the device tree should be used for proper setup of the dyndbg variable.

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

  • Salvator-XS/r8a7795 (R-Car H3 ES2.0 SoC) with on-board eMMC.

Testing

Here is some background to understanding the debug output. The reference document is the JEDEC eMMC standard v5.1.

To select the drive strength, CMD6 (SWITCH) is used to modify the EXT_CSD, see chapter 6.6.1. The bit pattern for CMD6 can be found in chapter 6.10.4. There we can see, that bits 8-15 are the value to be written to the register while bits 16-23 are the index of the register. As described in chapter 7.4.65, the drive strength can be configured in the HS_TIMING register (index: 185/0xb9), bits 4-7.

So, we can use this command to find a CMD6 which writes to register 185/0xb9:

# dmesg | grep CMD6.*b9
mmc0: starting CMD6 arg 03b91201 flags 0000049d

We see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x12. Since bits 4-7 are 1, the drive strength is of type 1 here.

If we know remove the drive strength property from the device tree, we fall back to the default behaviour. FIXME: explain how to remove the property

# dmesg | grep CMD6.*b9
mmc0: starting CMD6 arg 03b90201 flags 0000049d

We see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x02. Since bits 4-7 are 0, the drive strength is of type 0 here.