All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: "Nuno Sá" <noname.nuno@gmail.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>, <jic23@kernel.org>,
	<dlechner@baylibre.com>, <nuno.sa@analog.com>, <andy@kernel.org>,
	<robh@kernel.org>, <conor+dt@kernel.org>, <krzk+dt@kernel.org>,
	<linux-iio@vger.kernel.org>, <s32@nxp.com>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<chester62515@gmail.com>, <mbrugger@suse.com>,
	<ghennadi.procopciuc@oss.nxp.com>
Subject: Re: [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the s32g2/3 platforms
Date: Wed, 3 Sep 2025 16:41:11 +0100	[thread overview]
Message-ID: <20250903164111.00004bc6@huawei.com> (raw)
In-Reply-To: <eedbfbfd1ba625b6750eb3ae20a69301b8bc3ef9.camel@gmail.com>

On Wed, 03 Sep 2025 12:20:39 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:

> On Wed, 2025-09-03 at 12:27 +0200, Daniel Lezcano wrote:
> > From: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.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@nxp.com>
> > Signed-off-by: Alexandru-Catalin Ionita <alexandru-catalin.ionita@nxp.com>
> > Co-developed-by: Ciprian Costea <ciprianmarian.costea@nxp.com>
> > Signed-off-by: Ciprian Costea <ciprianmarian.costea@nxp.com>
> > Co-developed-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
> > Signed-off-by: Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com>
> > Signed-off-by: Stefan-Gabriel Mirea <stefan-gabriel.mirea@nxp.com>
> > Co-developed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > ---  
> 
> Hi David,
> 
> Just some minor review for now...
A couple of follow ups (ignoring the DMA buf as others are better
than I am to comment on that!)

> > +/*
> > + * The documentation describes the reset values for the
> > + * registers. However some registers do not have these values after a
> > + * reset. It is a not desirable situation. In some other SoC family
> > + * documentation NXP recommend to not assume the default values are
> > + * set and to initialize the registers conforming to the documentation
> > + * reset information to prevent this situation. Assume the same rule
> > + * applies here as there is a discrepancy between what is read from
> > + * the registers at reset time and the documentation.
> > + */
> > +static void nxp_sar_adc_set_default_values(struct nxp_sar_adc *info)
> > +{
> > +	const u32 mcr_default	= 0x00003901;
> > +	const u32 msr_default	= 0x00000001;
> > +	const u32 ctr_default	= 0x00000014;
> > +	const u32 cimr_default	= 0x00000000;
> > +	const u32 ncmr_default	= 0x00000000;
> > +  
> 
> const does not really bring much here. I would rather have them as #defines.

Unless they can be broken down into meaningful fields I'd
not bother with defines. Just put the values in the writel()
as their meaning is clear from what is being registered.

> 
> > +	writel(mcr_default, REG_ADC_MCR(info->regs));
> > +	writel(msr_default, REG_ADC_MSR(info->regs));
> > +	writel(ctr_default, REG_ADC_CTR0(info->regs));
> > +	writel(ctr_default, REG_ADC_CTR1(info->regs));
> > +	writel(cimr_default, REG_ADC_CIMR0(info->regs));
> > +	writel(cimr_default, REG_ADC_CIMR1(info->regs));
> > +	writel(ncmr_default, REG_ADC_NCMR0(info->regs));
> > +	writel(ncmr_default, REG_ADC_NCMR1(info->regs));
> > +}

> > +};
> > +MODULE_DEVICE_TABLE(of, nxp_sar_adc_match);
> > +
> > +static struct platform_driver nxp_sar_adc_driver = {
> > +	.probe          = nxp_sar_adc_probe,
> > +	.remove         = nxp_sar_adc_remove,
> > +	.driver         = {
> > +		.name   = DRIVER_NAME,
> > +		.of_match_table = nxp_sar_adc_match,
> > +#ifdef CONFIG_PM_SLEEP  
> 
> You should not need the above. Look at pm_ptr() and friends.

Further to that, DEFINE_SIMPLE_DEV_PM_OPS() and drop the guards
around the functions.  The trick here is that it exposes
the functions to the compiler but lets it figure out they aren't
actually used and drop them.  All with out ifdef or __maybe_unused
etc.

> 
> > +		.pm     = &nxp_sar_adc_pm_ops,
> > +#endif
> > +	},
> > +};
> > +
> > +module_platform_driver(nxp_sar_adc_driver);
> > +
> > +MODULE_AUTHOR("NXP");
> > +MODULE_DESCRIPTION("NXP SAR-ADC driver");
> > +MODULE_LICENSE("GPL");  
> 


  parent reply	other threads:[~2025-09-03 15:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-03 10:27 [PATCH v1 0/2] NXP SAR ADC IIO driver for s32g2/3 platforms Daniel Lezcano
2025-09-03 10:27 ` [PATCH v1 1/2] dt-bindings: iio: adc: Add the NXP SAR ADC " Daniel Lezcano
2025-09-03 21:52   ` Rob Herring (Arm)
2025-09-04 19:47   ` David Lechner
2025-09-06  7:29   ` Krzysztof Kozlowski
2025-09-03 10:27 ` [PATCH v1 2/2] iio: adc: Add the NXP SAR ADC support for the " Daniel Lezcano
2025-09-03 11:20   ` Nuno Sá
2025-09-03 14:53     ` Daniel Lezcano
2025-09-03 15:41     ` Jonathan Cameron [this message]
2025-09-04 17:40     ` Daniel Lezcano
2025-09-04 17:49       ` David Lechner
2025-09-05  9:44         ` Daniel Lezcano
2025-09-05 15:25           ` David Lechner
2025-09-05 20:58             ` Daniel Lezcano
2025-09-05 21:54               ` David Lechner
2025-09-08 12:16                 ` Daniel Lezcano
2025-09-08 13:58                   ` David Lechner
2025-09-09  9:29                     ` Nuno Sá
2025-09-09 16:22                       ` Daniel Lezcano
2025-09-10 11:57                         ` Nuno Sá
2025-09-10 16:21                           ` Jonathan Cameron
2025-09-03 11:48   ` Andy Shevchenko
2025-09-03 15:28     ` Daniel Lezcano
2025-09-04  7:33       ` Andy Shevchenko
2025-09-04 16:52         ` Daniel Lezcano
2025-09-09  9:04         ` Daniel Lezcano
2025-09-06  7:34   ` Krzysztof Kozlowski

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=20250903164111.00004bc6@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=andy@kernel.org \
    --cc=chester62515@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=ghennadi.procopciuc@oss.nxp.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbrugger@suse.com \
    --cc=noname.nuno@gmail.com \
    --cc=nuno.sa@analog.com \
    --cc=robh@kernel.org \
    --cc=s32@nxp.com \
    /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.