From: "Rob Herring (Arm)" <robh@kernel.org>
To: Marcelo Schmitt <marcelo.schmitt@analog.com>
Cc: jic23@kernel.org, krzk+dt@kernel.org, dlechner@baylibre.com,
linux-kernel@vger.kernel.org, nuno.sa@analog.com,
andy@kernel.org, marcelo.schmitt1@gmail.com,
skhan@linuxfoundation.org, Michael.Hennerich@analog.com,
linux-iio@vger.kernel.org, conor+dt@kernel.org, linux@analog.com,
corbet@lwn.net, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 09/13] dt-bindings: iio: adc: adi,ad4134: Document external multiplexer usage
Date: Wed, 30 Sep 2026 07:16:02 -0500 [thread overview]
Message-ID: <179077056179.2288166.13408399366910214654.robh@kernel.org> (raw)
In-Reply-To: <4c6b88d4332a3fd6d4c3f7a65478b24d2015226f.1790719425.git.marcelo.schmitt@analog.com>
On Tue, 29 Sep 2026 19:44:42 -0300, Marcelo Schmitt wrote:
> The AD4134 design has two data interfaces. One interface allows register
> access for device configuration while the other (separate interface)
> provides ADC sample data. One way of handling both peripheral interfaces is
> to merge them into a single SPI interface by switching between register
> access and sample access according to device user requests. Though, such
> solution requires extra hardware, external to the ADC chip. The access mode
> switch can be done with an external multiplexer selecting either AD4134 SDO
> or AD4134 DOUT0 to connect to the controller. The external multiplexer
> becomes part of hardware requested for AD4134 device operation and thus
> must be provided for operating the peripheral in such merged interface
> schema. Still, there are alternative ways of handling the two AD4134 data
> interfaces so the multiplexer is not always required.
>
> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> ---
> Change log v2 -> v3:
> - Included the example right away with the doc update that documents it.
> - Dropped mux provider from offload example.
>
> Currently, SPI offloading is only supported in 4 wire mode. So, offloading
> wouldn't be usable if added before the 4-wire patch.
>
>
> Detailed reasoning for the external multiplexer usage.
>
> Before coming to the current solution, the following configuration was tried.
>
> +-----------------------+ +-----------------+
> | AD4134 | | SPI Controller |
> | | | |
> | SPI interface | | |
> | for register SCLK |<--------------------------| SCLK |
> | access CS |<--------------------------| CS |
> | SDI |<--------------------------| SDO |
> | SDO |---+ | |
> | | | | |
> | Data interface DOUT0 |---+---------------------->| SDI0 |
> | for ADC data DOUT1 |-------------------------->| SDI1 |
> | read back DOUT2 |-------------------------->| SDI2 |
> | DOUT3 |-------------------------->| SDI3 |
> | DCLK |<--------------------------| DCLK
> | ODR |<------------------+ +->| Offload Trigger |
> +-----------------------+ | | +-----------------+
> | +--| PWM1 |
> +-------| PWM0 |
> +-------| GPIO |
> +-----------------+
>
> Though, because DOUT0 never goes high-Z, the DOUT0 pin keeps driving the data
> line, causing register reads to fail.
>
> Alternatively, we could have something like
>
> +-----------------------+ +-----------------+
> | AD4134 | | SPI Controller |
> | | | |
> | SPI interface | | |
> | for register SCLK |<--------------------------| SCLK |
> | access CS |<--------------------------| CS |
> | SDI |<--------------------------| SDO |
> | SDO |-------------------------->| SDI0 |
> | | | |
> | Data interface DOUT0 |-------------------------->| SDI1 |
> | for ADC data DOUT1 |-------------------------->| SDI2 |
> | read back DOUT2 |-------------------------->| SDI3 |
> | DOUT3 |-------------------------->| SDI4 |
> | DCLK |<--------------------------| DCLK
> | ODR |<------------------+ +->| Offload Trigger |
> +-----------------------+ | | +-----------------+
> | +--| PWM1 |
> +-------| PWM0 |
> +-------| GPIO |
> +-----------------+
>
> The downside of the above is the peripheral would need fine-grained config of
> controller SDI lines to only read SDI0 for register access, and only read SDI1,
> SDI2, SDI3, SDI4 for ADC sample data (currently available
> SPI_MULTI_LANE_MODE_STRIPE reads from all SDI lines).
>
> The currently proposed solution looks like the following
>
> +-----------------------+ +-----------------+
> | AD4134 | | SPI Controller |
> | | | |
> | SPI interface SCLK |<------------------------| SCLK |
> | for register CS |<------------------------| CS |
> | access SDI |<------------------------| SDO |
> | SDO |------->|¯¯¯¯\ | |
> | | |MUX >--------->| SDI0 |
> | Data interface DOUT0 |------->|____/ | |
> | for ADC sample | ^ | |
> | data read DOUT1 |------------------------>| SDI1 |
> | DOUT2 |------------------------>| SDI2 |
> | DOUT3 |------------------------>| SDI3 |
> | DCLK |<------------------------| DCLK |
> | ODR |<----------------+ +->| Offload Trigger |
> +-----------------------+ | | | +-----------------+
> | | +--| PWM1 |
> | +-------| PWM0 |
> | +-------| GPIO0 |
> +--------------| GPIO1 |
> +-----------------+
>
> By being able to mux between AD4134 SDO and AD4134 DOUT0, the peripheral can be
> connected to a single bus such that controllers able to read from multiple lines
> will be able to gather ADC sample data from all SDI lines (SPI_MULTI_LANE_MODE_STRIPE).
> With that, AD4134 maximum data throughput can be supported with what is already
> available from the SPI core. See additional details on the AD4134 IIO
> documentation (patch 13).
>
> Yet another possibility would be to have the peripheral sitting in two buses.
>
> +-----------------------+ +-----------------+
> | AD4134 | | SPI Controller A|
> | | | |
> | SPI interface SCLK |<--------------------------| SCLK |
> | for register CS |<--------------------------| CS |
> | access SDI |<--------------------------| SDO |
> | SDO |-------------------------->| SDI |
> | | +-----------------+
> | | | SPI Controller B|
> | | | |
> | Data interface DOUT0 |-------------------------->| SDI0 |
> | for ADC sample DOUT1 |-------------------------->| SDI1 |
> | data read DOUT2 |-------------------------->| SDI2 |
> | DOUT3 |-------------------------->| SDI3 |
> | DCLK |<--------------------------| DCLK |
> | ODR |<------------------+ +->| Offload Trigger |
> +-----------------------+ | | +-----------------+
> | +--| PWM1 |
> +-------| PWM0 |
> +-------| GPIO |
> +-----------------+
>
> That may be a fallback option if what's currently being proposed fails to comply
> to Linux code standards.
>
>
> .../bindings/iio/adc/adi,ad4134.yaml | 47 +++++++++++++++++++
> 1 file changed, 47 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
next prev parent reply other threads:[~2026-09-30 12:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 22:41 [PATCH v3 00/13] iio: adc: ad4134: Enable greater sample rate data capture Marcelo Schmitt
2026-09-29 22:42 ` [PATCH v3 01/13] iio: adc: ad4134: Adjust register map range Marcelo Schmitt
2026-09-29 22:42 ` [PATCH v3 02/13] iio: adc: ad4134: Sign extend sample data Marcelo Schmitt
2026-09-30 8:50 ` Joshua Crofts
2026-09-29 22:42 ` [PATCH v3 03/13] iio: adc: ad4134: Update include list to comply with IWYU principles Marcelo Schmitt
2026-09-29 22:43 ` [PATCH v3 04/13] iio: adc: ad4134: Serialize single-read operations Marcelo Schmitt
2026-09-29 22:43 ` [PATCH v3 05/13] iio: adc: ad4134: Run shorter transfers when CRC is disabled Marcelo Schmitt
2026-09-29 22:43 ` [PATCH v3 06/13] iio: adc: ad4134: Add support for digital filter type selection Marcelo Schmitt
2026-09-29 22:44 ` [PATCH v3 07/13] iio: adc: ad4134: Support buffered data read Marcelo Schmitt
[not found] ` <20260929230528.8861C1F000FF@smtp.kernel.org>
2026-09-30 18:54 ` Marcelo Schmitt
2026-09-29 22:44 ` [PATCH v3 08/13] dt-bindings: iio: adc: adi,ad4134: Document SPI connection mode Marcelo Schmitt
2026-09-30 11:51 ` Rob Herring (Arm)
2026-09-30 12:15 ` Rob Herring
[not found] ` <20260929230226.DDDAE1F00898@smtp.kernel.org>
2026-09-30 18:23 ` Marcelo Schmitt
2026-09-30 22:29 ` Conor Dooley
2026-09-29 22:44 ` [PATCH v3 09/13] dt-bindings: iio: adc: adi,ad4134: Document external multiplexer usage Marcelo Schmitt
2026-09-30 12:16 ` Rob Herring (Arm) [this message]
2026-09-29 22:45 ` [PATCH v3 10/13] iio: adc: ad4134: Support SPI 4-wire mode Marcelo Schmitt
[not found] ` <20260929230830.A8F3A1F000FF@smtp.kernel.org>
2026-09-30 19:39 ` Marcelo Schmitt
2026-09-29 22:45 ` [PATCH v3 11/13] dt-bindings: iio: adc: adi,ad4134: Document PWM usage Marcelo Schmitt
2026-09-29 22:45 ` [PATCH v3 12/13] iio: adc: ad4134: Support high-speed data capture Marcelo Schmitt
2026-09-30 9:42 ` Andy Shevchenko
[not found] ` <20260929231610.BA7C31F000FF@smtp.kernel.org>
2026-09-30 19:59 ` Marcelo Schmitt
2026-09-29 22:46 ` [PATCH v3 13/13] Docs: iio: Add AD4134 Marcelo Schmitt
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=179077056179.2288166.13408399366910214654.robh@kernel.org \
--to=robh@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@analog.com \
--cc=marcelo.schmitt1@gmail.com \
--cc=marcelo.schmitt@analog.com \
--cc=nuno.sa@analog.com \
--cc=skhan@linuxfoundation.org \
/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
all inboxes | Powered by JetHome®