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.
