Re: [PATCH 0/5] iio: adc: ti-ads112c14: add filter support

[Jonathan Cameron]

On Fri, 07 Aug 2026 19:19:45 -0500
"David Lechner (TI)" <dlechner@xxxxxxxxxxxx> wrote:

> TI ADS112C14 has several features related to filtering that are all
> interconnected. And to make things more interesting, not of the register
> fields map directly to IIO attributes. So this is one of those cases
> where we need to bend the rules a bit and just document it (we've
> already discussed this a bit in the previous series for this driver and
> came to this conclusion).

I've long forgotten that :)

> 
> Here is the high-level overview:
> 
> We are adding sampling_frequency, oversampling_ratio, filter_type, and
> a (new to IIO) settlingtime attribute.
> 
> Since register fields have different meanings depending on filter type
> we have a quirky rule that if the filter type is sinc4 or sinc4+sinc1,
> then you need to set the oversampling ratio first in order to see the
> expected available values for the sampling frequency. For sinc4+sinc1+pf1
> it is the other way around, you have to set sampling frequency first
> in order to see the expected available oversampling ratios.

That's rather horrible...

> 
> In other drivers, we've opted to store the requested values for dependant
> attributes like this and pick the closest available one when actually
> starting sampling. I opted not to do that here as there is not much
> overlap between settings. And as we will see below, there are other
> reasons for being picky about sampling frequency.
> 
> We also discussed in another series about a proposed settlingtime
> attribute. The conclusion was that it should be the total settling time
> delay (in seconds) before a chip takes the first sample (after any
> settings have changed). In this chip there is a DELAY field in a
> register that programs some extra delay in addition to an always present
> fixed delay. So the way the attribute will work for this chip is that
> the settlingtime_available attribute will list the range including a
> minimum value. This happens to be the always present fixed delay. So the
> difference between that and the current value of the settlingtime
> attribute will be programed as the DELAY value. It also seems that the
> fixed latency period includes the conversion time. We've just glossed
> over that for now and not subtracted that from the settlingtime
>  attribute.
> 
> Now, here is where things really get interesting/complicated. There are
> even more settings that affect the settling time. We defined the
> settling time as just a delay before the first sample. However, there
> are a couple of things that trigger the "first" sample. On this chip,
> the first sample only counts in continuous sampling mode. So only works
> as described when using the DRDY trigger in this driver. When using
> a generic trigger, e.g. a hrtimer trigger, single-shot sampling mode
> is used, so every sample is a "first" sample and has the settling delay
> added. This is mostly a non-issue other than it could throw people off
> that they cannot set the hrtimer frequency close to the sampling
> frequency attribute and actually get that sampling rate.

Whilst odd I'm not that bothered by this one.  Maybe some weasel
words about it potentially applying in other circumstances that
chopping or first sample.


> 
> And there a few other idiosyncrasies we haven't accounted for. To keep
> things simple, we've implemented settlingtime as tDELAY + tLATENCY
> (datasheet values). But this actually include the conversion time as
> well. Also, tLATENCY is longer if you are coming out of standby mode
> (this doesn't matter at this point since we didn't implement power
> management, but we wouldn't want to change it and break userspace
> later).
> 
> Then there is also input chopping where the positive and negative input
> channels are swapped in the mux in the ADC on each sample. In these
> cases, every conversion requires the settling time because the mux is
> switched after every conversion. And the actual first sample has
> additional delay (presumably does two conversions). 

oh goody.  I wonder if that is standard in any sense for chopping devices?

> So the first sample
> takes tGC_LATENCY = 2 × (tDELAY + tLATENCY) – 12 tMOD and every sample
> after that takes tGC_DATA = tDELAY + tLATENCY – 12 tMOD. For this one,
> I have valued simplicity over accuracy in the implementation, so it is
> the same where settlingtime = tDELAY + tLATENCY and not worried about
> the 12 tMOD difference. I think it makes sense to keep settlingtime
> as a single tDELAY + tLATENCY in this case since the when the mux
> changes after each sample, the next sample is now the first sample after
> settings have changed.
> 
> This sort of breaks the definition of sampling frequency though since
> in IIO, the 1 / sampling frequency is the time between each sample
> being sent over the bus. I don't really want to change how sampling
> frequency is implemented here though because the current values match
> the datasheet which can be used to infer information like where the
> notches in the filter are. The actual observed sampling rate will be
> 1 / tGC_DATA.
> 
> Having written all of this out now though, I'm tempted to go back and
> change the settlingtime attribute implementation to be more accurate.
> In any case, tDELAY will always be easy to infer because it is the
> current value minus the minimum value (from the _available attribute).
> Then when using input chopping one could get a reasonably accurate
> sample period by taking 1 / sampling_frequency + settlingtime.
> 
> We will follow this up later with a documentation patch that explains
> all of this too.
This is pretty nasty but not first time we've had to bend the ABI
a little.  

I stopped reviewing later patches as didn't want to unwind that
misplaces snippet Andy called out.

+ there is quite a bit in flight for this driver and my backlog of
IIO emails is a mere 268...

J
> 
> Signed-off-by: David Lechner (TI) <dlechner@xxxxxxxxxxxx>
> ---
> David Lechner (TI) (5):
>       iio: adc: ti-ads112c14: support external clock
>       iio: adc: ti-ads112c14: add filter support
>       iio: ABI: add sinc4+sinc1+pf1 filter_type
>       iio: adc: ti-ads112c14: add settlingtime attribute
>       iio: ABI: add settlingtime attributes
> 
>  Documentation/ABI/testing/sysfs-bus-iio |  22 +
>  drivers/iio/adc/ti-ads112c14.c          | 859 +++++++++++++++++++++++++++++++-
>  2 files changed, 862 insertions(+), 19 deletions(-)
> ---
> base-commit: 350d1fb9204b13c5f95e511e98b8bcb47574d425
> change-id: 20260807-iio-adc-ti-ads112c14-filter-support-8a56850f590f
> prerequisite-change-id: 20260724-iio-adc-ti-ads112c14-continuous-mode-dd1580754609:v3
> prerequisite-patch-id: 0be96266a72458a63f7da7ca876d87cdf5769a8b
> prerequisite-patch-id: 32ba48fd5eacaee60d50a0272557859cc9ea83ca
> prerequisite-patch-id: c1eb09689bd5f259ea0110cbbfb3fa76689bdb04
> prerequisite-change-id: 20260724-iio-adc-ti-ads112c14-burnout-184304669165:v1
> prerequisite-patch-id: 8723aa599dcf5b836fb81cf1efb6c9096bf60b7a
> prerequisite-patch-id: 12754335ccf210bcdeaa8a5d60b2280618d50993
> prerequisite-patch-id: ed5d4c1628ef60ed542339fe5fb490383ee8074f
> prerequisite-patch-id: b92f5609fcf39e958e78b4dd74c3d323ebb6a161
> prerequisite-patch-id: 755be140432ee53c84c3a4112dc8a42d78dfd01c
> prerequisite-patch-id: e89fe89cd6ceae3d875219611372a6d48bf0e064
> 
> Best regards,
> --  
> David Lechner (TI) <dlechner@xxxxxxxxxxxx>
> 
>