On Mon, 10 Mar 2025 09:31:45 -0500 David Lechner <dlechner@xxxxxxxxxxxx> wrote: > On 3/9/25 3:49 PM, Jorge Marques wrote: > >>> +.. list-table:: Driver attributes > >>> + :header-rows: 1 > >>> + > >>> + * - Attribute > >>> + - Description > >>> + * - ``in_voltage0_raw`` > >>> + - Raw ADC voltage value > >>> + * - ``in_voltage0_oversampling_ratio`` > >>> + - Enable the device's burst averaging mode to over sample using > >>> + the internal sample rate. > >>> + * - ``in_voltage0_oversampling_ratio_available`` > >>> + - List of available oversampling values. Value 0 disable the burst > >>> + averaging mode. > >>> + * - ``sample_rate`` > >>> + - Device internal sample rate used in the burst averaging mode. > >>> + * - ``sample_rate_available`` > >>> + - List of available sample rates. > >> > >> Why not using the standard sampling_frequency[_available] attributes? > > Because sampling_frequency is the sampling frequency for the pwm trigger > > during buffer readings. > > sample_rate is the internal device clock used during monitor and burst > > averaging modes. > > I haven't done a chips with a monitor mode yet where we aren't reading > the samples, so hopefully Jonathan will chime in here on the usual way > to handle that. > > For the burst averaging mode, I understand the need for a separate attribute > now. I would suggest to call this the conversion_frequency rather than > sampling_rate since IIO already defines "sampling" to be the data read > from the chip to Linux even if it is an averaged value, it still counts > as one sample. I should have read on. I'd like this more closely associated with oversampling. As per other reply we use sampling_frequency in the events directory for the monitoring frequency case. One of our very first drivers did this (max1363) so it's been in the ABI a long time! Jonathan
