Re: [PATCH v12 5/6] iio: adc: ad4691: add oversampling support

[Jonathan Cameron]

On Thu, 21 May 2026 11:32:42 +0000
"Sabau, Radu bogdan" <Radu.Sabau@xxxxxxxxxx> wrote:

> > -----Original Message-----
> > From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@xxxxxxxxxx>
> > Sent: Tuesday, May 19, 2026 3:20 PM  
> 
> ...
> 
> > 
> > +	iio_for_each_active_channel(indio_dev, bit) {
> > +		ret = regmap_write(st->regmap,
> > AD4691_ACC_DEPTH_IN(bit), st->osr[bit]);  
> 
> Unfortunately enough, I think a v13 will come, too...
> 
> Had a look again on what Sashiko had to say, and seeing the sampling frequency
> shared_by_all comment again made me have a deeper look see how the code could
> be commented so he wouldn't complain about this anymore, and...
> 
> Perhaps he is a bit right after all. I found a section stating that in standard
> sequencer mode (which the driver uses right now), all the channels actually use
> the ACC_DEPTH_IN0 for osr, and so changing ACC_DEPTH_INn for other channels
> doesn't really do much. And so I tested this selecting both voltage0 and voltage1
> for sampling with osr4 for voltage0 and osr1 for voltage1 and with a 100kHz osc freq
> indeed DR fell after approximately 80us which points out both channels were actually
> using OSR of 4. Perhaps the OSR should be shared by all and therefore the
> sampling frequency would also be shared by all, right?

I kind of lost track on the modes. What are the chances we later move to or add
support for a mode where the different OSRs do matter?  If that's a possibility
we should avoid ABI change by allowing for it from the start.

Then if we are in this mode, they'll have separate controls but change any, changes
them all, if we are in a different mode that connection breaks.
If that's the case, just throw in a comment saying something to the effect this
may change.

It's not wrong ABI to do this, it's just less intuitive for users which is why
we prefer the shared_by stuff where there isn't a disadvantage.  That is at most
a hint to what actually happens.   A simple example is where different
channels have one OSR field but they aren't the same - i.e. channel 1 is twice
the OSR of channel 2.  Hence we can't share the attribute but any change effects
both.

Jonathan

> 
> The usage of internal_osc_freq and pre-computed freq values depending on osr would
> stay the same since those are still correct anyway.
> 
> What's your opinion on this?
> Radu
>