Andy Shevchenko | 851b7e1 | 2013-03-04 11:09:30 +0200 | [diff] [blame] | 1 | DMA Test Guide |
| 2 | ============== |
| 3 | |
| 4 | Andy Shevchenko <andriy.shevchenko@linux.intel.com> |
| 5 | |
| 6 | This small document introduces how to test DMA drivers using dmatest module. |
| 7 | |
| 8 | Part 1 - How to build the test module |
| 9 | |
| 10 | The menuconfig contains an option that could be found by following path: |
| 11 | Device Drivers -> DMA Engine support -> DMA Test client |
| 12 | |
| 13 | In the configuration file the option called CONFIG_DMATEST. The dmatest could |
| 14 | be built as module or inside kernel. Let's consider those cases. |
| 15 | |
| 16 | Part 2 - When dmatest is built as a module... |
| 17 | |
| 18 | After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest |
| 19 | folder with nodes will be created. They are the same as module parameters with |
| 20 | addition of the 'run' node that controls run and stop phases of the test. |
| 21 | |
| 22 | Note that in this case test will not run on load automatically. |
| 23 | |
| 24 | Example of usage: |
| 25 | % echo dma0chan0 > /sys/kernel/debug/dmatest/channel |
| 26 | % echo 2000 > /sys/kernel/debug/dmatest/timeout |
| 27 | % echo 1 > /sys/kernel/debug/dmatest/iterations |
| 28 | % echo 1 > /sys/kernel/debug/dmatest/run |
| 29 | |
| 30 | Hint: available channel list could be extracted by running the following |
| 31 | command: |
| 32 | % ls -1 /sys/class/dma/ |
| 33 | |
| 34 | After a while you will start to get messages about current status or error like |
| 35 | in the original code. |
| 36 | |
Andy Shevchenko | bcc567e | 2013-05-23 14:29:53 +0300 | [diff] [blame] | 37 | Note that running a new test will not stop any in progress test. |
Andy Shevchenko | 851b7e1 | 2013-03-04 11:09:30 +0200 | [diff] [blame] | 38 | |
Andy Shevchenko | 3e5ccd8 | 2013-03-04 11:09:31 +0200 | [diff] [blame] | 39 | The following command should return actual state of the test. |
| 40 | % cat /sys/kernel/debug/dmatest/run |
| 41 | |
| 42 | To wait for test done the user may perform a busy loop that checks the state. |
| 43 | |
| 44 | % while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ] |
| 45 | > do |
| 46 | > echo -n "." |
| 47 | > sleep 1 |
| 48 | > done |
| 49 | > echo |
| 50 | |
Andy Shevchenko | 851b7e1 | 2013-03-04 11:09:30 +0200 | [diff] [blame] | 51 | Part 3 - When built-in in the kernel... |
| 52 | |
| 53 | The module parameters that is supplied to the kernel command line will be used |
| 54 | for the first performed test. After user gets a control, the test could be |
Andy Shevchenko | bcc567e | 2013-05-23 14:29:53 +0300 | [diff] [blame] | 55 | re-run with the same or different parameters. For the details see the above |
| 56 | section "Part 2 - When dmatest is built as a module..." |
Andy Shevchenko | 851b7e1 | 2013-03-04 11:09:30 +0200 | [diff] [blame] | 57 | |
| 58 | In both cases the module parameters are used as initial values for the test case. |
| 59 | You always could check them at run-time by running |
| 60 | % grep -H . /sys/module/dmatest/parameters/* |
Andy Shevchenko | 95019c8 | 2013-03-04 11:09:33 +0200 | [diff] [blame] | 61 | |
| 62 | Part 4 - Gathering the test results |
| 63 | |
| 64 | The module provides a storage for the test results in the memory. The gathered |
| 65 | data could be used after test is done. |
| 66 | |
| 67 | The special file 'results' in the debugfs represents gathered data of the in |
| 68 | progress test. The messages collected are printed to the kernel log as well. |
| 69 | |
| 70 | Example of output: |
| 71 | % cat /sys/kernel/debug/dmatest/results |
| 72 | dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0) |
| 73 | |
| 74 | The message format is unified across the different types of errors. A number in |
| 75 | the parens represents additional information, e.g. error code, error counter, |
| 76 | or status. |
| 77 | |
Andy Shevchenko | d86b2f2 | 2013-03-04 11:09:34 +0200 | [diff] [blame] | 78 | Comparison between buffers is stored to the dedicated structure. |
| 79 | |
| 80 | Note that the verify result is now accessible only via file 'results' in the |
| 81 | debugfs. |