Re: [PATCH v2 1/5] Documentation: ABI: IIO: add calibconv_delay documentation

[Jonathan Cameron <jic23@kernel.org>]

On Sun, 4 May 2025 14:48:32 -0500
David Lechner <dlechner@baylibre.com> wrote:

> On 5/4/25 10:16 AM, Jonathan Cameron wrote:
> > On Fri, 02 May 2025 15:26:58 +0200
> > Angelo Dureghello <adureghello@baylibre.com> wrote:
> >   
> >> From: Angelo Dureghello <adureghello@baylibre.com>
> >>
> >> Add new IIO calibconv_delay documentation.
> >>
> >> The ad7606 implements a phase calibation feature, in nanoseconds.
> >> Being this a time delay, using the conv_delay suffix.  
> > I made a late reply to v1...
> > 
> > Key point being that, in the general sense this is only a calibration
> > thing if it is both writeable and we are using it for filter phase correction.
> > In more general terms it's just a conversion sampling time offset (and as you have
> > it here in seconds).  I'm keen we define this to incorporate more general
> > cases including extra read only info on sequencer timing - that can be useful
> > if we have something like 
> >                  _____________
> > Input 0 --------|             |
> > Input 1 --------| 4 in, 2 out |-----  ADC0
> > Input 2 --------|  MUX        |
> > Input 3 --------|_____________|-----  ADC1
> > 
> > That is the ability to schedule more channels across a small number of
> > simultaneous sampling ADCs.  In these cases we've never had a way to
> > express what was done together.  Mostly there have been obvious
> > combinations (i.e. voltage and current at same time on a given wire for
> > power measurement), but it would still be nice to use your new interface
> > to allow us to describe what is running here (though probably not control
> > it as that would be hard to do!)
> >   
> I'm totally on board with making this more general than just calibration, but
> having worked on a couple of multiplexed simultaneous sampling ADCs like this,
> I'm scratching my head a bit trying to figure out how we would be able to know
> what the delay was between the conversions, at least in cases where we don't
> have a hardware conversion trigger based on a clock/pwm. Generally, it is as
> fast as the SPI bus can bang it out, but that isn't a fixed or predictable
> amount of time.

Yeah, this only applies to self clocking devices with a FIFO (possibly a very
short one with 1 register per channel in a scan).
The SPI hammering cases don't work for exactly the reason you mention.

For those we might be able to come up with a multi-baseline solution to
indicate that inputs 0 + 1 are together and 2 + 3 also together but it would
be fiddly.  So lets wait until we know we need that :)

Jonathan