On Tue, 25 Feb 2025 09:26:56 -0600 David Lechner <dlechner@xxxxxxxxxxxx> 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@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á > > The other driver is still under review: > > https://lore.kernel.org/linux-iio/2c3ce1701545e435238605342397e45657a0fb2a.1739368121.git.Jonathan.Santos@xxxxxxxxxx/ > > 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
