The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Kurt Borja" <kuurtb@gmail.com>
To: "David Lechner" <dlechner@baylibre.com>,
	"Kurt Borja" <kuurtb@gmail.com>,
	"Jonathan Cameron" <jic23@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Linus Walleij" <linusw@kernel.org>,
	"Bartosz Golaszewski" <brgl@kernel.org>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
	"Andy Shevchenko" <andy@kernel.org>,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v3 2/9] iio: adc: add the ti-ads1262 driver
Date: Sun, 09 Aug 2026 03:26:57 -0500	[thread overview]
Message-ID: <DKK9QWYHOBOT.2VD8XMZTE65H4@gmail.com> (raw)
In-Reply-To: <ad95afb4-e667-4290-8878-fdd7067f20fe@baylibre.com>

On Sat Aug 8, 2026 at 1:39 PM -05, David Lechner wrote:
> On 8/7/26 10:58 PM, Kurt Borja wrote:
>> Add the ti-ads1262 driver with initial support for the primary ADC
>> (ADC1). The ADS1263 auxiliary ADC (ADC2) is handled by a separate driver
>> and interoperability considerations were taken into account.
>
> Should probably mention here that IIO_CHAN_INFO_SCALE is intentionally
> left out here. (Or just implement it using internal reference voltage
> to start with.)

I'll mention the scale is left out.

>
>> 
>> Signed-off-by: Kurt Borja <kuurtb@gmail.com>
>> ---

[...]

>> diff --git a/drivers/iio/adc/ti-ads1262.c b/drivers/iio/adc/ti-ads1262.c

[...]

>> +static int ads1262_dev_reset(struct ads1262 *st)
>> +{
>> +	int ret;
>> +
>> +	if (st->reset_gpiod) {
>> +		ret = gpiod_set_value_cansleep(st->reset_gpiod, 1);
>> +		if (ret)
>> +			return ret;
>> +
>> +		/*
>> +		 * The RESET pulse timing requirement is 4 clock cycles, at the
>> +		 * minimum clock rate this is 4 microseconds.
>> +		 */
>> +		fsleep(4);
>
> How long do we have to hold reset before the chip powers down?

For power down 65536 clk cycles. Less than that is simple reset.

[...]

>> +static int ads1262_wait_for_conversion(struct ads1262 *st)
>> +{
>> +	u64 max_lat_ms;
>> +	long ret;
>> +
>> +	/*
>> +	 * The first conversion latency is affected by the channel's data rate,
>> +	 * filter, the configurable conversion delay and whether chop mode
>> +	 * and/or IDAC rotation mode are enabled.
>> +	 *
>> +	 * The worst possible latency is calculated by taking the lowest data
>> +	 * rate (2.5 SPS) and the sinc4 filter. This gives a latency of 1600 ms
>> +	 * (Table 9-13). Then we scale it by the actual clock rate and multiply
>> +	 * by 4 to account for chop and IDAC rotation modes (Equation 20).
>> +	 */
>> +	max_lat_ms = 4 * div_u64(mul_u32_u32(1600, 7372800), st->clk_rate);
>
> These are constant values, so don't need mul_u32_u32(). Also, given the wide
> range of possible sampling rates, I would include the current sampling rate
> in the calculation. No need to wate 1.6 seconds for something that should
> take a few 10s of microseconds.

Can we leave it like this until I implement the settlingtime? That way I
can calculate the actual first conversion latency.

[...]

>> +static int ads1262_debugfs_reg_access(struct iio_dev *indio_dev, unsigned int reg,
>> +				      unsigned int writeval, unsigned int *readval)
>> +{
>> +	struct ads1262 *st = iio_priv(indio_dev);
>> +
>> +	guard(mutex)(&st->xfer_lock);
>> +
>> +	if (readval)
>> +		return regmap_read_bypassed(st->regmap, reg, readval);
>
> Don't trust the cache? :-)

I don't trust myself :-) This was relevant early in development, I'll go
with the normal version.

[...]

>> +static int ads1262_parse_channels(struct iio_dev *indio_dev)
>> +{
>> +	struct ads1262 *st = iio_priv(indio_dev);
>> +	struct device *dev = &st->spi->dev;
>> +	struct iio_chan_spec *specs;
>> +	unsigned long used_regs = 0;
>> +	int num_specs;
>> +	u32 reg;
>> +	int ret;
>> +
>> +	st->num_channels = device_get_named_child_node_count(dev, "channel");
>> +	if (!st->num_channels)
>> +		return dev_err_probe(dev, -ENXIO, "no 'channel' nodes configured\n");
>> +	if (st->num_channels > ADS1262_MAX_CHANNEL_COUNT)
>> +		return dev_err_probe(dev, -EINVAL, "too many channels\n");
>> +
>> +	/* Account for the timestamp channel */
>> +	num_specs = st->num_channels + 1;
>> +	specs = devm_kcalloc(dev, num_specs, sizeof(*specs), GFP_KERNEL);
>> +	if (!specs)
>> +		return -ENOMEM;
>> +
>> +	device_for_each_named_child_node_scoped(dev, node, "channel") {
>> +		ret = fwnode_property_read_u32(node, "reg", &reg);
>> +		if (ret)
>> +			return dev_err_probe(dev, ret, "%s: failed to read channel reg\n",
>> +					     fwnode_get_name(node));
>> +		if (reg >= st->num_channels)
>> +			return dev_err_probe(dev, -EINVAL, "%s: reg out of range\n",
>> +					     fwnode_get_name(node));
>> +
>> +		static_assert(ADS1262_MAX_CHANNEL_COUNT < BITS_PER_LONG);
>> +		if (__test_and_set_bit(reg, &used_regs))
>> +			return dev_err_probe(dev, -EINVAL, "%s: duplicated channel reg\n",
>> +					     fwnode_get_name(node));
>> +
>> +		specs[reg].scan_index = reg;
>> +		specs[reg].scan_type = (struct iio_scan_type) {
>> +			.format = IIO_SCAN_FORMAT_SIGNED_INT,
>> +			.realbits = ADS1262_ADC1_RESOLUTION,
>> +			.storagebits = 32,
>> +			.endianness = IIO_BE,
>> +		};
>> +
>> +		ret = ads1262_parse_channel_node(st, &specs[reg], node);
>> +		if (ret)
>> +			return ret;
>> +
>> +		if (specs[reg].channel == ADS1262_INPMUX_TEMP)
>> +			specs[reg].type = IIO_TEMP;
>> +		else
>> +			specs[reg].type = IIO_VOLTAGE;
>> +
>> +		if (specs[reg].channel != ADS1262_INPMUX_TEMP)
>> +			specs[reg].indexed = true;
>> +
>> +		specs[reg].info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
>> +	}
>
> If we are going to use reg to determine the scan index, we need to
> make sure there are no holes in specs that didn't get filled in.
>
> device_for_each_named_child_node_scoped() will skip `status = "disabled"`
> channels, so this could be a possibility.

Ah, I didn't know some channels could be skipped. I'll check for holes.

[...]

-- 
Thanks,
 ~ Kurt

  reply	other threads:[~2026-08-09  8:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-08  3:58 [PATCH v3 0/9] iio: adc: Add TI ADS126X ADC family support Kurt Borja
2026-08-08  3:58 ` [PATCH v3 1/9] dt-bindings: iio: adc: support the TI ADS126x ADC family Kurt Borja
2026-08-08 18:38   ` David Lechner
2026-08-09  8:26     ` Kurt Borja
2026-08-10  8:46   ` Bartosz Golaszewski
2026-08-08  3:58 ` [PATCH v3 2/9] iio: adc: add the ti-ads1262 driver Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-09  8:26     ` Kurt Borja [this message]
2026-08-08 22:28   ` Uwe Kleine-König
2026-08-09 16:24     ` Kurt Borja
2026-08-08  3:58 ` [PATCH v3 3/9] iio: adc: ti-ads1262: support per-channel sampling frequency Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-09  8:27     ` Kurt Borja
2026-08-08  3:58 ` [PATCH v3 4/9] iio: adc: ti-ads1262: support per-channel reference and gain Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-09  8:28     ` Kurt Borja
2026-08-08  3:58 ` [PATCH v3 5/9] iio: adc: ti-ads1262: support input chopping Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-08  3:58 ` [PATCH v3 6/9] iio: adc: ti-ads1262: support excitation currents Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-08  3:58 ` [PATCH v3 7/9] iio: adc: ti-ads1262: support triggered buffer sampling Kurt Borja
2026-08-08 18:39   ` David Lechner
2026-08-09  8:28     ` Kurt Borja
2026-08-08  3:58 ` [PATCH v3 8/9] iio: adc: ti-ads1262: support REFOUT and VBIAS regulators Kurt Borja
2026-08-08 18:40   ` David Lechner
2026-08-09  8:28     ` Kurt Borja
2026-08-08  3:58 ` [PATCH v3 9/9] iio: adc: ti-ads1262: support common mode supplies Kurt Borja
2026-08-08 18:40   ` David Lechner
2026-08-09  8:29     ` Kurt Borja
2026-08-08 18:37 ` [PATCH v3 0/9] iio: adc: Add TI ADS126X ADC family support David Lechner
2026-08-09  8:29   ` Kurt Borja

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=DKK9QWYHOBOT.2VD8XMZTE65H4@gmail.com \
    --to=kuurtb@gmail.com \
    --cc=andy@kernel.org \
    --cc=brgl@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dlechner@baylibre.com \
    --cc=jic23@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.sa@analog.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox