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

[Conor Dooley]

On Mon, Jul 13, 2026 at 08:24:00AM -0700, Jonathan Cameron wrote:
> On Mon, 13 Jul 2026 09:55:53 -0500
> David Lechner <dlechner@xxxxxxxxxxxx> wrote:
> 
> > 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.

To be clear, what I was looking for before was a wording that made it
clear that this property meant the hardware supported it. "Allowed" made
it sound like a software policy thing rather than a hardware capability.

> > 
> > 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.
> Fair enough.  Given the driver can always ignore what is in DT I guess it
> is fine as is.

Attachment: signature.asc
Description: PGP signature