Re: [PATCH 1/6] dt-bindings: iio: adc: Add AD7768

On Mon, 20 Jul 2026 16:00:26 +0200
Janani Sunil <[email protected]> wrote:

> On 7/9/26 17:43, David Lechner wrote:
> > On 7/9/26 3:50 AM, Janani Sunil wrote:  
> >> Devicetree Bindings for AD7768-4 (4 channel) and AD7768 (8 channel)
> >> simultaneous sampling ADC
> >>
> >> Signed-off-by: Janani Sunil <[email protected]>
> >> ---
> >>   
> >>
> >> +
> >> +  adi,power-mode:
> >> +    $ref: /schemas/types.yaml#/definitions/string
> >> +    enum:
> >> +      - low
> >> +      - median
> >> +      - fast
> >> +    description:
> >> +      Power mode selection.  
> > Unless there are pins that control this, it seems like it should be
> > left up to the driver to decide how to set this.
> >
> > In this case, it looks like the power mode also influences sample rate
> > which is normally something controlled at runtime.  
> 
> Hi David,
> 
> The reason we'd like to retain power mode control is that certain ODRs 
> are supported across all three power modes (low/median/fast), and the 
> RMS noise and power consumption differ significantly between them at the 
> same ODR.
> 
> The higher the power mode, the better the noise performance, but power 
> consumption nearly doubles for every ~3 dB improvement in dynamic range. 
> Silently selecting one power mode in the driver would remove a 
> meaningful hardware tradeoff from the user.
> 
> We'd like to propose the following instead:
> - Remove adi,power-mode from the DT as suggested.
> - Expose power mode as a per-device sysfs attribute.
> - in_voltage<N>_sampling_frequency_available dynamically reflects only 
> the ODRs valid for the currently selected power mode.
> 
> This keeps the DT clean while still giving the user explicit control 
> over the noise versus power trade off. Would this approach be acceptable?
> 

The challenge here is simple: How does userspace know what a power mode
means?  Everyone wants low power and low noise and the trade of between
the two tends to be invisible.  If we add a control it also becomes
hard to do a best effort - give them something sensible - control based
on what they want. Users understand the ability to sample at different max
frequencies for example. There are ways to do this like always requiring
'auto' as an option for a power control but they are also rather nasty.

Whilst I see that it is reasonably complex to move from 'low / medium / high'
we need to try really hard to map that to something numeric and well defined.
I think it came up earlier in the discussion - there is a clearly stated
set of recommendations for a  mapping from fmod to power mode. I lost
track of whether we had reasons to not try and build an interface
around that.  Even though modulator frequency is a little obscure, if it
is consistently defined across manufacturers and parts and the trade offs
around how it is chosen are well understood that might be something that
would make a better ABI?

Jonathan




> Thanks,
> Jan
> 
> 
>