Merge tag 'docs-5.1' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet: "A fairly routine cycle for docs - lots of typo fixes, some new documents, and more translations. There's also some LICENSES adjustments from Thomas" * tag 'docs-5.1' of git://git.lwn.net/linux: (74 commits) docs: Bring some order to filesystem documentation Documentation/locking/lockdep: Drop last two chars of sample states doc: rcu: Suspicious RCU usage is a warning docs: driver-api: iio: fix errors in documentation Documentation/process/howto: Update for 4.x -> 5.x versioning docs: Explicitly state that the 'Fixes:' tag shouldn't split lines doc: security: Add kern-doc for lsm_hooks.h doc: sctp: Merge and clean up rst files Docs: Correct /proc/stat path scripts/spdxcheck.py: fix C++ comment style detection doc: fix typos in license-rules.rst Documentation: fix admin-guide/README.rst minimum gcc version requirement doc: process: complete removal of info about -git patches doc: translations: sync translations 'remove info about -git patches' perf-security: wrap paragraphs on 72 columns perf-security: elaborate on perf_events/Perf privileged users perf-security: document collected perf_events/Perf data categories perf-security: document perf_events/Perf resource control sysfs.txt: add note on available attribute macros docs: kernel-doc: typo "if ... if" -> "if ... is" ...
This commit is contained in:
@@ -168,6 +168,13 @@ The details of these operations are:
|
||||
dmaengine_submit() will not start the DMA operation, it merely adds
|
||||
it to the pending queue. For this, see step 5, dma_async_issue_pending.
|
||||
|
||||
.. note::
|
||||
|
||||
After calling ``dmaengine_submit()`` the submitted transfer descriptor
|
||||
(``struct dma_async_tx_descriptor``) belongs to the DMA engine.
|
||||
Consequentially, the client must consider invalid the pointer to that
|
||||
descriptor.
|
||||
|
||||
5. Issue pending DMA requests and wait for callback notification
|
||||
|
||||
The transactions in the pending queue can be activated by calling the
|
||||
|
@@ -26,7 +26,7 @@ IIO buffer setup
|
||||
================
|
||||
|
||||
The meta information associated with a channel reading placed in a buffer is
|
||||
called a scan element . The important bits configuring scan elements are
|
||||
called a scan element. The important bits configuring scan elements are
|
||||
exposed to userspace applications via the
|
||||
:file:`/sys/bus/iio/iio:device{X}/scan_elements/*` directory. This file contains
|
||||
attributes of the following form:
|
||||
|
@@ -2,8 +2,8 @@
|
||||
Core elements
|
||||
=============
|
||||
|
||||
The Industrial I/O core offers a unified framework for writing drivers for
|
||||
many different types of embedded sensors. a standard interface to user space
|
||||
The Industrial I/O core offers both a unified framework for writing drivers for
|
||||
many different types of embedded sensors and a standard interface to user space
|
||||
applications manipulating sensors. The implementation can be found under
|
||||
:file:`drivers/iio/industrialio-*`
|
||||
|
||||
@@ -11,7 +11,7 @@ Industrial I/O Devices
|
||||
----------------------
|
||||
|
||||
* struct :c:type:`iio_dev` - industrial I/O device
|
||||
* :c:func:`iio_device_alloc()` - alocate an :c:type:`iio_dev` from a driver
|
||||
* :c:func:`iio_device_alloc()` - allocate an :c:type:`iio_dev` from a driver
|
||||
* :c:func:`iio_device_free()` - free an :c:type:`iio_dev` from a driver
|
||||
* :c:func:`iio_device_register()` - register a device with the IIO subsystem
|
||||
* :c:func:`iio_device_unregister()` - unregister a device from the IIO
|
||||
|
@@ -1,7 +1,7 @@
|
||||
===========
|
||||
HW consumer
|
||||
===========
|
||||
An IIO device can be directly connected to another device in hardware. in this
|
||||
An IIO device can be directly connected to another device in hardware. In this
|
||||
case the buffers between IIO provider and IIO consumer are handled by hardware.
|
||||
The Industrial I/O HW consumer offers a way to bond these IIO devices without
|
||||
software buffer for data. The implementation can be found under
|
||||
|
@@ -38,7 +38,7 @@ There are two locations in sysfs related to triggers:
|
||||
|
||||
* :file:`/sys/bus/iio/devices/iio:device{X}/trigger/*`, this directory is
|
||||
created once the device supports a triggered buffer. We can associate a
|
||||
trigger with our device by writing the trigger's name in the
|
||||
trigger with our device by writing the trigger's name in the
|
||||
:file:`current_trigger` file.
|
||||
|
||||
IIO trigger setup
|
||||
|
Reference in New Issue
Block a user