[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4e52440-fa96-486b-9c50-828fdbbe27eb@wanadoo.fr>
Date: Tue, 16 Sep 2025 22:53:28 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Daniel Lezcano <daniel.lezcano@...aro.org>, 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 v3 2/2] iio: adc: Add the NXP SAR ADC support for the
s32g2/3 platforms
Le 16/09/2025 à 22:26, Daniel Lezcano a écrit :
> 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>
> ---
Hi,
> +static void nxp_sar_adc_dma_remove(void *data)
> +{
> + struct nxp_sar_adc *info = data;
> +
> + dma_free_coherent(info->dma_chan->device->dev, NXP_SAR_ADC_DMA_BUFF_SZ,
> + info->dma_buf.buf, info->rx_dma_buf);
> +}
> +
> +static int nxp_sar_adc_dma_probe(struct device *dev, struct nxp_sar_adc *info)
> +{
> + struct device *dev_dma;
> + u8 *rx_buf;
> +
> + info->dma_chan = devm_dma_request_chan(dev, "rx");
> + if (IS_ERR(info->dma_chan))
> + return PTR_ERR(info->dma_chan);
> +
> + dev_dma = info->dma_chan->device->dev;
> + rx_buf = dma_alloc_coherent(dev_dma, NXP_SAR_ADC_DMA_BUFF_SZ,
> + &info->rx_dma_buf, GFP_KERNEL);
maybe dmam_alloc_coherent() for the managed version?
This would save some LoC.
> + if (!rx_buf)
> + return -ENOMEM;
> +
> + info->dma_buf.buf = rx_buf;
> +
> + return devm_add_action_or_reset(dev, nxp_sar_adc_dma_remove, info);
> +}
Powered by blists - more mailing lists