[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0bfce1eb-69f1-4dae-b461-234eb98ffce1@linaro.org>
Date: Thu, 4 Sep 2025 19:40:32 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: Nuno Sá <noname.nuno@...il.com>, jic23@...nel.org,
dlechner@...libre.com, nuno.sa@...log.com, andy@...nel.org, robh@...nel.org,
conor+dt@...nel.org, krzk+dt@...nel.org
Cc: linux-iio@...r.kernel.org, s32@....com, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, chester62515@...il.com, mbrugger@...e.com,
ghennadi.procopciuc@....nxp.com
Subject: Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the
s32g2/3 platforms
Hi Nuno,
On 03/09/2025 13:20, Nuno Sá wrote:
> On Wed, 2025-09-03 at 12:27 +0200, Daniel Lezcano wrote:
>> From: Stefan-Gabriel Mirea <stefan-gabriel.mirea@....com>
>>
>> The NXP S32G2 and S32G3 platforms integrate a successive approximation
>> register (SAR) ADC. Two instances are available, each providing 8
>> multiplexed input channels with 12-bit resolution. The conversion rate
>> is up to 1 Msps depending on the configuration and sampling window.
>>
>> The SAR ADC supports raw, buffer, and trigger modes. It can operate
>> in both single-shot and continuous conversion modes, with optional
>> hardware triggering through the cross-trigger unit (CTU) or external
>> events. An internal prescaler allows adjusting the sampling clock,
>> while per-channel programmable sampling times provide fine-grained
>> trade-offs between accuracy and latency. Automatic calibration is
>> performed at probe time to minimize offset and gain errors.
>>
>> The driver is derived from the BSP implementation and has been partly
>> rewritten to comply with upstream requirements. For this reason, all
>> contributors are listed as co-developers, while the author refers to
>> the initial BSP driver file creator.
>>
>> All modes have been validated on the S32G274-RDB2 platform using an
>> externally generated square wave captured by the ADC. Tests covered
>> buffered streaming via IIO, trigger synchronization, and accuracy
>> verification against a precision laboratory signal source.
>>
>> Co-developed-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@....com>
>> Signed-off-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@....com>
>> Co-developed-by: Ciprian Costea <ciprianmarian.costea@....com>
>> Signed-off-by: Ciprian Costea <ciprianmarian.costea@....com>
>> Co-developed-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@....nxp.com>
>> Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@....nxp.com>
>> Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@....com>
>> Co-developed-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>> ---
[ ... ]
> The above needs some discussion at the very least. Have you considered the IIO
> DMA buffer interface? It should be extendable to accommodate any particularity
> of your usecase (or we should at least discuss it).
>
> With it, you also gain a userspace interface where you can actually share DMA
> buffers in a zero copy fashion. You can also share these buffers with USB
> gadgets. For instance, with libiio, you would be able to fetch samples from your
> host machine (through USB) in a very fast way (zero copy between IIO and USB).
>
> Setting up DMA to then "having" to push it to a SW buffer and needing a syscall
> to retrieve the data seems counter-productive.
I've read a bit about the DMA engine. It is unclear how to use it and
there are very few examples in the different drivers to refer to.
This proposed driver supports the RAW, BUFFER and TRIGGERED.
Shall I create an IIO device with the modes:
indio_dev->modes =
INDIO_DIRECT_MODE |
INDIO_BUFFER_HARDWARE |
INDIO_BUFFER_TRIGGERED
And then use:
devm_iio_triggered_buffer_setup()
and
devm_iio_dmaengine_buffer_setup_with_handle
?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
Powered by blists - more mailing lists