From: Jonathan Cameron <jic23@kernel.org>
To: "David Lechner (TI)" <dlechner@baylibre.com>
Cc: "Nuno Sá" <nuno.sa@analog.com>,
"Andy Shevchenko" <andy@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Kurt Borja" <kuurtb@gmail.com>,
"Nguyen Minh Tien" <zizuzacker@gmail.com>,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] iio: adc: add ti-ads112c14 driver
Date: Sun, 21 Jun 2026 19:52:35 +0100 [thread overview]
Message-ID: <20260621195235.25dc27ac@jic23-huawei> (raw)
In-Reply-To: <20260615-iio-adc-ti-ads122c14-v1-2-e6bdadf7cb2b@baylibre.com>
On Mon, 15 Jun 2026 17:00:00 -0500
"David Lechner (TI)" <dlechner@baylibre.com> wrote:
> Add a new driver for the TI ADS112C14/ADS122C14 ADC chips.
>
> This first step is adding a very basic driver that only supports power
> on/reset and reading the system monitor channels.
>
> ADS112C14_SYS_MON_CHANNEL_SHORT is the last channel rather than being in
> logical order by address to keep the voltage channels together and in
> case we find we need to add variants of this channel with different
> voltage reference later.
>
> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
> ---
>
> A few other notes for review that didn't seem worth putting in the
> commit message:
> * I intentionally did not use bulk regmap because later we may need to
> get the voltage of the avdd supply.
> * I left some comments in the code where the code might look funny (e.g.
> to reduce future diff) or does not exactly match the datasheet, in
> which case later changes will address that.
A few really small things inline.
> diff --git a/drivers/iio/adc/ti-ads112c14.c b/drivers/iio/adc/ti-ads112c14.c
> new file mode 100644
> index 000000000000..97097ae2a487
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads112c14.c
> @@ -0,0 +1,536 @@
> +
> +#define ADS112C14_REG_IDAC_MUX_CFG 0x0E
> +#define ADS112C14_IDAC_MUX_CFG_IUNIT BIT(7)
> +#define ADS112C14_IDAC_MUX_CFG_I2MUX GENMASK(6, 4)
> +#define ADS112C14_IDAC_MUX_CFG_I1MUX GENMASK(2, 0)
Maybe tweak the indent so the register vs fields is slightly easier
to see.
#define ADS112C14_REG_IDAC_MUX_CFG 0x0E
#define ADS112C14_IDAC_MUX_CFG_IUNIT BIT(7)
#define ADS112C14_IDAC_MUX_CFG_I2MUX GENMASK(6, 4)
#define ADS112C14_IDAC_MUX_CFG_I1MUX GENMASK(2, 0)
And deeper still for values where appropriate.
> +static const struct reg_default ads112c14_reg_defaults[] = {
> + { ADS112C14_REG_DEVICE_CFG, 0x00 },
> + { ADS112C14_REG_DATA_RATE_CFG, 0x00 },
> + { ADS112C14_REG_MUX_CFG, 0x00 },
> + { ADS112C14_REG_GAIN_CFG, 0x01 },
> + { ADS112C14_REG_REFERENCE_CFG, 0x00 },
> + { ADS112C14_REG_DIGITAL_CFG, 0x00 },
> + { ADS112C14_REG_GPIO_CFG, 0x00 },
> + { ADS112C14_REG_GPIO_DATA_OUTPUT, 0x00 },
> + { ADS112C14_REG_IDAC_MAG_CFG, 0x00 },
> + { ADS112C14_REG_IDAC_MUX_CFG, 0x10 },
If it is plausible to define these in terms of fields that make them
up I'd prefer that. It isn't always sensible to do so though as
they can get very messy.
> +};
>
> +
> +static int ads112c14_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan, int *val,
> + int *val2, long mask)
> +{
> + struct ads112c14_data *data = iio_priv(indio_dev);
> + u32 vref_uV, fsr_bits;
> +
> + /* Selecting V_REF source is not implemented yet. */
> + vref_uV = ads112c14_internal_ref_uV[ADS112C14_REFERENCE_CFG_REF_VAL_2_5V];
> +
> + /* Currently, everything is using signed data. */
> + fsr_bits = data->chip_info->resolution_bits - 1;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW: {
> + u8 buf[3];
> + int ret;
> +
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> +
> + ret = ads112c14_single_conversion(data, chan, buf);
> + iio_device_release_direct(indio_dev);
> + if (ret < 0)
> + return ret;
> +
> + switch (data->chip_info->resolution_bits) {
> + case 16:
> + *val = get_unaligned_be16(buf);
> + break;
> + case 24:
> + *val = get_unaligned_be24(buf);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + *val = sign_extend32(*val, fsr_bits);
> +
> + return IIO_VAL_INT;
> + }
> + case IIO_CHAN_INFO_SCALE:
> + if (chan->type == IIO_TEMP) {
> + /* TS_TC (typical) = 405 uV/°C */
> + *val = MILLI * vref_uV / 405;
> + *val2 = fsr_bits;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + }
> +
> + *val = vref_uV / (MICRO / MILLI);
> + /*
> + * Last 3 SYS_MON channels (ext ref, AVDD, DVDD) need to be
> + * multiplied by 8 to account for internal attenuation of / 8.
> + */
> + *val2 = fsr_bits - (chan->address >= 3 ? 3 : 0);
> + return IIO_VAL_FRACTIONAL_LOG2;
> + case IIO_CHAN_INFO_OFFSET:
> + /* Only the temperature channel has an offset. */
> + if (chan->type != IIO_TEMP)
> + return -EINVAL;
> + /* Die temperature [°C] = 25°C + (Measured voltage – TS_Offset) / TS_TC */
> + /* TS_TC (typical) = 405 uV/°C */
> + /* TS_Offset (typical) = 119.5 mV */
Trivial but make that a multiline comment block given it is all related stuff.
> + *val = div_s64((s64)(25 * 405 - 119500) * BIT(fsr_bits), vref_uV);
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ads112c14_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + const struct ads112c14_chip_info *info;
> + struct iio_dev *indio_dev;
> + struct ads112c14_data *data;
> + u32 reg_val;
> + int ret;
> +
> + info = i2c_get_match_data(client);
We currently (I think) still need to protect against a manual driver
override and that being NULL. Just error out if that happens as we
don't care about trying to support that.
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> + if (!indio_dev)
next prev parent reply other threads:[~2026-06-21 18:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-15 21:59 [PATCH 0/4] iio: adc: new ti-ads112c14 driver David Lechner (TI)
2026-06-15 21:59 ` [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14 David Lechner (TI)
2026-06-15 22:10 ` sashiko-bot
2026-06-16 0:26 ` Kurt Borja
2026-06-16 15:22 ` David Lechner
2026-06-16 17:31 ` Kurt Borja
2026-06-16 16:07 ` Conor Dooley
2026-06-16 19:54 ` David Lechner
2026-06-16 20:50 ` Conor Dooley
2026-06-16 21:04 ` David Lechner
2026-06-17 15:34 ` Conor Dooley
2026-06-21 18:41 ` Jonathan Cameron
2026-06-21 21:14 ` David Lechner
2026-06-15 22:00 ` [PATCH 2/4] iio: adc: add ti-ads112c14 driver David Lechner (TI)
2026-06-15 22:11 ` sashiko-bot
2026-06-16 7:32 ` Andy Shevchenko
2026-06-16 15:38 ` David Lechner
2026-06-17 10:07 ` Andy Shevchenko
2026-06-21 18:52 ` Jonathan Cameron [this message]
2026-06-15 22:00 ` [PATCH 3/4] iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel David Lechner (TI)
2026-06-15 22:14 ` sashiko-bot
2026-06-16 7:58 ` Andy Shevchenko
2026-06-16 10:03 ` Nuno Sá
2026-06-15 22:00 ` [PATCH 4/4] iio: adc: ti-ads112c14: add measurement channel support David Lechner (TI)
2026-06-15 22:13 ` sashiko-bot
2026-06-16 8:36 ` Andy Shevchenko
2026-06-16 15:55 ` David Lechner
2026-06-17 10:16 ` Andy Shevchenko
2026-06-16 15:30 ` David Lechner
2026-06-21 19:08 ` Jonathan Cameron
2026-06-16 0:18 ` [PATCH 0/4] iio: adc: new ti-ads112c14 driver Kurt Borja
2026-06-16 15:21 ` David Lechner
2026-06-16 17:26 ` Kurt Borja
2026-06-16 18:16 ` David Lechner
2026-06-21 19:14 ` Jonathan Cameron
2026-06-22 0:32 ` 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=20260621195235.25dc27ac@jic23-huawei \
--to=jic23@kernel.org \
--cc=andy@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlechner@baylibre.com \
--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 \
--cc=zizuzacker@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox