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

["Nuno Sá" <noname.nuno@gmail.com>]

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:
> > > Add documentation for the ad4080 attributes.
> > > 
> > > Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
> > > ---
> > >  .../ABI/testing/sysfs-bus-iio-adc-ad4080      | 55 +++++++++++++++++++
> > >  1 file changed, 55 insertions(+)
> > >  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-ad4080
> > > 
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4080
> > > b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4080
> > > new file mode 100644
> > > index 000000000000..e37bfba0e989
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad4080
> > > @@ -0,0 +1,55 @@
> > > +What:		/sys/bus/iio/devices/iio:deviceX/lvds_sync
> > > +Date:		February 2025
> > > +KernelVersion:
> > > +Contact:	linux-iio@vger.kernel.org
> > > +Description:
> > > +		This attribute handles the data synchronization
> > > process.Because the CNV
> > > +		signal is not taken into account by the FPGA when
> > > capturing
> > > the data, we
> > > +		need a process that configures the ADC to output pattern
> > > data, writes the
> > > +		SYNC bit in the axi_adc register map, waits until the
> > > custom
> > > HDL syncs the
> > > +		data correctly, and then changes the output mode to
> > > analog
> > > data instead of
> > > +		the fixed pattern.
> > 
> > I'll comment this one in the driver. I have some questions on how this
> > works...
> > 
> > > +
> > > +What:		/sys/bus/iio/devices/iio:deviceX/lvds_lvds
> > > +Date:		February 2025
> > > +KernelVersion:
> > > +Contact:	linux-iio@vger.kernel.org
> > > +Description:
> > > +		Configures the signal type of the CNV signal. The value
> > > can
> > > be either CMOS
> > > +		(lvds_cnv=0) or LVDS (lvds_cnv=1).
> > 
> > The name seems to be wrong with what you have implemented. From this
> > description, I would think of this as a DT property? Can the signal type
> > really
> > change at runtime?
> > 
> > > +
> > > +What:		/sys/bus/iio/devices/iio:deviceX/filter_sel
> > > +Date:		February 2025
> > > +KernelVersion:
> > > +Contact:	linux-iio@vger.kernel.org
> > > +Description:
> > > +		This attribute enables the digital filter functionality
> > > of
> > > the AD4080.In
> > > +		order to capture data correctly, the function must
> > > configure
> > > the ADC
> > > +		through SPI to select the filter type and enable data
> > > capture
> > > in filter
> > > +		mode through axi_adc(In this mode, data is gated by a
> > > signal
> > > generated by
> > > +		the AD4080 (GPIO1 and is not continuous as it is when the
> > > filter is
> > > +		disabled).
> > > +
> > > +What:		/sys/bus/iio/devices/iio:deviceX/filter_sel_available
> > > +Date:		February 2025
> > > +KernelVersion:
> > > +Contact:	linux-iio@vger.kernel.org
> > > +Description:
> > > +		Return the available filter modes that can be set.
> > 
> > There's a standard attr for this. I think we settled 
> 
> Yup. filter_type and filter_type_available. 
> 
> > > +
> > > +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á