Difference between revisions of "Tests:SDHI-autocmd12-responses"
(first version) |
(→TBD: ECC failure case) |
||
| Line 49: | Line 49: | ||
Note that the preceeding ''mmc0'' here denotes access to the eMMC while ''mmc1'' denotes the SD card in CN8. So, both drivers provide the same sensible responses back to the MMC core. | Note that the preceeding ''mmc0'' here denotes access to the eMMC while ''mmc1'' denotes the SD card in CN8. So, both drivers provide the same sensible responses back to the MMC core. | ||
| − | = | + | =About testing failure cases= |
| − | The tests so far only handled successful transfers. It is expected that the MMC core will act accordingly if one of the R1 responses from the automatically genereated CMD12 will have an error bit set. However, this could not be tested yet because a failing SD card could not be obtained or created (although | + | The tests so far only handled successful transfers. It is expected that the MMC core will act accordingly if one of the R1 responses from the automatically genereated CMD12 will have an error bit set. However, this could not be tested yet because a failing SD card could not be obtained or created (although a few TB have been written to a small 64MB (sic!) card). If the situation changes, this wiki will be updated. |
| − | Tests with manually setting error bits in the SDHI driver code seemed to work. This testing is not considered reliable, though, because it is unknown if the additions to the driver really match the behaviour of an SD card. | + | Tests with manually setting error bits in the SDHI driver code seemed to work. This testing is not considered reliable, though, because it is unknown if the additions to the driver really match the behaviour of an SD card. Thus, the search for an error inducing SD card continues. |
| + | |||
| + | However, because it was proven that the status bits of a response could be parsed and reported back to the MMC core, it can reasonably be assumed that other bits (e.g. error bits) will also be correctly transported over the same channel. | ||
Revision as of 11:13, 13 February 2017
This document describes how to test for SDHI that the R1 responses of automatically created CMD12 messages are processed.
Contents
Setup
Kernel Version and Configuration
Support for this feature is expected to land upstream in v4.12. It is currently available in a topic branch:
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/sdhi-autocmd12-resp
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: req done (CMD18):.
mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900 mmc1: 4096 bytes transferred: 0 mmc1: (CMD12): 0: 00000000 00000000 00000000 00000000
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.
Testing upstream kernel with this topic branch
The bootlog output now looks like this:
mmc1: req done (CMD18): 0: 00000900 00000900 00000b00 00000900 mmc1: 4096 bytes transferred: 0 mmc1: (CMD12): 0: 00000b00 00000000 00000000 00000000
We can see now on the last line, that a proper value was reported back to the MMC core. The value 0x00000b00 means the card is in DATA state and is ready for new data.
Verifying this against another driver (MMCIF)
If we compare this output to the output of the MMCIF driver accessing the on-board eMMC, we see the same values:
mmc0: req done (CMD18): 0: 00000900 00000000 00000000 00000000 mmc0: 4096 bytes transferred: 0 mmc0: (CMD12): 0: 00000b00 00000000 00000000 00000000
Note that the preceeding mmc0 here denotes access to the eMMC while mmc1 denotes the SD card in CN8. So, both drivers provide the same sensible responses back to the MMC core.
About testing failure cases
The tests so far only handled successful transfers. It is expected that the MMC core will act accordingly if one of the R1 responses from the automatically genereated CMD12 will have an error bit set. However, this could not be tested yet because a failing SD card could not be obtained or created (although a few TB have been written to a small 64MB (sic!) card). If the situation changes, this wiki will be updated.
Tests with manually setting error bits in the SDHI driver code seemed to work. This testing is not considered reliable, though, because it is unknown if the additions to the driver really match the behaviour of an SD card. Thus, the search for an error inducing SD card continues.
However, because it was proven that the status bits of a response could be parsed and reported back to the MMC core, it can reasonably be assumed that other bits (e.g. error bits) will also be correctly transported over the same channel.
