Re: [PATCH 14/14] Documentation: ABI: testing: ad4080 docs

[Jonathan Cameron <jic23@kernel.org>]

On Tue, 25 Feb 2025 09:26:56 -0600
David Lechner <dlechner@baylibre.com> wrote:

> On 2/25/25 3:16 AM, Nuno Sá wrote:
> > On Thu, 2025-02-20 at 12:27 -0600, David Lechner wrote:  
> >> On 2/20/25 8:53 AM, Nuno Sá wrote:  
> >>> On Thu, 2025-02-20 at 15:54 +0200, Antoniu Miclaus wrote:  
> 
> ...
> 
> >>>> +
> >>>> +What:		/sys/bus/iio/devices/iio:deviceX/sinc_dec_rate
> >>>> +Date:		February 2025
> >>>> +KernelVersion:
> >>>> +Contact:	linux-iio@vger.kernel.org
> >>>> +Description:
> >>>> +		Set the filter’s decimation rate.
> >>>> +
> >>>> +What:		/sys/bus/iio/devices/iio:deviceX/sinc_dec_rate_available
> >>>> +Date:		February 2025
> >>>> +KernelVersion:
> >>>> +Contact:	linux-iio@vger.kernel.org
> >>>> +Description:
> >>>> +		Return the available filter's decimation rates.
> >>>> +
> >>>> +  
> >>>
> >>> I'm not yet convinced we need the dec_rate custom attr. I'll add more
> >>> comments
> >>> in the driver.  
> >>
> >> If we do need it, in another driver recently we concluded that
> >> decimation rate is the same as oversampling ratio and there is
> >> already a standard attribute for oversampling ratio, so we used
> >> that.
> >>  
> > 
> > Yeah, in theory decimation is about averaging samples. Makes sense to me even
> > though I never thought about using the oversampling ratio attr. I was biased by
> > the IMUs drivers where we configure the dec_rate as part of the sampling
> > frequency attr since these filters directly affect the chip ODR. 
> > 
> > Out of curiosity, how did you handled this in the other driver? I would be
> > tempted to only allow reading the sampling frequency attribute which means that
> > the oversampling ratio attr is the one we can write (which then directly affects
> > sampling frequency).
> > 
> > - Nuno Sá  
> 
> The other driver is still under review:
> 
> https://lore.kernel.org/linux-iio/2c3ce1701545e435238605342397e45657a0fb2a.1739368121.git.Jonathan.Santos@analog.com/
> 
> It is modifying an existing driver, so in that case, we still have to preserve
> writing to sampling_frequency even if that isn't the ideal way to set it up.

It's pretty rare from what I recall to see a device sophisticated enough to do
over sampling that doesn't also support a sequencer that will allow configuring
the sampling frequency at a given oversampling ratio (by adding space, or more
settling time if a mux is involved which looks the same as space to software).

I guess there is always a first and to me in that case oversampling is the natural
control rather than sampling frequency.

Jonathan
Jonathan