[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240817161352.61661418@jic23-huawei>
Date: Sat, 17 Aug 2024 16:13:52 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Guillaume Stols <gstols@...libre.com>
Cc: Uwe Kleine-König <ukleinek@...nel.org>, Lars-Peter
Clausen <lars@...afoo.de>, Michael Hennerich
<Michael.Hennerich@...log.com>, Rob Herring <robh@...nel.org>, Krzysztof
Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki"
<rafael@...nel.org>, Jonathan Corbet <corbet@....net>,
linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fbdev@...r.kernel.org, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
aardelean@...libre.com
Subject: Re: [PATCH 3/8] Documentation: iio: Document ad7606 driver
On Thu, 15 Aug 2024 12:11:57 +0000
Guillaume Stols <gstols@...libre.com> wrote:
> The Analog Devices Inc. AD7606 (and similar chips) are complex ADCs that
> will benefit from a detailed driver documentation.
>
> This documents the current features supported by the driver.
>
> Signed-off-by: Guillaume Stols <gstols@...libre.com>
A few typos that I spotted, but other than that lgtm
> ---
> Documentation/iio/ad7606.rst | 142 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 142 insertions(+)
>
> diff --git a/Documentation/iio/ad7606.rst b/Documentation/iio/ad7606.rst
> new file mode 100644
> index 000000000000..e9578399e80d
> --- /dev/null
> +++ b/Documentation/iio/ad7606.rst
> @@ -0,0 +1,142 @@
> +.. SPDX-License-Identifier: GPL-2.0-only
> +
> +=============
> +AD7606 driver
> +=============
> +
> +ADC driver for Analog Devices Inc. AD7606 and similar devices. The module name
> +is ``ad7606``.
> +
> +Supported devices
> +=================
> +
> +The following chips are supported by this driver:
> +
> +* `AD7605 <https://www.analog.com/en/products/ad7605.html>`_
> +* `AD7606 <https://www.analog.com/en/products/ad7606.html>`_
> +* `AD7606B <https://www.analog.com/en/products/ad7606b.html>`_
> +* `AD7616 <https://www.analog.com/en/products/ad7616.html>`_
> +
> +Supported features
> +==================
> +
> +SPI wiring modes
> +----------------
> +
> +ad7606x ADCs can output data on several SDO lines (1/2/4/8). The driver
> +currently supports only 1 SDO line.
> +
> +Parallel wiring mode
> +--------------------
> +
> +AD7606x ADC have also a parallel interface, with 16 lines (that can be reduced
> +to 8 in byte mode). The parallel interface is selected by declaring the device
> +as platform in the device tree (with no io-backends node defined, see below).
> +
> +IIO-backend mode
> +----------------
> +
> +This mode allows to reach the best sample rates, but it requires an external
> +hardware (eg HDL or APU) to handle the low level communication.
> +The backend mode is enabled when trough the definition of the "io-backends"
through. Spell check in general as I'm bad at spotting these.
> +property in the device tree.
> +The reference configuration for the current implementation of IIO-backend mode
> +is the HDL reference provided by ADI:
> +https://wiki.analog.com/resources/eval/user-guides/ad7606x-fmc/hdl
> +This implementation embeds an IIO-backend compatible IP (adi-axi-adc) and a PWM
> +connected to the conversion trigger pin.
> +
> ++---+ +----------------------------
> +| | +-------+ |AD76xx
> +| A | controls | | |
> +| D |-------------->| PWM |-------------->| cnvst
> +| 7 | | | |
> +| 6 | +-------+ |
> +| 0 | controls +-----------+------------ |
> +| 6 |---------->| | |<--| frstdata
> +| | | Backend | Backend |<--| busy
> +| D | | Driver | | |
> +| R | | | |-->| clk
> +| I | requests |+---------+| DMA | |
> +| V |----------->| Buffer ||<---- |<=>| DATA
> +| E | |+---------+| | |
> +| R | +-----------+-----------+ |
> +| |-------------------------------------->| reset/configuration gpios
> ++---+ +-----------------------------
> +
> +
> +Software and hardware modes
> +---------------------------
> +
> +While all the AD7606 series parts can be configured using GPIOs, some of them
> +can be configured using register.
I'd add blank lines between paragraphs as makes it easier to read as text
> +The chip that support software mode have more values avalaible for configuring
available
> +the device, as well as more settings, and allow to control the range and
> +calibration per channel.
> +The following settings are available per channel in software mode:
> + - Scale
> +Also, there is a broader choice of oversampling ratios in software mode.
> +
> +Conversion triggering
> +---------------------
> +
> +The conversion can be triggered by two distinct ways:
> +
> + - A GPIO is connected to the conversion trigger pin, and this GPIO is controlled
> + by the driver directly. In this configuration, the driver set back the
the driver sets back
> + conversion trigger pin to high as soon as it has read all the conversions.
> +
> + - An external source is connected to the conversion trigger pin. In the
> + current implementation, it must be a PWM. In this configuration, the driver
> + does not control directly the conversion trigger pin. Instead, it can
> + control the PWM's frequency. This trigger is enabled only for iio-backend.
> +
> +Reference voltage
> +-----------------
> +
> +2 possible reference voltage sources are supported:
> +
> + - Internal reference (2.5V)
> + - External reference (2.5V)
> +
> +The source is determined by the device tree. If ``refin-supply`` is present,
> +then the external reference is used, else the internal reference is used.
> +
> +Oversampling
> +------------
> +
> +This family supports oversampling to improve SNR.
> +In software mode, the following ratios are available:
> +1 (oversampling disabled)/2/4/8/16/32/64/128/256.
> +
> +Unimplemented features
> +----------------------
> +
> +- 2/4/8 SDO lines
> +- CRC indication
> +- Calibration
> +
> +Device buffers
> +==============
> +
> +IIO triggered buffer
> +--------------------
> +
> +This driver supports IIO triggered buffers, with a "built in" trigger, i.e the
> +trigger is allocated and linked by the driver, and a new conversion is triggered
> +as soon as the samples are transferred, and a timestamp channel is added to make
> +up for the potential jitter induced by the delays in the interrupt handling.
> +
> +IIO backend buffer
> +------------------
> +
> +When IIO backend is used, the trigger is not needed, and the sample rate is
> +considered as stable, hence there is no timestamp channel. The communication is
> +delegated to an external logic, called a backend, and the backend's driver
> +handles the buffer. When this mode is enabled, the driver cannot control the
> +conversion pin, because the busy pin is bound to the backend.
> +
> +
> +
> +
> +
Drop this trailing whitespace.
>
Powered by blists - more mailing lists