lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241109153946.4f4df9d2@jic23-huawei>
Date: Sat, 9 Nov 2024 15:39:46 +0000
From: Jonathan Cameron <jic23@...nel.org>
To: David Lechner <dlechner@...libre.com>
Cc: "Miclaus, Antoniu" <Antoniu.Miclaus@...log.com>, "conor+dt@...nel.org"
 <conor+dt@...nel.org>, "linux-iio@...r.kernel.org"
 <linux-iio@...r.kernel.org>, "devicetree@...r.kernel.org"
 <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "linux-pwm@...r.kernel.org"
 <linux-pwm@...r.kernel.org>
Subject: Re: [PATCH v5 6/6] iio: adc: ad4851: add ad485x driver

On Thu, 7 Nov 2024 10:47:52 -0600
David Lechner <dlechner@...libre.com> wrote:

> On 11/7/24 10:13 AM, David Lechner wrote:
> > On 11/7/24 4:51 AM, Miclaus, Antoniu wrote:  
> 
> 
> >>> I'm pretty sure that calibscale and calibbias also need to take into
> >>> account if resolution boost is enabled or not.  
> >>
> >> Can you please detail a bit on this topic? I am not sure what I should do.
> >>  
> > 
> > We haven't implemented oversampling yet in ad4695 yet, so I don't know
> > exactly what we need to do either. ;-)
> > 
> > But this is how I would test it to see if it is working correctly or
> > not. We will need to test this with a 20-bit chip since that is the
> > only one that will change the _scale attribute when oversampling is
> > enabled.
> > 
> > First, with oversampling disabled (_oversampling_ratio = 1), generate
> > a constant voltage of 1V for the input. Read the _raw attribute. Let's
> > call this value raw0. Read the _scale attribute, call it scale0 and
> > the _offset attribute, call it offset0.
> > 
> > Then we should have (raw0 + offset0) * scale0 = 1000 mV (+/- some
> > noise).
> > 
> > Then change the offset calibrate to 100 mV. To do this, we reverse
> > the calculation 100 mV / scale0 = calibbias (raw units). Write the
> > raw value to the _calibbias attribute. Then read the _raw
> > attribute again, call it raw0_with_calibbias.
> > 
> > This time, we should have (raw0_with_calibbias + offset0) * scale0
> > = 1100 mV (+/- some noise).
> > 
> > Then set _calibbias back to 0 and repeat the above by setting the
> > _calibscale attribute to 0.90909 (this is 1 / 1.1, which should  
> 
> Now that I have written this, this has me second-guessing if I
> implemented calibscale correctly on ad4695. It would seem more
> logical that if we have an actual input voltage of 1 V and a
> calibscale of 1.1, then the resulting processed value we read
> should be 1100 mV.
> 
> Jonathan, can you set me straight? The sysfs ABI docs aren't
> clear on this point.

Deliberately vague in this case.  calibbias is kind of the wild west
of ABI. Often we have no meaningful information on what the tweak
register settings actually do beyond 'up vs down'.  In some cases
the datasheets even refer to them as taps up or taps down.

I don't think we've ever said if it should be consistent as you
change other parameters.  If you care about calibration you probably
need to redo it for your new settings anyway and tweak the calibbias
/calibscale till it gives the right values.

Obviously that is easier to do if you have a consistent scheme for
a given device and if possible allow calibrating at just one setting
but I don't think we can apply general rules.

Jonathan

> 
> > add 10% to the measured raw value). Read, the _raw attribute again,
> > call it raw0_with_caliscale.
> > 
> > This time, we should have (raw0_with_caliscale + offset0) * scale0
> > = 1100 mV (+/- some noise).
> > 
> > Set _calibscale back to 0. Then set _oversampling_ratio to 2. Read
> > _scale and _offset again, call these scale1 and offset1.
> > 
> > Then repeat the steps above using scale1 and offset1 in the
> > calculations. The raw values will be different but the resulting
> > processed values (mV) should all be the same if the attributes
> > are implemented correctly.
> >   


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ