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

From eLinux.org
Jump to: navigation, search
(first very early draft)
 
m (rephrase for easier understanding)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
!DRAFT!
 
 
This document describes how to test that setting a fixed drive strength for eMMC works properly.
 
This document describes how to test that setting a fixed drive strength for eMMC works properly.
  
Line 9: Line 8:
 
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 by specifiying ''dyndbg="file drivers/mmc/core/* +p"''. A branch already prepared for that is:
 +
 
 +
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/emmc-drive-strength-with_dbg
 +
 
 +
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 20:
 
=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.
+
Looking at ''arg'', we see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x12. From this value 0x12, bits 4-7 are 1, so the drive strength is of type 1 here.
 +
 
 +
If we now remove the drive strength property from the device tree, we fall back to the default behaviour. So, in the file
 +
''arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts'', remove the following line:
 +
<pre>
 +
fixed-emmc-driver-type = <1>;
 +
</pre>
  
==Testing upstream kernel with this topic branch==
+
Then, the debug output will change like this:
  
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.
+
Looking at ''arg'', we see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x02. From this value 0x02, bits 4-7 are 0, so the drive strength is of type 0 here.
The value ''0x00000b00'' means the card is in DATA state and is ready for new data.
 

Latest revision as of 10:19, 4 October 2017

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 by specifiying dyndbg="file drivers/mmc/core/* +p". A branch already prepared for that is:

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

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

Looking at arg, we see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x12. From this value 0x12, bits 4-7 are 1, so the drive strength is of type 1 here.

If we now remove the drive strength property from the device tree, we fall back to the default behaviour. So, in the file arch/arm64/boot/dts/renesas/r8a7795-salvator-xs.dts, remove the following line:

fixed-emmc-driver-type = <1>;

Then, the debug output will change like this:

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

Looking at arg, we see that 0xb9 is in the index bits 16-23, so the value bits 8-15 are 0x02. From this value 0x02, bits 4-7 are 0, so the drive strength is of type 0 here.