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@xxxxxxxxxx> > > > --- > > > .../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@xxxxxxxxxxxxxxx > > > +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@xxxxxxxxxxxxxxx > > > +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@xxxxxxxxxxxxxxx > > > +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@xxxxxxxxxxxxxxx > > > +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@xxxxxxxxxxxxxxx > > > +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@xxxxxxxxxxxxxxx > > > +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á
