linux-kernel - Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <edc8e024-e425-49de-bfa2-44218fe72e26@linaro.org>
Date: Fri, 5 Sep 2025 11:44:43 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: David Lechner <dlechner@...libre.com>, Nuno Sá
 <noname.nuno@...il.com>, jic23@...nel.org, 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

On 04/09/2025 19:49, David Lechner wrote:
> On 9/4/25 12:40 PM, Daniel Lezcano wrote:
>>
>> 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 |
> 
> Only INDIO_DIRECT_MODE needs to be set here.
> 
>>      INDIO_BUFFER_HARDWARE |
>>      INDIO_BUFFER_TRIGGERED
>>
>> And then use:
>>
>> devm_iio_triggered_buffer_setup()
> 
> Yes, use this and it will add INDIO_BUFFER_TRIGGERED to the flags.
> 
>>
>> and
>>
>> devm_iio_dmaengine_buffer_setup_with_handle
> 
> Likewise, this will add INDIO_BUFFER_HARDWARE.
> 
> And you likely only need to call devm_iio_dmaengine_buffer_setup() which will
> save some boilerplate code.

What is still unclear for me is the trigger and the dma modes.

If the dma engine is supported, I should use 
devm_iio_dmaengine_buffer_setup_with_handle(), but will the trigger mode 
be supported also automatically (I don't see a clear answer in the 
documentation neither in the drivers) ?

If not, shall I call 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