Re: [PATCH v3 4/8] dt-bindings: iio: adc: add input-chopping property

[David Lechner]

On 7/12/26 8:34 PM, Jonathan Cameron wrote:
> On Fri, 10 Jul 2026 17:50:37 -0500
> "David Lechner (TI)" <dlechner@xxxxxxxxxxxx> wrote:
> 
>> Add a generic input-chopping property to adc.yaml. This is a feature
>> seen frequently in ADCs that are designed to measure resistive loads,
>> such as RTDs and strain gauges. Enabling this can reduce offset errors
>> by swapping the positive and negative input channels on every other
>> conversion. This can have side-effects in timing and filter response, so
>> it is not always desirable to enable this feature in some applications.
>> Therefore, it is best to make this a property that can be enabled or
>> disabled in the device tree.
>>
>> Signed-off-by: David Lechner (TI) <dlechner@xxxxxxxxxxxx>
>> ---
>> v3 changes:
>> * Renamed property to input-chopping to reflect more common terminology.
>> * Removed "allowed" from the description.
>> * Extended description to explain when it should not be used.
>>
>> v2 changes:
>> * New patch.
>> ---
>>  Documentation/devicetree/bindings/iio/adc/adc.yaml | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> index 308857f11220..c408feebd46d 100644
>> --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml
>> @@ -80,6 +80,14 @@ properties:
>>        ADCs usually allow choosing between internal reference sources or a pair
>>        of external pins.
>>  
>> +  input-chopping:
>> +    type: boolean
>> +    description:
>> +      If set, the positive and negative input channels are swapped on every
>> +      other conversion to reduce offset error. This generally comes at the
>> +      expense of added settling time between conversions, so should be omitted
>> +      on systems with high-frequency signals or high data rate requirements.
> 
> I'm lazy so I didn't check back, but in my mental model of this, the DT is simply
> saying that the analog circuitry is suitable for doing chopping.  Driver decision
> on whether to do it.  Perhaps we can reword it for that?

Heh, that was the "allowed" part that I removed.

I think this is really more of a design decision between the tradeoff
of less noise vs. data rate. By setting this property, we are saying
we should favor less noise. So I think it is more about the expected
signal than the circuitry.

So not sure that I would add anything here.


>> +
>>    excitation-channels:
>>      $ref: /schemas/types.yaml#/definitions/uint32-array
>>      description:
>>
>