Eric Lee / smarc-fsl-linux-kernel

08 Jun, 2013

1 commit

  • bcc567e31   dmatest: do not allow to interrupt ongoing tests ... Browse Code »

    When user interrupts ongoing transfers the dmatest may end up with console
    lockup, oops, or data mismatch. This patch prevents user to abort any ongoing
    test.

    Documentation is updated accordingly.

    Signed-off-by: Andy Shevchenko
    Reported-by: Will Deacon
    Tested-by: Will Deacon
    Signed-off-by: Vinod Koul

    Andy Shevchenko
     

15 Apr, 2013

4 commits

  • d86b2f298   dmatest: append verify result to results ... Browse Code »

    Comparison between buffers is stored to the dedicated structure.

    Note that the verify result is now accessible only via file 'results' in the
    debugfs.

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Andy Shevchenko
     
  • 95019c8c5   dmatest: gather test results in the linked list ... Browse Code »

    The patch provides a storage for the test results in the linked list. The
    gathered data could be used after test is done.

    The new file 'results' represents gathered data of the in progress test. The
    messages collected are printed to the kernel log as well.

    Example of output:
    % cat /sys/kernel/debug/dmatest/results
    dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)

    The message format is unified across the different types of errors. A number in
    the parens represents additional information, e.g. error code, error counter,
    or status.

    Note that the buffer comparison is done in the old way, i.e. data is not
    collected and just printed out.

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Andy Shevchenko
     
  • 3e5ccd866   dmatest: return actual state in 'run' file ... Browse Code »

    The following command should return actual state of the test.
    % cat /sys/kernel/debug/dmatest/run

    To wait for test done the user may perform a busy loop that checks the state.
    % while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
    > do
    > echo -n "."
    > sleep 1
    > done
    > echo

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Andy Shevchenko
     
  • 851b7e16a   dmatest: run test via debugfs ... Browse Code »

    Instead of doing
    modprobe dmatest ...
    modprobe -r dmatest
    we allow user to run tests interactively.

    The dmatest could be built as module or inside kernel. Let's consider those
    cases.

    1. When dmatest is built as a module...

    After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
    folder with nodes will be created. They are the same as module parameters with
    addition of the 'run' node that controls run and stop phases of the test.

    Note that in this case test will not run on load automatically.

    Example of usage:
    % echo dma0chan0 > /sys/kernel/debug/dmatest/channel
    % echo 2000 > /sys/kernel/debug/dmatest/timeout
    % echo 1 > /sys/kernel/debug/dmatest/iterations
    % echo 1 > /sys/kernel/debug/dmatest/run

    After a while you will start to get messages about current status or error like
    in the original code.

    Note that running a new test will stop any in progress test.

    2. When built-in in the kernel...

    The module parameters that is supplied to the kernel command line will be used
    for the first performed test. After user gets a control, the test could be
    interrupted or re-run with same or different parameters. For the details see
    the above section "1. When dmatest is built as a module..."

    In both cases the module parameters are used as initial values for the test case.
    You always could check them at run-time by running
    % grep -H . /sys/module/dmatest/parameters/*

    Signed-off-by: Andy Shevchenko
    Signed-off-by: Vinod Koul

    Andy Shevchenko