From: Andrej Picej <andrej.picej@norik.com>
Document i.MX93 ADC calibration properties and how to set them.
Signed-off-by: Andrej Picej <andrej.picej@norik.com>
Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
---
.../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
index c2e5ff418920..d1c04cf85fe6 100644
--- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
@@ -52,6 +52,27 @@ properties:
"#io-channel-cells":
const: 1
+ nxp,calib-avg-en:
+ default: 1
+ description:
+ Enable or disable calibration averaging function (AVGEN).
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 0, 1 ]
+
+ nxp,calib-nr-samples:
+ default: 512
+ description:
+ Selects number of samples (NRSMPL) to be used during calibration.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 16, 32, 128, 512 ]
+
+ nxp,calib-t-sample:
+ default: 22
+ description:
+ Selects sample time (TSAMP) of calibration conversions in ADC clock cycles
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [ 8, 16, 22, 32 ]
+
required:
- compatible
- reg
--
2.34.1On 7/10/25 2:39 AM, Primoz Fiser wrote: > From: Andrej Picej <andrej.picej@norik.com> > > Document i.MX93 ADC calibration properties and how to set them. > > Signed-off-by: Andrej Picej <andrej.picej@norik.com> > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> > --- > .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > index c2e5ff418920..d1c04cf85fe6 100644 > --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > @@ -52,6 +52,27 @@ properties: > "#io-channel-cells": > const: 1 > > + nxp,calib-avg-en: > + default: 1 > + description: > + Enable or disable calibration averaging function (AVGEN). > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 0, 1 ] > + > + nxp,calib-nr-samples: > + default: 512 > + description: > + Selects number of samples (NRSMPL) to be used during calibration. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 16, 32, 128, 512 ] > + > + nxp,calib-t-sample: > + default: 22 > + description: > + Selects sample time (TSAMP) of calibration conversions in ADC clock cycles > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 8, 16, 22, 32 ] > + > required: > - compatible > - reg This seem like things that should be set at runtime rather than in the devicetree. Unless there is some justification on why these values depend on how the chip is wired up?
On Thu, 10 Jul 2025 10:46:44 -0500 David Lechner <dlechner@baylibre.com> wrote: > On 7/10/25 2:39 AM, Primoz Fiser wrote: > > From: Andrej Picej <andrej.picej@norik.com> > > > > Document i.MX93 ADC calibration properties and how to set them. > > > > Signed-off-by: Andrej Picej <andrej.picej@norik.com> > > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> > > --- > > .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > index c2e5ff418920..d1c04cf85fe6 100644 > > --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > @@ -52,6 +52,27 @@ properties: > > "#io-channel-cells": > > const: 1 > > > > + nxp,calib-avg-en: > > + default: 1 > > + description: > > + Enable or disable calibration averaging function (AVGEN). > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [ 0, 1 ] > > + > > + nxp,calib-nr-samples: > > + default: 512 > > + description: > > + Selects number of samples (NRSMPL) to be used during calibration. > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [ 16, 32, 128, 512 ] Allow 1 as a value and drop the enabled above. Averaging over 1 sample is same as no averaging and gives simpler binding. > > + > > + nxp,calib-t-sample: > > + default: 22 > > + description: > > + Selects sample time (TSAMP) of calibration conversions in ADC clock cycles > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [ 8, 16, 22, 32 ] > > + > > required: > > - compatible > > - reg > > This seem like things that should be set at runtime rather than > in the devicetree. Unless there is some justification on why > these values depend on how the chip is wired up? Further to that, I'd like to see some explanation of why we care to change it at all. Is it ever a bad idea to enable averaging and pick a large number of samples for calibration? > >
Hi all, On 13. 07. 25 17:02, Jonathan Cameron wrote: > On Thu, 10 Jul 2025 10:46:44 -0500 > David Lechner <dlechner@baylibre.com> wrote: > >> On 7/10/25 2:39 AM, Primoz Fiser wrote: >>> From: Andrej Picej <andrej.picej@norik.com> >>> >>> Document i.MX93 ADC calibration properties and how to set them. >>> >>> Signed-off-by: Andrej Picej <andrej.picej@norik.com> >>> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> >>> --- >>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ >>> 1 file changed, 21 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>> index c2e5ff418920..d1c04cf85fe6 100644 >>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>> @@ -52,6 +52,27 @@ properties: >>> "#io-channel-cells": >>> const: 1 >>> >>> + nxp,calib-avg-en: >>> + default: 1 >>> + description: >>> + Enable or disable calibration averaging function (AVGEN). >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [ 0, 1 ] >>> + >>> + nxp,calib-nr-samples: >>> + default: 512 >>> + description: >>> + Selects number of samples (NRSMPL) to be used during calibration. >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [ 16, 32, 128, 512 ] > > Allow 1 as a value and drop the enabled above. Averaging over 1 sample > is same as no averaging and gives simpler binding. > >>> + >>> + nxp,calib-t-sample: >>> + default: 22 >>> + description: >>> + Selects sample time (TSAMP) of calibration conversions in ADC clock cycles >>> + $ref: /schemas/types.yaml#/definitions/uint32 >>> + enum: [ 8, 16, 22, 32 ] >>> + >>> required: >>> - compatible >>> - reg >> >> This seem like things that should be set at runtime rather than >> in the devicetree. Unless there is some justification on why >> these values depend on how the chip is wired up? It depends how ADC 1.8V Vref is wired up, especially how noisy it is. > > Further to that, I'd like to see some explanation of why we care > to change it at all. Is it ever a bad idea to enable averaging and > pick a large number of samples for calibration? This is a snippet from the i.MX93 TRM, chapter Analog-to-Digital Converter (SAR_ADC) describing calibration steps: 1. Wait for deassertion of functional reset. 2. Configure SAR controller operating clock (MCR[ADCLKSE] = 0). 3. Bring ADC out of Power-down state (MCR[PWDN] = 0). 4. Configure desired calibration settings (default values kept for highest accuracy maximum time). • MCR[TSAMP]: Sample time for calibration conversion • MCR[NRSMPL]: Number of samples in averaging • MCR[AVGEN]: Averaging function enable in calibration 5. Run calibration by writing a one to MCR[CALSTART]. 6. Check calibration run status in MSR[CALBUSY]—wait until MSR[CALBUSY] = 0; alternatively, MSR[ADCSTAT] can be used to check status. 7. Check calibration pass/fail status in MSR[CALFAIL] field. If MSR[CALFAIL] = 1 then calibration failed. Detailed status can be checked in CALSTAT. See point 4). Not sure why would there be an option to configure i.MX93 ADC calibration parameters if one use-case (max accuracy max time) to rule them all? On the other hand, public TRM doesn't give much more information and input from NXP would be highly desired. @Haibo Chen your thoughts? BR, Primoz > >> >> > -- Primoz Fiser phone: +386-41-390-545 email: primoz.fiser@norik.com -- Norik systems d.o.o. Your embedded software partner Slovenia, EU phone: +386-41-540-545 email: info@norik.com
On Mon, 2025-07-14 at 07:56 +0200, Primoz Fiser wrote: > Hi all, > > On 13. 07. 25 17:02, Jonathan Cameron wrote: > > On Thu, 10 Jul 2025 10:46:44 -0500 > > David Lechner <dlechner@baylibre.com> wrote: > > > > > On 7/10/25 2:39 AM, Primoz Fiser wrote: > > > > From: Andrej Picej <andrej.picej@norik.com> > > > > > > > > Document i.MX93 ADC calibration properties and how to set them. > > > > > > > > Signed-off-by: Andrej Picej <andrej.picej@norik.com> > > > > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> > > > > --- > > > > .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ > > > > 1 file changed, 21 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93- > > > > adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > > > index c2e5ff418920..d1c04cf85fe6 100644 > > > > --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > > > +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > > > > @@ -52,6 +52,27 @@ properties: > > > > "#io-channel-cells": > > > > const: 1 > > > > > > > > + nxp,calib-avg-en: > > > > + default: 1 > > > > + description: > > > > + Enable or disable calibration averaging function (AVGEN). > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + enum: [ 0, 1 ] > > > > + > > > > + nxp,calib-nr-samples: > > > > + default: 512 > > > > + description: > > > > + Selects number of samples (NRSMPL) to be used during calibration. > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + enum: [ 16, 32, 128, 512 ] > > > > Allow 1 as a value and drop the enabled above. Averaging over 1 sample > > is same as no averaging and gives simpler binding. > > > > > > + > > > > + nxp,calib-t-sample: > > > > + default: 22 > > > > + description: > > > > + Selects sample time (TSAMP) of calibration conversions in ADC > > > > clock cycles > > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > > + enum: [ 8, 16, 22, 32 ] > > > > + > > > > required: > > > > - compatible > > > > - reg > > > > > > This seem like things that should be set at runtime rather than > > > in the devicetree. Unless there is some justification on why > > > these values depend on how the chip is wired up? > > It depends how ADC 1.8V Vref is wired up, especially how noisy it is. > > > > > Further to that, I'd like to see some explanation of why we care > > to change it at all. Is it ever a bad idea to enable averaging and > > pick a large number of samples for calibration? > > This is a snippet from the i.MX93 TRM, chapter Analog-to-Digital > Converter (SAR_ADC) describing calibration steps: > > 1. Wait for deassertion of functional reset. > 2. Configure SAR controller operating clock (MCR[ADCLKSE] = 0). > 3. Bring ADC out of Power-down state (MCR[PWDN] = 0). > 4. Configure desired calibration settings (default values kept for > highest accuracy maximum time). > • MCR[TSAMP]: Sample time for calibration conversion > • MCR[NRSMPL]: Number of samples in averaging > • MCR[AVGEN]: Averaging function enable in calibration > 5. Run calibration by writing a one to MCR[CALSTART]. > 6. Check calibration run status in MSR[CALBUSY]—wait until MSR[CALBUSY] > = 0; alternatively, MSR[ADCSTAT] can be > used to check status. > 7. Check calibration pass/fail status in MSR[CALFAIL] field. If > MSR[CALFAIL] = 1 then calibration failed. Detailed status > can be checked in CALSTAT. > > > See point 4). > > Not sure why would there be an option to configure i.MX93 ADC > calibration parameters if one use-case (max accuracy max time) to rule > them all? > Sometimes HW guys just want to give you some options. Does not mean we have to use them all :). I guess what Jonathan is interested in, is to understand in what conditions the defaults are no good for the calibration? If we can have a set of values that should pretty much always work, no need to further complicate the bindings or the driver. - Nuno Sá > On the other hand, public TRM doesn't give much more information and > >
On Mon, Jul 14, 2025 at 05:11:31PM +0100, Nuno S? wrote:
>On Mon, 2025-07-14 at 07:56 +0200, Primoz Fiser wrote:
>> Hi all,
>>
>> On 13. 07. 25 17:02, Jonathan Cameron wrote:
>> > On Thu, 10 Jul 2025 10:46:44 -0500
>> > David Lechner <dlechner@baylibre.com> wrote:
>> >
>> > > On 7/10/25 2:39 AM, Primoz Fiser wrote:
>> > > > From: Andrej Picej <andrej.picej@norik.com>
>> > > >
>> > > > Document i.MX93 ADC calibration properties and how to set them.
>> > > >
>> > > > Signed-off-by: Andrej Picej <andrej.picej@norik.com>
>> > > > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com>
>> > > > ---
>> > > > ??.../bindings/iio/adc/nxp,imx93-adc.yaml???????????? | 21 +++++++++++++++++++
>> > > > ??1 file changed, 21 insertions(+)
>> > > >
>> > > > diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-
>> > > > adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>> > > > index c2e5ff418920..d1c04cf85fe6 100644
>> > > > --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>> > > > +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>> > > > @@ -52,6 +52,27 @@ properties:
>> > > > ???? "#io-channel-cells":
>> > > > ???????? const: 1
>> > > > ??
>> > > > +?? nxp,calib-avg-en:
>> > > > +?????? default: 1
>> > > > +?????? description:
>> > > > +?????????? Enable or disable calibration averaging function (AVGEN).
>> > > > +?????? $ref: /schemas/types.yaml#/definitions/uint32
>> > > > +?????? enum: [ 0, 1 ]
>> > > > +
>> > > > +?? nxp,calib-nr-samples:
>> > > > +?????? default: 512
>> > > > +?????? description:
>> > > > +?????????? Selects number of samples (NRSMPL) to be used during calibration.
>> > > > +?????? $ref: /schemas/types.yaml#/definitions/uint32
>> > > > +?????? enum: [ 16, 32, 128, 512 ]
>> >
>> > Allow 1 as a value and drop the enabled above.???? Averaging over 1 sample
>> > is same as no averaging and gives simpler binding.
>> >
>> > > > +
>> > > > +?? nxp,calib-t-sample:
>> > > > +?????? default: 22
>> > > > +?????? description:
>> > > > +?????????? Selects sample time (TSAMP) of calibration conversions in ADC
>> > > > clock cycles
>> > > > +?????? $ref: /schemas/types.yaml#/definitions/uint32
>> > > > +?????? enum: [ 8, 16, 22, 32 ]
>> > > > +
>> > > > ??required:
>> > > > ???? - compatible
>> > > > ???? - reg??
>> > >
>> > > This seem like things that should be set at runtime rather than
>> > > in the devicetree. Unless there is some justification on why
>> > > these values depend on how the chip is wired up?
>>
>> It depends how ADC 1.8V Vref is wired up, especially how noisy it is.
>>
>> >
>> > Further to that, I'd like to see some explanation of why we care
>> > to change it at all. Is it ever a bad idea to enable averaging and
>> > pick a large number of samples for calibration?
>>
>> This is a snippet from the i.MX93 TRM, chapter Analog-to-Digital
>> Converter (SAR_ADC) describing calibration steps:
>>
>> 1. Wait for deassertion of functional reset.
>> 2. Configure SAR controller operating clock (MCR[ADCLKSE] = 0).
>> 3. Bring ADC out of Power-down state (MCR[PWDN] = 0).
>> 4. Configure desired calibration settings (default values kept for
>> highest accuracy maximum time).
>> ??? MCR[TSAMP]: Sample time for calibration conversion
>> ??? MCR[NRSMPL]: Number of samples in averaging
>> ??? MCR[AVGEN]: Averaging function enable in calibration
>> 5. Run calibration by writing a one to MCR[CALSTART].
>> 6. Check calibration run status in MSR[CALBUSY]???wait until MSR[CALBUSY]
>> = 0; alternatively, MSR[ADCSTAT] can be
>> used to check status.
>> 7. Check calibration pass/fail status in MSR[CALFAIL] field. If
>> MSR[CALFAIL] = 1 then calibration failed. Detailed status
>> can be checked in CALSTAT.
>>
>>
>> See point 4).
>>
>> Not sure why would there be an option to configure i.MX93 ADC
>> calibration parameters if one use-case (max accuracy max time) to rule
>> them all?
>>
>
>Sometimes HW guys just want to give you some options. Does not mean we have to
>use them all :).
>
>I guess what Jonathan is interested in, is to understand in what conditions the
>defaults are no good for the calibration? If we can have a set of values that
>should pretty much always work, no need to further complicate the bindings or
>the driver.
Just my understanding, it is hard to use one fixed settings to fit all
kinds of conditions.
Noise induced from PCB tracks Electro- magnetic noise
| |
V V
---------
|SOC(ADC)| <---------------------------------<- (~) external Signal
---------
^ ^
| |
I/O coupled noise Internal noise
So OEM A's board may needs different settings compared with OEM B's board.
Regards,
Peng
>
>- Nuno S??
>> On the other hand, public TRM doesn't give much more information and
>> >
Hi Nuno, On 14. 07. 25 18:11, Nuno Sá wrote: > On Mon, 2025-07-14 at 07:56 +0200, Primoz Fiser wrote: >> Hi all, >> >> On 13. 07. 25 17:02, Jonathan Cameron wrote: >>> On Thu, 10 Jul 2025 10:46:44 -0500 >>> David Lechner <dlechner@baylibre.com> wrote: >>> >>>> On 7/10/25 2:39 AM, Primoz Fiser wrote: >>>>> From: Andrej Picej <andrej.picej@norik.com> >>>>> >>>>> Document i.MX93 ADC calibration properties and how to set them. >>>>> >>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com> >>>>> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> >>>>> --- >>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ >>>>> 1 file changed, 21 insertions(+) >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93- >>>>> adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>>>> index c2e5ff418920..d1c04cf85fe6 100644 >>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml >>>>> @@ -52,6 +52,27 @@ properties: >>>>> "#io-channel-cells": >>>>> const: 1 >>>>> >>>>> + nxp,calib-avg-en: >>>>> + default: 1 >>>>> + description: >>>>> + Enable or disable calibration averaging function (AVGEN). >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [ 0, 1 ] >>>>> + >>>>> + nxp,calib-nr-samples: >>>>> + default: 512 >>>>> + description: >>>>> + Selects number of samples (NRSMPL) to be used during calibration. >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [ 16, 32, 128, 512 ] >>> >>> Allow 1 as a value and drop the enabled above. Averaging over 1 sample >>> is same as no averaging and gives simpler binding. >>> >>>>> + >>>>> + nxp,calib-t-sample: >>>>> + default: 22 >>>>> + description: >>>>> + Selects sample time (TSAMP) of calibration conversions in ADC >>>>> clock cycles >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 >>>>> + enum: [ 8, 16, 22, 32 ] >>>>> + >>>>> required: >>>>> - compatible >>>>> - reg >>>> >>>> This seem like things that should be set at runtime rather than >>>> in the devicetree. Unless there is some justification on why >>>> these values depend on how the chip is wired up? >> >> It depends how ADC 1.8V Vref is wired up, especially how noisy it is. >> >>> >>> Further to that, I'd like to see some explanation of why we care >>> to change it at all. Is it ever a bad idea to enable averaging and >>> pick a large number of samples for calibration? >> >> This is a snippet from the i.MX93 TRM, chapter Analog-to-Digital >> Converter (SAR_ADC) describing calibration steps: >> >> 1. Wait for deassertion of functional reset. >> 2. Configure SAR controller operating clock (MCR[ADCLKSE] = 0). >> 3. Bring ADC out of Power-down state (MCR[PWDN] = 0). >> 4. Configure desired calibration settings (default values kept for >> highest accuracy maximum time). >> • MCR[TSAMP]: Sample time for calibration conversion >> • MCR[NRSMPL]: Number of samples in averaging >> • MCR[AVGEN]: Averaging function enable in calibration >> 5. Run calibration by writing a one to MCR[CALSTART]. >> 6. Check calibration run status in MSR[CALBUSY]—wait until MSR[CALBUSY] >> = 0; alternatively, MSR[ADCSTAT] can be >> used to check status. >> 7. Check calibration pass/fail status in MSR[CALFAIL] field. If >> MSR[CALFAIL] = 1 then calibration failed. Detailed status >> can be checked in CALSTAT. >> >> >> See point 4). >> >> Not sure why would there be an option to configure i.MX93 ADC >> calibration parameters if one use-case (max accuracy max time) to rule >> them all? >> > > Sometimes HW guys just want to give you some options. Does not mean we have to > use them all :). > > I guess what Jonathan is interested in, is to understand in what conditions the > defaults are no good for the calibration? If we can have a set of values that > should pretty much always work, no need to further complicate the bindings or > the driver. In case you have a noisy Vref you can adjust the parameters to pass the calibration and have a working ADC. The trade-off is a less precise ADC but at least a working one. In ideal case you would have Vref supplied by the dedicated LDO and tons of decoupling caps, but in real-world you have it connected to a noisy SMPS and you need to adjust the parameters accordingly. That's it :) BR, Primoz -- Primoz Fiser phone: +386-41-390-545 email: primoz.fiser@norik.com -- Norik systems d.o.o. Your embedded software partner Slovenia, EU phone: +386-41-540-545 email: info@norik.com
On Tue, 15 Jul 2025 07:46:44 +0200 Primoz Fiser <primoz.fiser@norik.com> wrote: > Hi Nuno, > > On 14. 07. 25 18:11, Nuno Sá wrote: > > On Mon, 2025-07-14 at 07:56 +0200, Primoz Fiser wrote: > >> Hi all, > >> > >> On 13. 07. 25 17:02, Jonathan Cameron wrote: > >>> On Thu, 10 Jul 2025 10:46:44 -0500 > >>> David Lechner <dlechner@baylibre.com> wrote: > >>> > >>>> On 7/10/25 2:39 AM, Primoz Fiser wrote: > >>>>> From: Andrej Picej <andrej.picej@norik.com> > >>>>> > >>>>> Document i.MX93 ADC calibration properties and how to set them. > >>>>> > >>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com> > >>>>> Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> > >>>>> --- > >>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ > >>>>> 1 file changed, 21 insertions(+) > >>>>> > >>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93- > >>>>> adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > >>>>> index c2e5ff418920..d1c04cf85fe6 100644 > >>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > >>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > >>>>> @@ -52,6 +52,27 @@ properties: > >>>>> "#io-channel-cells": > >>>>> const: 1 > >>>>> > >>>>> + nxp,calib-avg-en: > >>>>> + default: 1 > >>>>> + description: > >>>>> + Enable or disable calibration averaging function (AVGEN). > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>>> + enum: [ 0, 1 ] > >>>>> + > >>>>> + nxp,calib-nr-samples: > >>>>> + default: 512 > >>>>> + description: > >>>>> + Selects number of samples (NRSMPL) to be used during calibration. > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>>> + enum: [ 16, 32, 128, 512 ] > >>> > >>> Allow 1 as a value and drop the enabled above. Averaging over 1 sample > >>> is same as no averaging and gives simpler binding. > >>> > >>>>> + > >>>>> + nxp,calib-t-sample: > >>>>> + default: 22 > >>>>> + description: > >>>>> + Selects sample time (TSAMP) of calibration conversions in ADC > >>>>> clock cycles > >>>>> + $ref: /schemas/types.yaml#/definitions/uint32 > >>>>> + enum: [ 8, 16, 22, 32 ] > >>>>> + > >>>>> required: > >>>>> - compatible > >>>>> - reg > >>>> > >>>> This seem like things that should be set at runtime rather than > >>>> in the devicetree. Unless there is some justification on why > >>>> these values depend on how the chip is wired up? > >> > >> It depends how ADC 1.8V Vref is wired up, especially how noisy it is. > >> > >>> > >>> Further to that, I'd like to see some explanation of why we care > >>> to change it at all. Is it ever a bad idea to enable averaging and > >>> pick a large number of samples for calibration? > >> > >> This is a snippet from the i.MX93 TRM, chapter Analog-to-Digital > >> Converter (SAR_ADC) describing calibration steps: > >> > >> 1. Wait for deassertion of functional reset. > >> 2. Configure SAR controller operating clock (MCR[ADCLKSE] = 0). > >> 3. Bring ADC out of Power-down state (MCR[PWDN] = 0). > >> 4. Configure desired calibration settings (default values kept for > >> highest accuracy maximum time). > >> • MCR[TSAMP]: Sample time for calibration conversion > >> • MCR[NRSMPL]: Number of samples in averaging > >> • MCR[AVGEN]: Averaging function enable in calibration > >> 5. Run calibration by writing a one to MCR[CALSTART]. > >> 6. Check calibration run status in MSR[CALBUSY]—wait until MSR[CALBUSY] > >> = 0; alternatively, MSR[ADCSTAT] can be > >> used to check status. > >> 7. Check calibration pass/fail status in MSR[CALFAIL] field. If > >> MSR[CALFAIL] = 1 then calibration failed. Detailed status > >> can be checked in CALSTAT. > >> > >> > >> See point 4). > >> > >> Not sure why would there be an option to configure i.MX93 ADC > >> calibration parameters if one use-case (max accuracy max time) to rule > >> them all? > >> > > > > Sometimes HW guys just want to give you some options. Does not mean we have to > > use them all :). > > > > I guess what Jonathan is interested in, is to understand in what conditions the > > defaults are no good for the calibration? If we can have a set of values that > > should pretty much always work, no need to further complicate the bindings or > > the driver. > > In case you have a noisy Vref you can adjust the parameters to pass the > calibration and have a working ADC. That's a fairly odd sounding situation. Is this a case of it will always pass because there is some drift going on or something low frequency like that? Or is it a case of retry until it passes? Jonathan > > The trade-off is a less precise ADC but at least a working one. > > In ideal case you would have Vref supplied by the dedicated LDO and tons > of decoupling caps, but in real-world you have it connected to a noisy > SMPS and you need to adjust the parameters accordingly. > > That's it :) > > BR, > Primoz >
On Thu, Jul 10, 2025 at 09:39:03AM +0200, Primoz Fiser wrote: > From: Andrej Picej <andrej.picej@norik.com> > > Document i.MX93 ADC calibration properties and how to set them. > > Signed-off-by: Andrej Picej <andrej.picej@norik.com> > Signed-off-by: Primoz Fiser <primoz.fiser@norik.com> > --- > .../bindings/iio/adc/nxp,imx93-adc.yaml | 21 +++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > index c2e5ff418920..d1c04cf85fe6 100644 > --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml > @@ -52,6 +52,27 @@ properties: > "#io-channel-cells": > const: 1 > > + nxp,calib-avg-en: > + default: 1 > + description: > + Enable or disable calibration averaging function (AVGEN). > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 0, 1 ] bool type should be enough > + > + nxp,calib-nr-samples: > + default: 512 > + description: > + Selects number of samples (NRSMPL) to be used during calibration. > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 16, 32, 128, 512 ] > + > + nxp,calib-t-sample: > + default: 22 > + description: > + Selects sample time (TSAMP) of calibration conversions in ADC clock cycles > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [ 8, 16, 22, 32 ] Need some judgement in commit message, such as difference board need difference nxp,calib-nr-samples value. Frank > + > required: > - compatible > - reg > -- > 2.34.1 >
© 2016 - 2025 Red Hat, Inc.