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", ®);
>> + 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
next prev parent reply other threads:[~2026-08-09 8:27 UTC|newest]
Thread overview: 42+ 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 4:08 ` sashiko-bot
2026-08-08 18:38 ` David Lechner
2026-08-09 8:26 ` Kurt Borja
2026-08-10 16:42 ` David Lechner
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 4:11 ` sashiko-bot
2026-08-08 18:39 ` David Lechner
2026-08-09 8:26 ` Kurt Borja [this message]
2026-08-10 16:42 ` David Lechner
2026-08-10 18:48 ` Andy Shevchenko
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 4:11 ` sashiko-bot
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 4:13 ` sashiko-bot
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 4:09 ` sashiko-bot
2026-08-08 18:39 ` David Lechner
2026-08-09 8:28 ` Kurt Borja
2026-08-10 16:31 ` David Lechner
2026-08-08 3:58 ` [PATCH v3 8/9] iio: adc: ti-ads1262: support REFOUT and VBIAS regulators Kurt Borja
2026-08-08 4:11 ` sashiko-bot
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
2026-08-10 16:42 ` David Lechner
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 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.