From: Randy Dunlap <rdunlap@infradead.org>
To: Ramona Gradinariu <ramona.gradinariu@analog.com>,
corbet@lwn.net, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, jic23@kernel.org,
nuno.sa@analog.com, linux-iio@vger.kernel.org
Subject: Re: [PATCH v4 2/3] docs: iio: add documentation for device buffers
Date: Tue, 13 Feb 2024 17:13:13 -0800 [thread overview]
Message-ID: <6076dba6-496e-4cae-be76-a30e006d3b77@infradead.org> (raw)
In-Reply-To: <20240213081720.17549-3-ramona.gradinariu@analog.com>
On 2/13/24 00:17, Ramona Gradinariu wrote:
> Add documentation for IIO device buffers describing buffer
> attributes and how data is structured in buffers using
> scan elements.
>
> Signed-off-by: Ramona Gradinariu <ramona.gradinariu@analog.com>
> ---
> changes in v4:
> - documented multiple buffer support
> - reworked scan elements section
> - added reference to ABI docs
> Documentation/iio/iio_devbuf.rst | 125 +++++++++++++++++++++++++++++++
> Documentation/iio/index.rst | 1 +
> 2 files changed, 126 insertions(+)
> create mode 100644 Documentation/iio/iio_devbuf.rst
>
> diff --git a/Documentation/iio/iio_devbuf.rst b/Documentation/iio/iio_devbuf.rst
> new file mode 100644
> index 000000000000..e99143efb4d7
> --- /dev/null
> +++ b/Documentation/iio/iio_devbuf.rst
> @@ -0,0 +1,125 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +=============================
> +Industrial IIO device buffers
> +=============================
> +
> +1. Overview
> +===========
> +
> +The Industrial I/O core offers a way for continuous data capture based on a
> +trigger source. Multiple data channels can be read at once from
> +/dev/iio:deviceX character device node, thus reducing the CPU load.
> +
> +Devices with buffer support feature an additional sub-folder in the
folder or directory?
> +/sys/bus/iio/devices/deviceX/ folder hierarchy, called bufferY, where Y defaults
folder or directory?
> +to 0, for devices with a single buffer.
> +
> +2. Buffer attributes
> +====================
> +
> +An IIO buffer has an associated attributes directory under
directory or folder?
Just be consistent, please.
> +/sys/bus/iio/iio:deviceX/bufferY/. The attributes are described below.
> +
What are the corresponding attribute names?
> +Length
> +------
> +
> +Read / Write attribute which states the total number of data samples (capacity)
> +that can be stored by the buffer.
> +
> +Enable
> +------
> +
> +Read / Write attribute which starts / stops the buffer capture. This file should
> +be written last, after length and selection of scan elements.
> +
> +Watermark
> +---------
> +
> +Read / Write positive integer attribute specifying the maximum number of scan
> +elements to wait for.
> +
> +Poll will block until the watermark is reached.
> +
> +Blocking read will wait until the minimum between the requested read amount or
> +the low water mark is available.
watermark
> +
> +Non-blocking read will retrieve the available samples from the buffer even if
> +there are less samples then watermark level. This allows the application to
than the
> +block on poll with a timeout and read the available samples after the timeout
> +expires and thus have a maximum delay guarantee.
> +
> +Data available
> +--------------
> +
> +Read-only attribute indicating the bytes of data available in the buffer. In the
> +case of an output buffer, this indicates the amount of empty space available to
> +write data to. In the case of an input buffer, this indicates the amount of data
> +available for reading.
> +
> +Scan elements
> +-------------
> +
> +The meta information associated with a channel reading placed in a buffer is
That line gives me -ENOPARSE. Can it be improved?
> +called a scan element. The scan elements are configurable per buffer, thus they
> +are exposed to userspace applications via the /sys/bus/iio/iio:deviceX/bufferY/
> +directory. The scan elements attributes are presented below.
> +
> +**_en**
> +
> +Read/ Write attribute used for enabling a channel. If and only if its value
> +is non zero, then a triggered capture will contain data samples for this
non-zero,
> +channel.
> +
> +**_index**
> +
> +Read-only positive integer attribute specifying the position of the channel in
> +the buffer. Note these are not dependent on what is enabled and may not be
> +contiguous. Thus for user-space to establish the full layout these must be used
userspace
as above.
> +in conjunction with all _en attributes to establish which channels are present,
> +and the relevant _type attributes to establish the data storage format.
> +
> +**_type**
> +
> +Read-only attribute containing the description of the scan element data storage
> +within the buffer and hence the form in which it is read from user space. Format
> +is [be|le]:[s|u]bits/storagebits[Xrepeat][>>shift], where:
> +
> +- **be** or **le** specifies big or little endian.
> +- **s** or **u**, specifies if signed (2's complement) or unsigned.
no comma ^
> +- **bits**, is the number of valid data bits.
no comma ^
> +- **storagebits**, is the number of bits (after padding) that it occupies in the
no comma ^
> + buffer.
> +- **repeat**, specifies the number of bits/storagebits repetitions. When the
no comma ^
> + repeat element is 0 or 1, then the repeat value is omitted.
> +- **shift**, if specified, is the shift that needs to be applied prior to
no comma ^
> + masking out unused bits.
> +
> +For example, a driver for a 3-axis accelerometer with 12 bit resolution where
12-bit
> +data is stored in two 8-bits registers as follows:
8-bit is as follows:
> +
> +.. code-block:: bash
> +
> + 7 6 5 4 3 2 1 0
> + +---+---+---+---+---+---+---+---+
> + |D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06)
> + +---+---+---+---+---+---+---+---+
> +
> + 7 6 5 4 3 2 1 0
> + +---+---+---+---+---+---+---+---+
> + |D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07)
> + +---+---+---+---+---+---+---+---+
> +
> +will have the following scan element type for each axis:
> +
> +.. code-block:: bash
> +
> + $ cat /sys/bus/iio/devices/iio:device0/buffer0/in_accel_y_type
> + le:s12/16>>4
> +
> +A user space application will interpret data samples read from the buffer as two
userspace
for consistency.
as two-
> +byte little endian signed data, that needs a 4 bits right shift before masking
little-endian
> +out the 12 valid bits of data.
> +
> +Please see Documentation/ABI/testing/sysfs-bus-iio for a complete description of
> +the attributes.
> diff --git a/Documentation/iio/index.rst b/Documentation/iio/index.rst
> index db341b45397f..206a0aff5ca1 100644
> --- a/Documentation/iio/index.rst
> +++ b/Documentation/iio/index.rst
> @@ -8,6 +8,7 @@ Industrial I/O
> :maxdepth: 1
>
> iio_configfs
> + iio_devbuf
>
> Industrial I/O Kernel Drivers
> =============================
> --
> 2.34.1
>
>
--
#Randy
next prev parent reply other threads:[~2024-02-14 1:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-13 8:17 [PATCH v4 0/3] adis16475 driver documentation Ramona Gradinariu
2024-02-13 8:17 ` [PATCH v4 1/3] docs: iio: Refactor index.rst Ramona Gradinariu
2024-02-13 8:17 ` [PATCH v4 2/3] docs: iio: add documentation for device buffers Ramona Gradinariu
2024-02-13 23:58 ` David Lechner
2024-02-16 11:54 ` Jonathan Cameron
2024-02-14 1:13 ` Randy Dunlap [this message]
2024-02-13 8:17 ` [PATCH v4 3/3] docs: iio: add documentation for adis16475 driver Ramona Gradinariu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6076dba6-496e-4cae-be76-a30e006d3b77@infradead.org \
--to=rdunlap@infradead.org \
--cc=corbet@lwn.net \
--cc=jic23@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=ramona.gradinariu@analog.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox