Commit 7832681b authored by Linus Torvalds's avatar Linus Torvalds

Merge tag 'docs-4.15' of git://git.lwn.net/linux

Pull documentation updates from Jonathan Corbet:
 "A relatively calm cycle for the docs tree again.

  - The old driver statement has been added to the kernel docs.

  - We have a couple of new helper scripts. find-unused-docs.sh from
    Sayli Karnic will point out kerneldoc comments that are not actually
    used in the documentation. Jani Nikula's
    documentation-file-ref-check finds references to non-existing files.

  - A new ftrace document from Steve Rostedt.

  - Vinod Koul converted the dmaengine docs to RST

  Beyond that, it's mostly simple fixes.

  This set reaches outside of Documentation/ a bit more than most. In
  all cases, the changes are to comment docs, mostly from Randy, in
  places where there didn't seem to be anybody better to take them"

* tag 'docs-4.15' of git://git.lwn.net/linux: (52 commits)
  documentation: fb: update list of available compiled-in fonts
  MAINTAINERS: update DMAengine documentation location
  dmaengine: doc: ReSTize pxa_dma doc
  dmaengine: doc: ReSTize dmatest doc
  dmaengine: doc: ReSTize client API doc
  dmaengine: doc: ReSTize provider doc
  dmaengine: doc: Add ReST style dmaengine document
  ftrace/docs: Add documentation on how to use ftrace from within the kernel
  bug-hunting.rst: Fix an example and a typo in a Sphinx tag
  scripts: Add a script to find unused documentation
  samples: Convert timers to use timer_setup()
  documentation: kernel-api: add more info on bitmap functions
  Documentation: fix selftests related file refs
  Documentation: fix ref to power basic-pm-debugging
  Documentation: fix ref to trace stm content
  Documentation: fix ref to coccinelle content
  Documentation: fix ref to workqueue content
  Documentation: fix ref to sphinx/kerneldoc.py
  Documentation: fix locking rt-mutex doc refs
  docs: dev-tools: correct Coccinelle version number
  ...
parents 516fb7f2 47427379
# Note: This documents additional properties of any device beyond what
# is documented in Documentation/sysfs-rules.txt
# is documented in Documentation/admin-guide/sysfs-rules.rst
What: /sys/devices/*/of_node
Date: February 2015
......
......@@ -18,6 +18,6 @@ Description:
in the initramfs, which has already been measured as part
of the trusted boot. For more information on creating and
loading existing trusted/encrypted keys, refer to:
Documentation/keys-trusted-encrypted.txt. (A sample dracut
patch, which loads the trusted/encrypted key and enables
Documentation/security/keys/trusted-encrypted.rst. (A sample
dracut patch, which loads the trusted/encrypted key and enables
EVM, is available from http://linux-ima.sourceforge.net/#EVM.)
......@@ -187,7 +187,8 @@ Description: Processor frequency boosting control
This switch controls the boost setting for the whole system.
Boosting allows the CPU and the firmware to run at a frequency
beyound it's nominal limit.
More details can be found in Documentation/cpu-freq/boost.txt
More details can be found in
Documentation/admin-guide/pm/cpufreq.rst
What: /sys/devices/system/cpu/cpu#/crash_notes
......@@ -223,7 +224,8 @@ Description: Parameters for the Intel P-state driver
no_turbo: limits the driver to selecting P states below the turbo
frequency range.
More details can be found in Documentation/cpu-freq/intel-pstate.txt
More details can be found in
Documentation/admin-guide/pm/intel_pstate.rst
What: /sys/devices/system/cpu/cpu*/cache/index*/<set_of_attributes_mentioned_below>
Date: July 2014(documented, existed before August 2008)
......
......@@ -18,7 +18,8 @@ Description:
Writing one of the above strings to this file causes the system
to transition into the corresponding state, if available.
See Documentation/power/states.txt for more information.
See Documentation/admin-guide/pm/sleep-states.rst for more
information.
What: /sys/power/mem_sleep
Date: November 2016
......@@ -35,7 +36,8 @@ Description:
represented by it to be used on subsequent attempts to suspend
the system.
See Documentation/power/states.txt for more information.
See Documentation/admin-guide/pm/sleep-states.rst for more
information.
What: /sys/power/disk
Date: September 2006
......
......@@ -97,6 +97,9 @@ endif # HAVE_SPHINX
# The following targets are independent of HAVE_SPHINX, and the rules should
# work or silently pass without Sphinx.
refcheckdocs:
$(Q)cd $(srctree);scripts/documentation-file-ref-check
cleandocs:
$(Q)rm -rf $(BUILDDIR)
$(Q)$(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/media clean
......@@ -109,6 +112,7 @@ dochelp:
@echo ' epubdocs - EPUB'
@echo ' xmldocs - XML'
@echo ' linkcheckdocs - check for broken external links (will connect to external hosts)'
@echo ' refcheckdocs - check for references to non-existing files under Documentation'
@echo ' cleandocs - clean all generated files'
@echo
@echo ' make SPHINXDIRS="s1 s2" [target] Generate only docs of folder s1, s2'
......@@ -116,3 +120,5 @@ dochelp:
@echo
@echo ' make SPHINX_CONF={conf-file} [target] use *additional* sphinx-build'
@echo ' configuration. This is e.g. useful to build with nit-picking config.'
@echo
@echo ' Default location for the generated documents is Documentation/output'
......@@ -527,7 +527,7 @@ grace period also drove it to completion.
This straightforward approach had the disadvantage of needing to
account for POSIX signals sent to user tasks,
so more recent implemementations use the Linux kernel's
<a href="https://www.kernel.org/doc/Documentation/workqueue.txt">workqueues</a>.
<a href="https://www.kernel.org/doc/Documentation/core-api/workqueue.rst">workqueues</a>.
<p>
The requesting task still does counter snapshotting and funnel-lock
......
......@@ -350,7 +350,7 @@ If something goes wrong
help debugging the problem. The text above the dump is also
important: it tells something about why the kernel dumped code (in
the above example, it's due to a bad kernel pointer). More information
on making sense of the dump is in Documentation/admin-guide/oops-tracing.rst
on making sense of the dump is in Documentation/admin-guide/bug-hunting.rst
- If you compiled the kernel with CONFIG_KALLSYMS you can send the dump
as is, otherwise you will have to use the ``ksymoops`` program to make
......
......@@ -240,7 +240,7 @@ In order to report it upstream, you should identify the mailing list
used for the development of the affected code. This can be done by using
the ``get_maintainer.pl`` script.
For example, if you find a bug at the gspca's conex.c file, you can get
For example, if you find a bug at the gspca's sonixj.c file, you can get
their maintainers with::
$ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
......@@ -257,7 +257,7 @@ Please notice that it will point to:
Tejun and Bhaktipriya (in this specific case, none really envolved on the
development of this file);
- The driver maintainer (Hans Verkuil);
- The subsystem maintainer (Mauro Carvalho Chehab)
- The subsystem maintainer (Mauro Carvalho Chehab);
- The driver and/or subsystem mailing list (linux-media@vger.kernel.org);
- the Linux Kernel mailing list (linux-kernel@vger.kernel.org).
......@@ -274,14 +274,14 @@ Fixing the bug
--------------
If you know programming, you could help us by not only reporting the bug,
but also providing us with a solution. After all open source is about
but also providing us with a solution. After all, open source is about
sharing what you do and don't you want to be recognised for your genius?
If you decide to take this way, once you have worked out a fix please submit
it upstream.
Please do read
ref:`Documentation/process/submitting-patches.rst <submittingpatches>` though
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` though
to help your code get accepted.
......
......@@ -314,7 +314,7 @@
amijoy.map= [HW,JOY] Amiga joystick support
Map of devices attached to JOY0DAT and JOY1DAT
Format: <a>,<b>
See also Documentation/input/joystick.txt
See also Documentation/input/joydev/joystick.rst
analog.map= [HW,JOY] Analog joystick and gamepad support
Specifies type or capabilities of an analog joystick
......@@ -439,7 +439,7 @@
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
bttv.pll= See Documentation/media/v4l-drivers/bttv.rst
bttv.tuner=
bulk_remove=off [PPC] This parameter disables the use of the pSeries
......@@ -641,8 +641,8 @@
For now, only VisioBraille is supported.
consoleblank= [KNL] The console blank (screen saver) timeout in
seconds. Defaults to 10*60 = 10mins. A value of 0
disables the blank timer.
seconds. A value of 0 disables the blank timer.
Defaults to 0.
coredump_filter=
[KNL] Change the default value for
......@@ -724,7 +724,7 @@
db9.dev[2|3]= [HW,JOY] Multisystem joystick support via parallel port
(one device per port)
Format: <port#>,<type>
See also Documentation/input/joystick-parport.txt
See also Documentation/input/devices/joystick-parport.rst
ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot
time. See
......@@ -1220,7 +1220,7 @@
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
support via parallel port (up to 5 devices per port)
Format: <port#>,<pad1>,<pad2>,<pad3>,<pad4>,<pad5>
See also Documentation/input/joystick-parport.txt
See also Documentation/input/devices/joystick-parport.rst
gamma= [HW,DRM]
......@@ -1766,7 +1766,7 @@
ivrs_acpihid[00:14.5]=AMD0020:0
js= [HW,JOY] Analog joystick
See Documentation/input/joystick.txt.
See Documentation/input/joydev/joystick.rst.
nokaslr [KNL]
When CONFIG_RANDOMIZE_BASE is set, this disables
......@@ -2248,10 +2248,10 @@
s2idle - Suspend-To-Idle
shallow - Power-On Suspend or equivalent (if supported)
deep - Suspend-To-RAM or equivalent (if supported)
See Documentation/power/states.txt.
See Documentation/admin-guide/pm/sleep-states.rst.
meye.*= [HW] Set MotionEye Camera parameters
See Documentation/video4linux/meye.txt.
See Documentation/media/v4l-drivers/meye.rst.
mfgpt_irq= [IA-32] Specify the IRQ to use for the
Multi-Function General Purpose Timers on AMD Geode
......@@ -3134,7 +3134,7 @@
plip= [PPT,NET] Parallel port network link
Format: { parport<nr> | timid | 0 }
See also Documentation/parport.txt.
See also Documentation/admin-guide/parport.rst.
pmtmr= [X86] Manual setup of pmtmr I/O Port.
Override pmtimer IOPort with a hex value.
......@@ -3885,6 +3885,12 @@
[KNL] Should the soft-lockup detector generate panics.
Format: <integer>
A nonzero value instructs the soft-lockup detector
to panic the machine when a soft-lockup occurs. This
is also controlled by CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC
which is the respective build-time switch to that
functionality.
softlockup_all_cpu_backtrace=
[KNL] Should the soft-lockup detector generate
backtraces on all cpus.
......@@ -4199,7 +4205,7 @@
TurboGraFX parallel port interface
Format:
<port#>,<js1>,<js2>,<js3>,<js4>,<js5>,<js6>,<js7>
See also Documentation/input/joystick-parport.txt
See also Documentation/input/devices/joystick-parport.rst
udbg-immortal [PPC] When debugging early kernel crashes that
happen after console_init() and before a proper
......
......@@ -94,7 +94,7 @@ step-by-step instructions for how a user can trigger the bug.
If the failure includes an "OOPS:", take a picture of the screen, capture
a netconsole trace, or type the message from your screen into the bug
report. Please read "Documentation/admin-guide/oops-tracing.rst" before posting your
report. Please read "Documentation/admin-guide/bug-hunting.rst" before posting your
bug report. This explains what you should do with the "Oops" information
to make it useful to the recipient.
......@@ -120,7 +120,7 @@ summary from [1.]>" for easy identification by the developers::
[4.2.] Kernel .config file:
[5.] Most recent kernel version which did not have the bug:
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/admin-guide/oops-tracing.rst)
resolved (see Documentation/admin-guide/bug-hunting.rst)
[7.] A small shell script or example program which triggers the
problem (if possible)
[8.] Environment
......
......@@ -55,13 +55,9 @@ This driver provides the following features:
(to compile support as a module which can be loaded and unloaded)
to the options:
Enhanced IDE/MFM/RLL disk/cdrom/tape/floppy support
ATA/ATAPI/MFM/RLL support
Include IDE/ATAPI CDROM support
and `no' to
Use old disk-only driver on primary interface
Depending on what type of IDE interface you have, you may need to
specify additional configuration options. See
Documentation/ide/ide.txt.
......
......@@ -2,11 +2,9 @@
The Linux Kernel API
====================
Data Types
==========
Doubly Linked Lists
-------------------
List Management Functions
=========================
.. kernel-doc:: include/linux/list.h
:internal:
......@@ -55,12 +53,27 @@ The Linux kernel provides more basic utility functions.
Bitmap Operations
-----------------
.. kernel-doc:: lib/bitmap.c
:doc: bitmap introduction
.. kernel-doc:: include/linux/bitmap.h
:doc: declare bitmap
.. kernel-doc:: include/linux/bitmap.h
:doc: bitmap overview
.. kernel-doc:: include/linux/bitmap.h
:doc: bitmap bitops
.. kernel-doc:: lib/bitmap.c
:export:
.. kernel-doc:: lib/bitmap.c
:internal:
.. kernel-doc:: include/linux/bitmap.h
:internal:
Command-line Parsing
--------------------
......@@ -70,13 +83,16 @@ Command-line Parsing
CRC Functions
-------------
.. kernel-doc:: lib/crc4.c
:export:
.. kernel-doc:: lib/crc7.c
:export:
.. kernel-doc:: lib/crc16.c
.. kernel-doc:: lib/crc8.c
:export:
.. kernel-doc:: lib/crc-itu-t.c
.. kernel-doc:: lib/crc16.c
:export:
.. kernel-doc:: lib/crc32.c
......@@ -84,6 +100,9 @@ CRC Functions
.. kernel-doc:: lib/crc-ccitt.c
:export:
.. kernel-doc:: lib/crc-itu-t.c
:export:
idr/ida Functions
-----------------
......@@ -96,6 +115,30 @@ idr/ida Functions
.. kernel-doc:: lib/idr.c
:export:
Math Functions in Linux
=======================
Base 2 log and power Functions
------------------------------
.. kernel-doc:: include/linux/log2.h
:internal:
Division Functions
------------------
.. kernel-doc:: include/asm-generic/div64.h
:functions: do_div
.. kernel-doc:: include/linux/math64.h
:internal:
.. kernel-doc:: lib/div64.c
:functions: div_s64_rem div64_u64_rem div64_u64 div64_s64
.. kernel-doc:: lib/gcd.c
:export:
Memory Management in Linux
==========================
......
......@@ -209,7 +209,7 @@ err.log will now have the profiling information, while stdout will
provide some progress information as Coccinelle moves forward with
work.
DEBUG_FILE support is only supported when using coccinelle >= 1.2.
DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
.cocciconfig support
--------------------
......
......@@ -31,6 +31,17 @@ To build and run the tests with a single command, use::
Note that some tests will require root privileges.
Build and run from user specific object directory (make O=dir)::
$ make O=/tmp/kselftest kselftest
Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=)::
$ make KBUILD_OUTPUT=/tmp/kselftest kselftest
The above commands run the tests and print pass/fail summary to make it
easier to understand the test results. Please find the detailed individual
test results for each test in /tmp/testname file(s).
Running a subset of selftests
=============================
......@@ -46,10 +57,21 @@ You can specify multiple tests to build and run::
$ make TARGETS="size timers" kselftest
Build and run from user specific object directory (make O=dir)::
$ make O=/tmp/kselftest TARGETS="size timers" kselftest
Build and run KBUILD_OUTPUT directory (make KBUILD_OUTPUT=)::
$ make KBUILD_OUTPUT=/tmp/kselftest TARGETS="size timers" kselftest
The above commands run the tests and print pass/fail summary to make it
easier to understand the test results. Please find the detailed individual
test results for each test in /tmp/testname file(s).
See the top-level tools/testing/selftests/Makefile for the list of all
possible targets.
Running the full range hotplug selftests
========================================
......@@ -113,9 +135,17 @@ Contributing new tests (details)
* Use TEST_GEN_XXX if such binaries or files are generated during
compiling.
TEST_PROGS, TEST_GEN_PROGS mean it is the excutable tested by
TEST_PROGS, TEST_GEN_PROGS mean it is the executable tested by
default.
TEST_CUSTOM_PROGS should be used by tests that require custom build
rule and prevent common build rule use.
TEST_PROGS are for test shell scripts. Please ensure shell script has
its exec bit set. Otherwise, lib.mk run_tests will generate a warning.
TEST_CUSTOM_PROGS and TEST_PROGS will be run by common run_tests.
TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
executable which is not tested by default.
TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
......
00-INDEX
- this file.
client.txt
-the DMA Engine API Guide.
dmatest.txt
- how to compile, configure and use the dmatest system.
provider.txt
- the DMA controller API.
\ No newline at end of file
PXA/MMP - DMA Slave controller
==============================
Constraints
-----------
a) Transfers hot queuing
A driver submitting a transfer and issuing it should be granted the transfer
is queued even on a running DMA channel.
This implies that the queuing doesn't wait for the previous transfer end,
and that the descriptor chaining is not only done in the irq/tasklet code
triggered by the end of the transfer.
A transfer which is submitted and issued on a phy doesn't wait for a phy to
stop and restart, but is submitted on a "running channel". The other
drivers, especially mmp_pdma waited for the phy to stop before relaunching
a new transfer.
b) All transfers having asked for confirmation should be signaled
Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call.
This implies that even if an irq/tasklet is triggered by end of tx1, but
at the time of irq/dma tx2 is already finished, tx1->complete() and
tx2->complete() should be called.
c) Channel running state
A driver should be able to query if a channel is running or not. For the
multimedia case, such as video capture, if a transfer is submitted and then
a check of the DMA channel reports a "stopped channel", the transfer should
not be issued until the next "start of frame interrupt", hence the need to
know if a channel is in running or stopped state.
d) Bandwidth guarantee
The PXA architecture has 4 levels of DMAs priorities : high, normal, low.
The high priorities get twice as much bandwidth as the normal, which get twice
as much as the low priorities.
A driver should be able to request a priority, especially the real-time
ones such as pxa_camera with (big) throughputs.
Design
------
a) Virtual channels
Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
channel" linked to the requestor line, and the physical DMA channel is
assigned on the fly when the transfer is issued.
b) Transfer anatomy for a scatter-gather transfer
+------------+-----+---------------+----------------+-----------------+
| desc-sg[0] | ... | desc-sg[last] | status updater | finisher/linker |
+------------+-----+---------------+----------------+-----------------+
This structure is pointed by dma->sg_cpu.
The descriptors are used as follows :
- desc-sg[i]: i-th descriptor, transferring the i-th sg
element to the video buffer scatter gather
- status updater
Transfers a single u32 to a well known dma coherent memory to leave
a trace that this transfer is done. The "well known" is unique per
physical channel, meaning that a read of this value will tell which
is the last finished transfer at that point in time.
- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
- linker: has ddadr= desc-sg[0] of next transfer, dcmd=0
c) Transfers hot-chaining
Suppose the running chain is :
Buffer 1 Buffer 2
+---------+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+---+
| |
+----+
After a call to dmaengine_submit(b3), the chain will look like :
Buffer 1 Buffer 2 Buffer 3
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
| | | |
+----+ +----+
new_link
If while new_link was created the DMA channel stopped, it is _not_
restarted. Hot-chaining doesn't break the assumption that
dma_async_issue_pending() is to be used to ensure the transfer is actually started.
One exception to this rule :
- if Buffer1 and Buffer2 had all their addresses 8 bytes aligned
- and if Buffer3 has at least one address not 4 bytes aligned
- then hot-chaining cannot happen, as the channel must be stopped, the
"align bit" must be set, and the channel restarted As a consequence,
such a transfer tx_submit() will be queued on the submitted queue, and
this specific case if the DMA is already running in aligned mode.
d) Transfers completion updater
Each time a transfer is completed on a channel, an interrupt might be
generated or not, up to the client's request. But in each case, the last
descriptor of a transfer, the "status updater", will write the latest
transfer being completed into the physical channel's completion mark.
This will speed up residue calculation, for large transfers such as video
buffers which hold around 6k descriptors or more. This also allows without
any lock to find out what is the latest completed transfer in a running
DMA chain.
e) Transfers completion, irq and tasklet
When a transfer flagged as "DMA_PREP_INTERRUPT" is finished, the dma irq
is raised. Upon this interrupt, a tasklet is scheduled for the physical
channel.
The tasklet is responsible for :
- reading the physical channel last updater mark
- calling all the transfer callbacks of finished transfers, based on
that mark, and each transfer flags.
If a transfer is completed while this handling is done, a dma irq will
be raised, and the tasklet will be scheduled once again, having a new
updater mark.
f) Residue
Residue granularity will be descriptor based. The issued but not completed
transfers will be scanned for all of their descriptors against the
currently running descriptor.
g) Most complicated case of driver's tx queues
The most tricky situation is when :
- there are not "acked" transfers (tx0)
- a driver submitted an aligned tx1, not chained
- a driver submitted an aligned tx2 => tx2 is cold chained to tx1
- a driver issued tx1+tx2 => channel is running in aligned mode
- a driver submitted an aligned tx3 => tx3 is hot-chained
- a driver submitted an unaligned tx4 => tx4 is put in submitted queue,
not chained
- a driver issued tx4 => tx4 is put in issued queue, not chained
- a driver submitted an aligned tx5 => tx5 is put in submitted queue, not
chained
- a driver submitted an aligned tx6 => tx6 is put in submitted queue,
cold chained to tx5
This translates into (after tx4 is issued) :
- issued queue
+-----+ +-----+ +-----+ +-----+
| tx1 | | tx2 | | tx3 | | tx4 |
+---|-+ ^---|-+ ^-----+ +-----+
| | | |
+---+ +---+
- submitted queue
+-----+ +-----+
| tx5 | | tx6 |
+---|-+ ^-----+
| |
+---+
- completed queue : empty
- allocated queue : tx0
It should be noted that after tx3 is completed, the channel is stopped, and
restarted in "unaligned mode" to handle tx4.
Author: Robert Jarzmik <robert.jarzmik@free.fr>
......@@ -65,7 +65,7 @@ Without options, the kernel-doc directive includes all documentation comments
from the source file.
The kernel-doc extension is included in the kernel source tree, at
``Documentation/sphinx/kernel-doc.py``. Internally, it uses the
``Documentation/sphinx/kerneldoc.py``. Internally, it uses the
``scripts/kernel-doc`` script to extract the documentation comments from the
source.
......
DMA Test Guide
==============
==============
DMA Test Guide
==============
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This small document introduces how to test DMA drivers using dmatest module.
Part 1 - How to build the test module
Part 1 - How to build the test module
=====================================
The menuconfig contains an option that could be found by following path:
Device Drivers -> DMA Engine support -> DMA Test client
......@@ -13,25 +15,31 @@ The menuconfig contains an option that could be found by following path:
In the configuration file the option called CONFIG_DMATEST. The dmatest could
be built as module or inside kernel. Let's consider those cases.
Part 2 - When dmatest is built as a module...
Part 2 - When dmatest is built as a module
==========================================
Example of usage:
% modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1
Example of usage: ::
...or:
% modprobe dmatest
% echo dma0chan0 > /sys/module/dmatest/parameters/channel
% echo 2000 > /sys/module/dmatest/parameters/timeout
% echo 1 > /sys/module/dmatest/parameters/iterations
% echo 1 > /sys/module/dmatest/parameters/run
% modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1
...or on the kernel command line:
...or: ::
dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1
% modprobe dmatest
% echo dma0chan0 > /sys/module/dmatest/parameters/channel
% echo 2000 > /sys/module/dmatest/parameters/timeout
% echo 1 > /sys/module/dmatest/parameters/iterations
% echo 1 > /sys/module/dmatest/parameters/run
Hint: available channel list could be extracted by running the following
command:
% ls -1 /sys/class/dma/
...or on the kernel command line: ::
dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1
..hint:: available channel list could be extracted by running the following
command:
::
% ls -1 /sys/class/dma/
Once started a message like "dmatest: Started 1 threads using dma0chan0" is
emitted. After that only test failure messages are reported until the test
......@@ -39,8 +47,9 @@ stops.
Note that running a new test will not stop any in progress test.
The following command returns the state of the test.
% cat /sys/module/dmatest/parameters/run
The following command returns the state of the test. ::
% cat /sys/module/dmatest/parameters/run
To wait for test completion userpace can poll 'run' until it is false, or use
the wait parameter. Specifying 'wait=1' when loading the module causes module
......@@ -50,15 +59,19 @@ before returning. For example, the following scripts wait for 42 tests
to complete before exiting. Note that if 'iterations' is set to 'infinite' then
waiting is disabled.
Example:
% modprobe dmatest run=1 iterations=42 wait=1
% modprobe -r dmatest
...or:
% modprobe dmatest run=1 iterations=42
% cat /sys/module/dmatest/parameters/wait
% modprobe -r dmatest
Example: ::
% modprobe dmatest run=1 iterations=42 wait=1
% modprobe -r dmatest
Part 3 - When built-in in the kernel...
...or: ::
% modprobe dmatest run=1 iterations=42
% cat /sys/module/dmatest/parameters/wait
% modprobe -r dmatest
Part 3 - 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
......@@ -66,27 +79,32 @@ re-run with the same or different parameters. For the details see the above
section "Part 2 - When dmatest is built as a module..."
In both cases the module parameters are used as the actual values for the test
case. You always could check them at run-time by running