From: David Lechner <dlechner@baylibre.com>
To: 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>
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
Subject: Re: [PATCH v4 03/10] iio: adc: add the ti-ads1262 driver
Date: Thu, 10 Sep 2026 16:38:46 -0500 [thread overview]
Message-ID: <0505ad77-8ae8-44bb-88b8-210f5cba023f@baylibre.com> (raw)
In-Reply-To: <DL8IE3OUIUZ4.2SND39L7P03VL@gmail.com>
On 9/6/26 3:17 PM, Kurt Borja wrote:
> On Mon Aug 31, 2026 at 5:22 PM -03, David Lechner wrote:
>> On 8/28/26 1:38 AM, 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.
>>>
>>
>> ...
>>
>>> +#define ADS1262_FW_CHANNEL_COUNT 16
>>> +#define ADS1262_MON_CHANNEL_COUNT 4
>>> +#define ADS1262_REGMAP_WRITE_SZ 8
>>> +#define ADS1262_MONITOR_ADDR_OFFSET 100
>>
>> Where does this offset come from? I would make the address the value that
>> gets written to MUXP/MUXN. But it looks like we are using the same value
>> for the .channel, so setting .address to that would be redundant.
>
> I'm using .address to map the firmware 'reg' to channels in
> fwnode_xlate. That's why I would need to move the monitors forward. More
> on this discussion below.
>
>>
>>> +
>>> +#define ADS1262_ADC1_RESOLUTION 32
>>> +
>>> +struct ads1262 {
>>> + struct spi_device *spi;
>>> + struct regmap *regmap;
>>> + struct gpio_desc *start_gpiod;
>>> + /* protects concurrent SPI transfers */
>>> + struct mutex xfer_lock;
>>> + /* protects channel state */
>>> + struct mutex chan_lock;
>>> + struct completion drdy;
>>> + unsigned long clk_rate;
>>> + u8 dev_id;
>>> +};
>>> +
>>> +static const char * const ads1262_device_id_to_name[] = {
>>> + [ADS1262_DEV_ID] = "ads1262",
>>> + [ADS1263_DEV_ID] = "ads1263",
>>> +};
>>> +
>>> +static const struct iio_chan_spec ads1262_monitor_chan_specs[] = {
>>> + {
>>> + .type = IIO_TEMP,
>>> + .channel = ADS1262_INPMUX_TEMP,
>>> + .channel2 = ADS1262_INPMUX_TEMP,
>>
>> Since these are the same, I would just not set .channel2 and later say
>> MUXN = spec->differential ? spec->channel2 : spec->channel. Same applies
>> to others below.
>>
>>> + .address = ADS1262_MONITOR_ADDR_OFFSET + 0,
>>> + .scan_type = {
>>> + .format = IIO_SCAN_FORMAT_SIGNED_INT,
>>> + .realbits = ADS1262_ADC1_RESOLUTION,
>>> + .storagebits = 32,
>>> + .endianness = IIO_BE,
>>> + },
>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
>>
>> Where is SCALE and OFFSET?
>
> Missing.
>
> I'm pretty sure I tested this channel though so maybe there's something
> wrong in my tests.
I think it was just added in a later patch.
>
>>
>>> + },
>>> + {
>>> + .type = IIO_VOLTAGE,
>>> + .channel = ADS1262_INPMUX_AVDD,
>>> + .channel2 = ADS1262_INPMUX_AVDD,
>>> + .indexed = 1,
>>> + .address = ADS1262_MONITOR_ADDR_OFFSET + 1,
>>> + .scan_type = {
>>> + .format = IIO_SCAN_FORMAT_SIGNED_INT,
>>> + .realbits = ADS1262_ADC1_RESOLUTION,
>>> + .storagebits = 32,
>>> + .endianness = IIO_BE,
>>> + },
>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
>>> + },
>>> + {
>>> + .type = IIO_VOLTAGE,
>>> + .channel = ADS1262_INPMUX_DVDD,
>>> + .channel2 = ADS1262_INPMUX_DVDD,
>>> + .indexed = 1,
>>> + .address = ADS1262_MONITOR_ADDR_OFFSET + 2,
>>> + .scan_type = {
>>> + .format = IIO_SCAN_FORMAT_SIGNED_INT,
>>> + .realbits = ADS1262_ADC1_RESOLUTION,
>>> + .storagebits = 32,
>>> + .endianness = IIO_BE,
>>> + },
>>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
>>> + },
>>> + {
>>> + .type = IIO_VOLTAGE,
>>> + .channel = ADS1262_INPMUX_TDAC,
>>> + .channel2 = ADS1262_INPMUX_TDAC,
>>
>> Hmm... a differential where channel == channel2 usually means a shorted
>> input. TDACP and TDACN can be controlled indepedantly, so really are two
>> separate channels.
>
> They can be controlled independently but the user would have to define a
> common mode channel for that. I went with this because its only a test
> channel and we making these channels static. Otherwise we would have to
> allow the TDAC channel in devicetree. Would that be preferable?
>
Sounds like Jonathan is OK with it, so OK with me too to leave it as-is.
next prev parent reply other threads:[~2026-09-10 21:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-28 6:38 [PATCH v4 00/10] iio: adc: Add TI ADS126X ADC family support Kurt Borja
2026-08-28 6:38 ` [PATCH v4 01/10] dt-bindings: adc: add excitation-current-chopping property Kurt Borja
2026-08-28 16:33 ` Conor Dooley
2026-08-28 6:38 ` [PATCH v4 02/10] dt-bindings: iio: adc: support the TI ADS126x ADC family Kurt Borja
2026-08-28 6:45 ` sashiko-bot
2026-08-28 16:39 ` Conor Dooley
2026-08-30 1:57 ` Jonathan Cameron
2026-08-31 16:24 ` Conor Dooley
2026-09-01 3:01 ` Jonathan Cameron
2026-09-06 20:16 ` Kurt Borja
2026-08-30 1:53 ` Jonathan Cameron
2026-09-06 20:16 ` Kurt Borja
2026-08-31 19:44 ` David Lechner
2026-09-06 20:17 ` Kurt Borja
2026-08-28 6:38 ` [PATCH v4 03/10] iio: adc: add the ti-ads1262 driver Kurt Borja
2026-08-28 6:52 ` sashiko-bot
2026-08-30 2:02 ` Jonathan Cameron
2026-09-06 20:16 ` Kurt Borja
2026-08-28 8:09 ` Andy Shevchenko
2026-09-06 20:15 ` Kurt Borja
2026-09-08 10:01 ` Andy Shevchenko
2026-08-31 20:22 ` David Lechner
2026-09-01 3:07 ` Jonathan Cameron
2026-09-06 20:17 ` Kurt Borja
2026-09-10 2:43 ` Jonathan Cameron
2026-09-10 21:38 ` David Lechner [this message]
2026-08-28 6:38 ` [PATCH v4 04/10] iio: adc: ti-ads1262: support per-channel sampling frequency Kurt Borja
2026-08-28 7:03 ` sashiko-bot
2026-08-30 1:36 ` Jonathan Cameron
2026-09-06 20:16 ` Kurt Borja
2026-08-30 2:22 ` Jonathan Cameron
2026-09-06 20:17 ` Kurt Borja
2026-08-28 6:38 ` [PATCH v4 05/10] iio: adc: ti-ads1262: support per-channel reference and gain Kurt Borja
2026-08-28 6:38 ` [PATCH v4 06/10] iio: adc: ti-ads1262: support input chopping Kurt Borja
2026-08-28 6:38 ` [PATCH v4 07/10] iio: adc: ti-ads1262: support excitation currents Kurt Borja
2026-08-28 6:57 ` sashiko-bot
2026-08-28 6:38 ` [PATCH v4 08/10] iio: adc: ti-ads1262: support triggered buffer sampling Kurt Borja
2026-08-28 6:57 ` sashiko-bot
2026-08-28 6:38 ` [PATCH v4 09/10] iio: adc: ti-ads1262: support REFOUT and VBIAS regulators Kurt Borja
2026-08-28 6:53 ` sashiko-bot
2026-08-28 6:38 ` [PATCH v4 10/10] iio: adc: ti-ads1262: support common mode supplies Kurt Borja
2026-08-28 7:03 ` sashiko-bot
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=0505ad77-8ae8-44bb-88b8-210f5cba023f@baylibre.com \
--to=dlechner@baylibre.com \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kuurtb@gmail.com \
--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