From: Jonathan Cameron <jic23@kernel.org>
To: "Miclaus, Antoniu" <Antoniu.Miclaus@analog.com>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
"Hennerich, Michael" <Michael.Hennerich@analog.com>,
David Lechner <dlechner@baylibre.com>,
"Sa, Nuno" <Nuno.Sa@analog.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Olivier Moysan <olivier.moysan@foss.st.com>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
Date: Mon, 20 Apr 2026 15:29:14 +0100 [thread overview]
Message-ID: <20260420152914.323238fe@jic23-huawei> (raw)
In-Reply-To: <SN6SPR01MB0090FF0C73500BB51F63D7FB9B232@SN6SPR01MB0090.namprd03.prod.outlook.com>
On Thu, 16 Apr 2026 08:51:46 +0000
"Miclaus, Antoniu" <Antoniu.Miclaus@analog.com> wrote:
> --
> Antoniu Miclăuş
>
> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Sunday, April 12, 2026 9:34 PM
> > To: Miclaus, Antoniu <Antoniu.Miclaus@analog.com>
> > Cc: Lars-Peter Clausen <lars@metafoo.de>; Hennerich, Michael
> > <Michael.Hennerich@analog.com>; David Lechner <dlechner@baylibre.com>;
> > Sa, Nuno <Nuno.Sa@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > Olivier Moysan <olivier.moysan@foss.st.com>; linux-iio@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-
> > channel ADC
> >
> > [External]
> >
> > On Sat, 28 Mar 2026 13:40:47 +0200
> > Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> >
> > > Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
> > > integrated fully differential amplifiers (FDA).
> > >
> > > Architecture notes:
> > >
> > > The AD4880 is modeled as a single IIO device rather than two independent
> > > devices because the channels share power supplies, a voltage reference,
> > > the CNV conversion clock, and a single interleaved data output stream.
> > > Splitting them into separate IIO devices would make synchronized
> > > dual-channel capture impossible from userspace.
> > >
> > > An MFD approach does not apply here either - the channels are not
> > > functionally distinct sub-devices but identical ADC paths sharing a
> > > common data interface.
> > >
> > > Each channel has fully independent configuration registers accessible
> > > through separate SPI chip selects, so per-channel regmaps are used with
> > > no locking between them. The data path has no software involvement at
> > > runtime: the CNV clock triggers simultaneous conversions and the device
> > > outputs an interleaved bitstream captured directly by the IIO backend
> > > (FPGA). spi_new_ancillary_device() handles the configuration path;
> > > the IIO backend handles the data path.
> > >
> > > The debugfs_reg_access callback is not exposed for the dual-channel
> > > variant since the IIO framework provides a single (reg, val) interface
> > > with no channel parameter, and exposing only one channel would be
> > > misleading.
> > >
> > > The AD4880 is a fairly unique part - having separate SPI config
> > > interfaces per channel with a shared interleaved data output is not
> > > a common pattern.
> > I tried applying this and it's not going in cleanly (I didn't check
> > exactly why). Please could you send a rebased version. The togreg
> > branch should be fine I think, but maybe sanity check it against
> > my current testing branch as well.
>
> The AD4880 driver has a cross-tree dependency on two SPI patches that are queued in spi/for-7.1:
>
> - ffef4123043c ("spi: allow ancillary devices to share parent's chip selects")
> - 463279e58811 ("spi: add devm_spi_new_ancillary_device()")
>
> The driver uses devm_spi_new_ancillary_device() with multi-CS to create an ancillary SPI device for the second channel's configuration interface, so it won't build against togreg alone.
>
> What approach do you suggest in this situation?
Ah. Makes sense.
Given timing, wait and if I look to have forgotten this ping me around
rc2 when I should have that 7.1 material in my base tree anyway.
thanks,
Jonathan
>
> >
> > Whilst this driver is making a few more assumptions about the backend
> > than I'd ideally like, I think it is reasonable to postpone any handling
> > for truely separate backends until (maybe) someone needs it.
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > Changes in v8:
> > > - Drop fwnode_handle cleanup patch (now in jic23/testing)
> > > - Clarify backend buffer comment to describe FPGA architecture
> > > (two axi_ad408x IP instances with a packer block)
> > > - Make filter_type a per-channel array instead of a single variable
> > > - Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
> > > based on sashiko's review
> > >
> > > Antoniu Miclaus (3):
> > > iio: backend: add devm_iio_backend_get_by_index()
> > > dt-bindings: iio: adc: ad4080: add AD4880 support
> > > iio: adc: ad4080: add support for AD4880 dual-channel ADC
> > >
> > > .../bindings/iio/adc/adi,ad4080.yaml | 53 +++-
> > > drivers/iio/adc/ad4080.c | 251 ++++++++++++++----
> > > drivers/iio/industrialio-backend.c | 53 ++--
> > > include/linux/iio/backend.h | 1 +
> > > 4 files changed, 282 insertions(+), 76 deletions(-)
> > >
>
next prev parent reply other threads:[~2026-04-20 14:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-28 11:40 [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC Antoniu Miclaus
2026-03-28 11:40 ` [PATCH v8 1/3] iio: backend: add devm_iio_backend_get_by_index() Antoniu Miclaus
2026-03-28 11:40 ` [PATCH v8 2/3] dt-bindings: iio: adc: ad4080: add AD4880 support Antoniu Miclaus
2026-03-31 15:44 ` Rob Herring
2026-03-28 11:40 ` [PATCH v8 3/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC Antoniu Miclaus
2026-04-12 18:33 ` [PATCH v8 0/3] " Jonathan Cameron
2026-04-16 8:51 ` Miclaus, Antoniu
2026-04-20 14:29 ` Jonathan Cameron [this message]
2026-04-20 14:35 ` Miclaus, Antoniu
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=20260420152914.323238fe@jic23-huawei \
--to=jic23@kernel.org \
--cc=Antoniu.Miclaus@analog.com \
--cc=Michael.Hennerich@analog.com \
--cc=Nuno.Sa@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--cc=krzk+dt@kernel.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=olivier.moysan@foss.st.com \
--cc=robh@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.