Re: [PATCH v3 3/3] iio: adc: ltc2497: add 2x conversion speed mode

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Wed, Sep 02, 2026 at 09:44:12AM +0300, Andrei Stancovici wrote:
> The LTC2499 supports a 2x output rate (SPD bit in the second
> configuration byte).  In 2x mode the offset auto-calibration is
> disabled, roughly doubling the conversion rate (~13.6Hz vs ~6.8Hz in
> simultaneous 50/60Hz rejection) while leaving linearity and full-scale
> errors unchanged (datasheet).  During a temperature measurement the part
> always converts at 1x regardless of SPD.
> 
> Expose the rate through the standard sampling_frequency /
> sampling_frequency_available ABI on the voltage channels only: SPD is
> ignored for temperature conversions, so the temperature channel
> deliberately carries no SAMP_FREQ attribute.  A new has_speed_mode
> capability flag gates the feature (LTC2499); the two-byte command path
> is now taken for has_temp || has_speed_mode, since both features need the
> second config byte.
> 
> The conversion-time wait becomes mode dependent: 150ms at 1x, 76ms at 2x
> (datasheet t_CONV max, simultaneous rejection, rounded up).  The wait is
> keyed on the conversion currently in flight, whose duration is fixed by
> the mode that was active when it started - not by the newly selected
> mode.  This matters on a 1x->2x switch: a 1x conversion may still be
> running when the first 2x read arrives, and reprogramming the device
> before it finishes would be NACKed with -EIO.  Timing is centralized in
> ltc2497core_conv_time_ms() so a future FA/FB rejection-mode selection
> can extend it into a [rejection][speed] lookup without touching callers.
> 
> LTC2496/LTC2497 (no speed mode) keep the single-byte path and the
> unchanged 150ms wait.
> 
> Validated on a live LTC2499: 20 reads take ~3.1s at 1x and ~1.6s at 2x
> (~0.5x, no -EIO), voltage and temperature readings stay sane in both
> modes, and the temperature/voltage interleave (sticky-PTAT) regression
> still passes at 1x and 2x.

Are the commit messages written with AI assistance?
If so, can you shorten them straight to the point?
Some of the details can be read in the datasheet or code, I think.
(For datasheet it makes sense to add Datasheet tag).

...

> +	/*
> +	 * Parts with a speed mode expose in_voltage_sampling_frequency and
> +	 * in_voltage_sampling_frequency_available on the voltage channels only.
> +	 * SPD is ignored during a temperature measurement, so the temperature
> +	 * channel deliberately carries no SAMP_FREQ attribute.  Patch a private
> +	 * copy of the shared channel array so parts without a speed mode stay
> +	 * untouched.
> +	 */
> +	if (ddata->chip_info->has_speed_mode) {
> +		struct iio_chan_spec *channels;
> +
> +		channels = devm_kmemdup(dev, ltc2497core_channel,
> +					sizeof(ltc2497core_channel), GFP_KERNEL);
> +		if (!channels)
> +			return -ENOMEM;
> +
> +		for (unsigned int i = 0; i < indio_dev->num_channels; i++) {
> +			if (channels[i].type != IIO_VOLTAGE)
> +				continue;

+ blank line.

> +			channels[i].info_mask_shared_by_type |=
> +				BIT(IIO_CHAN_INFO_SAMP_FREQ);
> +			channels[i].info_mask_shared_by_type_available |=
> +				BIT(IIO_CHAN_INFO_SAMP_FREQ);
> +		}
> +
> +		indio_dev->channels = channels;
> +	}

-- 
With Best Regards,
Andy Shevchenko