RFC parameter based voltage scaling

RFC parameter based voltage scaling

[Grant Coady]

Greetings,

Parameter based conversions is an easy way for drivers to scale 
voltages with fixed point math.

I've written fixed point math routines in bash to prove the concept, 
but if driver scaling has been vetoed, I'd rather know now than 
submit something unwanted.  lm87 driver almost has it, carrying 
scaling factors in private memory, loaded at chip detect time.

Surveying the Winbond sensor chips, I came up with:

/*
 * Winbond inX internal scaling -- fullscale is 4096mV, Vref is 3600mV
 *
 * These sensor chips perform internal scaling for 5V (in3) and 5VSB
 * Using datasheet resistor values for traceability:
 *
 * 83781D, 83782D, 83783D, 83L784R      5V is 34/50
 * 83726F, 83726HF, 83697HF             5V is 34/50, 5VSB is 17/33
 * 83627THF, 83637HF                    5V is 34/51, 5VSB is 34/51
 */
static const u8 r1[] = {0, 0, 0, 34, 0, 0, 0, 17, 0};
static const u8 r2[] = {1, 1, 1, 50, 1, 1, 1, 33, 1};

static inline unsigned long IN_FROM_REG(u8 reg, int n)
{
        return SCALE(reg, 4096 * (r1[n] + r2[n]), 256 * r2[n]);
}

static inline u8 IN_TO_REG(unsigned long val, int n)
{
        return SENSORS_LIMIT(SCALE(val, 256 * r2[n],
                                4096 * (r1[n] + r2[n])), 0, 255);
}

Of course a 'real' driver would have the table in private memory and 
load appropriate values on chip detect, lm87 does this, worth doing 
for Winbond?

There is not much more to making some of the values preset to chip 
standard values for +12 and negative, and making those external to 
sensor chip values settable from user-space.

Comments?  

--Grant.

RFC parameter based voltage scaling

[Jean Delvare]

Hi Grant,

> I've written fixed point math routines in bash to prove the concept,
> but if driver scaling has been vetoed, I'd rather know now than
> submit something unwanted.  lm87 driver almost has it, carrying
> scaling factors in private memory, loaded at chip detect time.

The rule is: drivers should provide the voltages as seen at their pins.
This means that, where scaling is external, it has to be done in
user-space, while where scaling is internal, it has to be done by the
driver itself. All drivers respect that rule as far as I remember.

> * Winbond inX internal scaling -- fullscale is 4096mV, Vref is 3600mV
> *
> * These sensor chips perform internal scaling for 5V (in3) and 5VSB

I don't think so. Can you point us to a datasheet stating this?

> Comments?

Your code makes sense for external resistors, but not for internal
scaling as far as I can see, so it won't be of any help in the drivers.
And libsensors mostly works the way you describe already, just not in as
formal a way (because compute lines were meant for all values, not just
voltages).

So all in all I think that you are trying to fix a problem that doesn't
exist in the first place, sorry.

--
Jean Delvare

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Mon, 9 May 2005 15:35:36 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

>> but if driver scaling has been vetoed, I'd rather know now than
>> submit something unwanted.  lm87 driver almost has it, carrying
>> scaling factors in private memory, loaded at chip detect time.
>
>The rule is: drivers should provide the voltages as seen at their pins.

Yes, so the Winbond drivers (at least w82627hf) do not report pin 
voltage for 5V and 5VSB thus need this or similar fix.

>This means that, where scaling is external, it has to be done in
>user-space, while where scaling is internal, it has to be done by the
>driver itself. All drivers respect that rule as far as I remember.

Except the exceptions :)

>> * These sensor chips perform internal scaling for 5V (in3) and 5VSB
>
>I don't think so. Can you point us to a datasheet stating this?

Any Winbond datasheet :)

W83L784R 6.3.1:
"The first function is to supply internal analog power in the W83L784R 
and the second function is that this voltage with 5V is connected to 
internal serial resistors to monitor the +5V voltage. The value of 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
two serial resistors are 34K ohms and 50K ohms so that input voltage 
                         ^^^^^^^^^^^^^^^^^^^^^
to ADC is 2.98V which is less than 4.096V of ADC maximum input voltage."

W83627HF:
"The first function is to supply internal analog power in the W83627HF 
and the second function is that this voltage with 5V is connected to 
internal serial resistors to monitor the +5V voltage. The value of two 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
serial resistors are 34K ohms and 50K ohms so that input voltage to ADC
                     ^^^^^^^^^^^^^^^^^^^^^
is 2.98V which is less than 4.096V of ADC maximum input voltage.

The Pin 61 is connected to 5VSB voltage. W83627HF monitors this voltage 
and the internal two serial resistors are 17K W and 33K W so that input 
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-- W is ohm symbol
voltage to ADC is 3.3V which less than 4.096V of ADC maximum input voltage."

W83627THF Section 7.3.1 pin 114, pin 61 34k, 51k

Need I go on?  I surveyed every datasheet I could find (w83697hf circuit 
overlay problem been fixed too).
>
>> Comments?
>
>Your code makes sense for external resistors, but not for internal
>scaling as far as I can see, so it won't be of any help in the drivers.

Okay another exception for Winbond chips.  But this method can go 
either place, driver or user-space, I'm trying to demonstrate a 
different way of doing scaling that suits end-user calibration, as 
well as point out where drivers differ from sysfs standard usage.

>And libsensors mostly works the way you describe already, just not in as
>formal a way (because compute lines were meant for all values, not just
>voltages).

libsensors compute lines suit most situations, I hit one where it 
fails, plus the silliness (IMHO) of entering every formula twice, 
parameter based scaling avoids that, what I'm discussing here is 
something for voltages, that seems to work very well.  Whether it 
gets into sensors as an alternate compute method, or is a utility 
that produces 'normalised' compute terms doesn't really matter in 
long run.

The benefit of doing resistor based scaling is that resistor value 
are in a discrete value series so one may pick an unambiguous pair 
for a particular positive or negative voltage reading.  A user-space 
program can take observed reading (BIOS or measured) and produce 
'best match' pair that works, as mobo maker using same discrete 
value series.

You did ask me once how to do scaling without reciprocal formula 
entry?  This is one way how.  It doesn't have to go into driver, 
though perhaps partially, to meet self-scaled input requirements.

>So all in all I think that you are trying to fix a problem that doesn't
>exist in the first place, sorry.

Disagree :o)  The story:

I started on this originally because I could find no documentation on 
which adm9240 VccpX input was monitoring respective -5 and -12 volt 
inputs on Intel SE440BX-2 mobo -- what surprised me back then was the 
totally unambiguous answer the method of using resistor series values 
gave.  Not only told me resistor values, it unambiguously told me which 
sensor input was measuring which negative voltage.  I think I posted 
that here a while ago.  

libsensors cannot compute negative voltages for adm9240 as they require 
two inputs for the calculation?  You not corrected that notion for me, 
did I miss some thing in compute syntax or it simply isn't there?  
ADM9240 has no reference to drive top of resistor divider, so one must 
measure 5V and VccpX in order to discover negative reading.

There are notes in archives about adm9240 having problems displaying 
correct voltages, if they mean negative voltages I have the answer, 
further, as it compares observed vs measured value it accounts for 
input pin loading (~140k).

Parameter based conversion fixes the compute lines for voltages by 
relating them to 'real world' values that can be inferred, you might 
consider that idea for libsensors, I get terribly confused by the 
number of exceptions to the 'rules' for drivers :)

An alternative is to simply provide a script that does the resistor 
ratio stuff then 'normalise' the result so it can be plugged into 
sensors.  Least disturbance of the system?  Plus the ability to tell 
which input is monitoring what voltage -- maybe I was lucky with Intel, 
they used E12 (10%) series, E24 (5%) series works well, my studies 
indicate E24 series would be close enough, given the relatively poor 
resolution and accuracy of the sensor chip measurements. 

Trialling with E96 (1%) series is too noisy on 12V measurement due 
to poor measurement resolution, and it was a single bit (16mV) doing 
the damage -- when it was 'right' datasheet value came up (56/232), 
one bit higher and a different offering.

I'm still exploring the hwmon system, finding a balance between what 
can be done versus what should be done in drivers, I now see we don't 
really want a lot of extra accessors populating sysfs if that is so 
expensive.  I did go back to the Jan2003 sysfs discussions, so I'm 
dragging up stuff that you have already settled.  This is still new 
area for me.

Sensors needs a cleanup, and it seems right at the core parser, that's
not a nice one to take on, but from end-user point of view it needs 
doing.  One day :)  The lex/yacc parser in sensors is not terribly 
bright, I've forgotten if there is more modern way to build a parser, 
but the core parser doesn't look right, although its been a few years 
since I did one ('97 or '98), I'd have to dig it up and look.

The techniques, ideas I'm exploring don't _have_ to go into the 
drivers, I'm running them either way, direct sysfs access with shell 
script (see below) or in driver, that is not an issue for me.  Though 
I had to ask when I see it so close to being done in driver, but then 
complicated by the restrictions placed on sysfs data transfer and 
naming.  

Okay, I'm dancing all over the drivers at the moment, trying to discover 
boundaries, as many are not documented.  

Once I have an idea of boundaries, document that, look at what is left 
for user-space.  At times I'm being too picky as measurement and control 
design is what I did for a living a long time ago.  Other times I can't 
see wood for trees.  (older I get, better I was :)

Example with: Linux 2.6.12-rc3-mm3b.  (First time I been game to boot -mm)

root@sempro:~# lsmod
Module                  Size  Used by
w83627hf               29480  0
i2c_sensor              2944  1 w83627hf <<= unmodified
i2c_isa                 1856  0
via_agp                 7744  1
agpgart                29256  1 via_agp


Grant's voltage divider value finder,
R1 is from E24 (5%) series, R2 from E24 series

Working on:    12V
~~~~~~~~~~~~~~~~~~
     R1      R2    Error  Series
    ----   -----   ------   ---
    2000    5600   0.088%   E24  <<= match datasheet 10/28 (28 is from E96)
    4300   12000   0.249%   E24

Working on:   -12V
~~~~~~~~~~~~~~~~~~
     R1      R2    Error  Series
    ----   -----   ------   ---
    2400   10000   0.030%   E24  <<= closet to datasheet 56/232 = 0.241
    1800    7500   0.040%   E24
    3600   15000   0.107%   E24
    4300   18000   0.423%   E24

Working on:    -5V
~~~~~~~~~~~~~~~~~~
     R1      R2    Error  Series
    ----   -----   ------   ---
    5600   12000   0.074%   E24  <<= matches datasheet suggested values
    2200    4700   0.212%   E24
    2000    4300   0.490%   E24


   x     raw    BIOS   final   label   R1   R2
   0    1552    1550    1552   Vcore    0    0
   2    3296    3290    3296     3.3    0    0
   3    3040    5130    5107       5   50   34  <<= 50/34 are internal to sensor chip
   4    3152   11970   11977      12   20   56
   5     624  -11780  -11705     -12   56  232
   6     848   -5040   -5049      -5   56  120
   7    3280    5070    4969    5VSB   33   17  <<= 33/17 also internal resistors
   8    3376    3370    3376   Vbatt    0    0

raw is what sysfs gives, BIOS are observed readings, final are readings 
as per label column with R1, R2 as per:

#      -------o--> +5V, +5VSB, +12V   Measuring positive V > 4V
#             |     Vplus
#             -
#            | | R2        ----------------------   Measuring negative V
#            | |          |                      |   ____       ____
#             -           |          3600mV Vref |--|____|--o--|____|--->
#             |      Vin  |                      |    R1    |    R2
#             o-----------| 0..4096mV            |          |        -5V, -12V
#             |           |            0..4096mV |----------          Vminus
#             -           | W83697HF             | Vin
#            | | R1       |                      |
#            | |           ----------------------
#             -
#             |
#      -------o--> 0V

Data structure is simple (for w83697hf):

Vlabel=("Vcore" "-" "  3.3" "    5" "   12" "  -12" "   -5" " 5VSB" "Vbatt")
#                  +5 +12 -12  -5 5VSB
Vsfind=(0   0   0   0   1   2   2   0   0)      # 0 builtin, 1 = pos, 2 = neg
Vscale=(0   0   0   1   1   2   2   1   0)      # 0 noscale, 1 = pos, 2 = neg
R1spec=(0   0   0  50  20  56  56  33   0)      # known and datasheet values
R2spec=(0   0   0  34  56 232 120  17   0)
Vbios=(1550 0 3290 5130 11970 -11780 -5040 5070 3370) # mV reported by BIOS

Summary
````````
I've described a parameter based voltage reporting system that suits 
some chips that describe their scaling in terms of resistor values, 
a method for calibrating sensor readings to match observed BIOS or 
measured readings.  The result of this can be 'normalised' to suit 
current libsensors 'compute' lines or placed in drivers where needed.

A mobo manufacturer is likely to use less expensive E12 or E24 series 
resistor values for external voltage scaling.  My 2 of 2 mobo survey 
confirms this.  One mobo left to try is a the Gigglebyte shambles that 
does not follow manuf. guidelines (it87).

As far as drivers go, the winbond series drivers need fixing to report 
internally scaled voltages, winbond have two standards: an earlier 
5V -> 34/50, 5VSB -> 17/33 (where present), and a later standard where 
both 5V and 5VSB are 34/51.

Query
``````
The query I have is how to tell libsensors to produce a negative voltage 
readings for adm9240, as each depends on two input channel values.

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Mon, 9 May 2005 15:35:36 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

>Your code makes sense for external resistors, but not for internal
>scaling as far as I can see, so it won't be of any help in the drivers.
>And libsensors mostly works the way you describe already, just not in as
>formal a way (because compute lines were meant for all values, not just
>voltages).

>So all in all I think that you are trying to fix a problem that doesn't
>exist in the first place, sorry.

Just reviewed /etc/sensors.conf again, negative voltage calculation 
is totally bogus as it does not account for reference voltage driving 
top of resistor divider.  The proof is that you do not have correct 
Winbond resistor values in the sample calculations.  They're fudged.

+12V: compute in4 ((28/10)+1)*@  ,  @/((28/10)+1)  uses Winbond values

Fudged negative calculations:

-12V: compute in5 -(210/60.4)*@  ,  -@/(210/60.4)  210/60.4 = 3.47
	versus datasheet: 232/56 = 4.14

-5V: compute in6 -(90.9/60.4)*@ ,  -@/(90.9/60.4) 90.9/60.4 = 1.5
	versus datasheet: 120/56 = 2.14

Parameter based calculation does not have these issues, doesn't 
need floating point either.  I think this is the background thing 
bugging me for weeks since I looked at sensors.conf

What do you need for further proof?  My interest is correctness.

Numbers traceable to datasheet is easy way.  My last reply 
detailed calibration to mobo use of other than sensor chip 
suggested values.

Another section of my shell script (fixed point math):

Vref600 # mV reference driving top of Vminus voltage divider

function scale_voltage # nr, scale type: none, plus, minus
{
        local r1=${R1spec[${1}]}
        local r2=${R2spec[${1}]}
        local in=${Vread[${1}]}
        case $2 in
                0 ) Vshow[${1}]=$in;;
                1 ) Vshow[${1}]=$(((in * (r1 + r2) + r1 / 2) / r1));;
                2 ) Vshow[${1}]=$(((((in - Vref) * r2 + r1 / 2) / r1) + in));;
                * ) Vshow[${1}]=0;;
        esac
}

--Grant.

RFC parameter based voltage scaling

[Jean Delvare]

Hi Grant,

> Yes, so the Winbond drivers (at least w82627hf) do not report pin
> voltage for 5V and 5VSB thus need this or similar fix.

Seems that you're correct there. Looking at my pc87360 driver, it has
the same problem (in7, in8 and in10 are internally scaled, yet the
scaling is done by libsensors).

Now, as to whether this should be fixed, depends on how much complexity
it adds to the drivers. Also note that this will cause trouble to the
users (which will have to remove compute lines from /etc/sensors.conf).

> > Your code makes sense for external resistors, but not for internal
> > scaling as far as I can see, so it won't be of any help in the drivers.
>
> Okay another exception for Winbond chips.

Correct. First time I see this usually internal scaling is about
normalized values, not resistor ratios.

> The benefit of doing resistor based scaling is that resistor value
> are in a discrete value series so one may pick an unambiguous pair
> for a particular positive or negative voltage reading.  A user-space
> program can take observed reading (BIOS or measured) and produce
> 'best match' pair that works, as mobo maker using same discrete
> value series.

Feel free to distribute such a user-space tool, so you'll see how useful
people find it. I am quite suspicious about the fact that it'll work
for all motherboards. Not all voltage inputs might use two resistors for
scaling (think inverting amps, amps, reference voltages...). There are
also many different measured voltages (Vcore, Vram, Vagp, +1.5, +3.3,
+5, +12, -12, -5, battery...) some of which change depending on the
system. Depending on the ADC, some may need scaling or not (e.g. +3.3
needs scaling on the PC87366). I think you'll have a very hard time
writing a tool dealing with all the cases.

> You did ask me once how to do scaling without reciprocal formula
> entry?  This is one way how.  It doesn't have to go into driver,
> though perhaps partially, to meet self-scaled input requirements.

Only works for voltages. They are the main user of compute lines for
sure, but not the only ones. For this reason, I'd prefer your tool to
generate the compute lines rather than modifying libsensors to handle a
different syntax.

Maybe a simple document would even be just as useful.

> I started on this originally because I could find no documentation on
> which adm9240 VccpX input was monitoring respective -5 and -12 volt
> inputs on Intel SE440BX-2 mobo -- what surprised me back then was the
> totally unambiguous answer the method of using resistor series values
> gave.  Not only told me resistor values, it unambiguously told me which
> sensor input was measuring which negative voltage.  I think I posted
> that here a while ago.

You did. It worked for you, great, but you knew what you were after, and
had only two missing inputs. The general case is much more complex than
that.

> libsensors cannot compute negative voltages for adm9240 as they require
> two inputs for the calculation?  You not corrected that notion for me,
> did I miss some thing in compute syntax or it simply isn't there?

Compute lines can refer to input values, e.g.:

  compute in5  (@ - in3) * 2, @ / 2 + in3

Isn't it what you need? Just make sure that compute lines are in the
right order (I think it matters).

> Sensors needs a cleanup, and it seems right at the core parser, that's
> not a nice one to take on, but from end-user point of view it needs
> doing.  One day :)  The lex/yacc parser in sensors is not terribly
> bright, I've forgotten if there is more modern way to build a parser,
> but the core parser doesn't look right, although its been a few years
> since I did one ('97 or '98), I'd have to dig it up and look.

Totally agree with you here, the parser is very hard to maintain, lex and
yacc aren't my friends. And it leaks memory...

But rather than trying to fix that broken libsensors, writing a new one
would be more useful IMHO (but this requires finishing the sysfs
interface as I said before).

--
Jean Delvare

RFC parameter based voltage scaling

[Jean Delvare]

Hi Grant,

> Just reviewed /etc/sensors.conf again, negative voltage calculation
> is totally bogus as it does not account for reference voltage driving
> top of resistor divider.  The proof is that you do not have correct
> Winbond resistor values in the sample calculations.  They're fudged.

This is no proof. Winbond datasheet are not always accurate (*cough*),
and motherboards have a long history of not following the
recommendations anyway.

That being said, I have found similar errors in the past (mostly broken
rounding in the drivers) so I wouldn't be surprised if there are more.

> Parameter based calculation does not have these issues, doesn't
> need floating point either.

Just because the resistors value are integers doesn't mean you don't
need floating point. Future resistors may not have integer values, and
also libsensors currently provides the chip voltage values in Volts, as
floats.

> Numbers traceable to datasheet is easy way.

And mostly useless, unfortunately, for the reasons given above. Most
datasheets are hints at best.

--
Jean Delvare

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Tue, 10 May 2005 14:35:31 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

>
>Hi Grant,
>
>> Just reviewed /etc/sensors.conf again, negative voltage calculation
>> is totally bogus as it does not account for reference voltage driving
>> top of resistor divider.  The proof is that you do not have correct
>> Winbond resistor values in the sample calculations.  They're fudged.
>
>This is no proof. Winbond datasheet are not always accurate (*cough*),
>and motherboards have a long history of not following the
>recommendations anyway.

The trouble with these datasheets is people often confuse resolution 
with accuracy, these chips are accurate to a few percent, the 
resolution problem stops me using E96 (1%) resistor series as the 
signal ~ noise on a one bit change in reading (my 12V flips between 
two readings, a polling averager could smooth that into an intermediate 
value, adding partial bit resolution.

In the paragraph above the Winbond examples. the formula is wrong, 
it doesn't account for reference driving top of driver, if you look 
at raw vs indicated in my number table, you see winbond raw values 
are roughly 3V below reference: ~600mV and ~800 mV --> that's the 
documented error in sensors.conf as it states negative measurements 
are at about 3V at the chip pin.  The document is wrong.  

>
>That being said, I have found similar errors in the past (mostly broken
>rounding in the drivers) so I wouldn't be surprised if there are more.
Round in drivers with fixed point can be kept below 1/2 % easy, 
I'm talking about somebody fudging a non-traceable formula in the 
document.  It may be the expression can be fixed, I find it difficult 
to work with bad docs, it has taken me weeks to prove this part of 
the system.  
>
>> Parameter based calculation does not have these issues, doesn't
>> need floating point either.
>
>Just because the resistors value are integers doesn't mean you don't
>need floating point. Future resistors may not have integer values, and
>also libsensors currently provides the chip voltage values in Volts, as
>floats.
Floating point is convenient for user-space, my focus on fixed point 
was for driver use, if it was allowed.  Fixed point has that annoying 
step of removing the sign from the number to the right of the decimal 
point :)  

Future resistor values come in E96 series which is a noisy calculation, 
the other option is resnet's where you might get 10/20 ratio or 10/30 
ratio which is also covered in E24 series.  

I've already demonstrated that E24 resistor ratios are below the basic 
error of the sensor chip.  E24 series over two decades gives ratios to 
much better than 1/2%, point 2: is that mobo makers are likely to use 
cheap 5% resistors, point 3: with winbond you're looking at ~60mV 
measurement resolution for 12V, the adm9240 was about 90mV resolution 
for -12V.

>And mostly useless, unfortunately, for the reasons given above. Most
>datasheets are hints at best.

Sort of, datasheets can be poorly expressed, poorly understood when 
one doesn't have the hardware, sure.  The errors I'm finding are way 
beyond that.  You're trying to tell a former electronics design 
engineer who was working with 50000 count A/D converters 20 years 
ago how to read datasheets and where error terms come from?  

And here we are, using 256 count converters, this aint rocket science.  

I did fixed point so it could be used in drivers, float point is 
convenient for user-space, I'm not against float point per se, my 
working in fixed point was to find error terms for drivers, there 
is a dataloss -> div/0 problem I encountered, took ages to fix, 
'cos Ohm's Law was being violated :)  And silly me put in a skip 
if zero which masked the issue for some time.  

I prefer to see obvious data transforms, traceable to datasheet, 
so Winbond begs for resistor ratios.

And I haven't looked at temperature yet :)

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Tue, 10 May 2005 14:28:54 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

>> Yes, so the Winbond drivers (at least w82627hf) do not report pin
>> voltage for 5V and 5VSB thus need this or similar fix.
>
>Seems that you're correct there. Looking at my pc87360 driver, it has
>the same problem (in7, in8 and in10 are internally scaled, yet the
>scaling is done by libsensors).
>
>Now, as to whether this should be fixed, depends on how much complexity
>it adds to the drivers. Also note that this will cause trouble to the
>users (which will have to remove compute lines from /etc/sensors.conf).

Depends how far you want to go, normalised fullscale mV lookup is 
simple, just a static lookup array of u16.  I suspect static lookups 
are cheaper than 'fancy code'.

Full-blown scaling needs r/w accessors to private memory values 
and a normalised resistor ratio, not much, but seems against policy.

This is why I'm discussing, not coding.  Right now we are is a mixed 
state, one could just as easily argue all scaling done in user space.

This mix of half + half is confusing, inconsistent and difficult to 
resolve.  Yes.  Having the _option_ of driver based scaling lets us 
have it both ways, default to existing system, offer optional scaling 
for new stuff, I'd like to do it like this as it doesn't break 
libsensors, but _does_ allow drivers to work independently, thus avoid 
having to keep two systems in step. 
>
>> Okay another exception for Winbond chips.
>
>Correct. First time I see this usually internal scaling is about
>normalized values, not resistor ratios.

Yes, but I think scaling should be traceable to data sheet expression 
of scaling method is good, so I worked out how to do that in fixed 
point.  I've done winbond the other way too, 'faking' the effective 
fullscale measurement range for Winbond:  5V -> 6881mV fullscale, and 
5VSB is 6205mV fullscale.  Trouble is, you end up with a u16 array 
lookup of mostly 4096mV values, it looked silly :)

Perhaps my pair of u8 resistor arrays looked just as silly to you?

I did it that way so values traceable to datasheet, it is also very 
close to full-blown scaling in driver at small cost of placing 
arrays in memory, and r/w accessors for changeable inputs (non-
changeable could be r/o accessor as place holder)

>Feel free to distribute such a user-space tool, so you'll see how useful
>people find it. I am quite suspicious about the fact that it'll work
>for all motherboards. Not all voltage inputs might use two resistors for
>scaling (think inverting amps, amps, reference voltages...). There are
>also many different measured voltages (Vcore, Vram, Vagp, +1.5, +3.3,
>+5, +12, -12, -5, battery...) some of which change depending on the
>system. Depending on the ADC, some may need scaling or not (e.g. +3.3
>needs scaling on the PC87366). I think you'll have a very hard time
>writing a tool dealing with all the cases.

Well yes, I'm only addressing one issue, mobo makers changing external 
divider resistors, and a reliable method to account for that one aspect.

Not replacing the whole thing :)

Example, I installed msft win on new machine to get second opinion 
on fan control (They can't do it either), and the 5VSB was reported 
as 5.5V --> I know why now: they used 34/50 instead of 17/33 for 
5VSB.  Didn't read datasheet...  

That the simple task I wanted to address: mobo make used different 
resistor divider to manuf. recommended, how to discover?  It works 
for that one purpose I wanted, and works well.  I'm not suggesting 
it has any use beyond that, certainly not as a replacement for 
existing code, just one way to resolve a particular problem, the 
new idea here is using the typical discrete resistor value series 
to discover viable ratios.

>Only works for voltages. They are the main user of compute lines for
>sure, but not the only ones. For this reason, I'd prefer your tool to
>generate the compute lines rather than modifying libsensors to handle a
>different syntax.

Oh sure, as I get to know the system I can see libsensors can do the 
job, not even a different syntax (I don't think), more below...

So yes, once we discover resistor ratio it can go straight in to 
libsensors syntax compute line, no problem.  
>
>Maybe a simple document would even be just as useful.

Yes, I'm working up to that, a document and a small program/script 
that takes observed readings and produces likely resistor ratios 
leading to compute lines for libsensors is end result.  This is 
aimed squarely at +12, -5 and -12 readings, nothing more.

What surprised me was it tells me quite accurately the required 
resistor ratios, yes it addresses this one aspect, but isn't that 
often requested?  Why are mobo readings so different BIOS vs sensors?

>Compute lines can refer to input values, e.g.:
>
>  compute in5  (@ - in3) * 2, @ / 2 + in3
>
>Isn't it what you need? Just make sure that compute lines are in the
>right order (I think it matters).

Thanks, I didn't pick that up from documentation, but it was long 
time ago I looked.  Yes, it is what I needed :)

for adm9240:

in5 is -12V, in3 is 5V

-12V indicated = 
current through R1		(in - 5V) / R1
multiplied by R2		(in - 5V) * R2 / R1
offset by voltage at top of R2	((in - 5V) * R2 / R1) + in

compute in5 ((@ - in3) * 82 / 15) + @, ??

A similar formula is required for winbond, except they provide 
a 3600mV reference to drive top of voltage divider.

Winbond -12V with datasheet resistors:

compute in5 ((@ - 3600) * 232 / 56) + @, ??

I never did get around to working out the reciprocal for those :)

But you can clearly see that the winbond negative voltage example 
in sensors.conf is wrong because it doesn't offset the reading? 
Instead, it fudges the multiplier, not correct at all.

These are straight line transforms: y = mx + c, c is zero for positive 
voltages, but not for negative voltages.

>> Sensors needs a cleanup, and it seems right at the core parser, that's
>> not a nice one to take on, but from end-user point of view it needs
>> doing.  One day :)  The lex/yacc parser in sensors is not terribly
>> bright, I've forgotten if there is more modern way to build a parser,
>> but the core parser doesn't look right, although its been a few years
>> since I did one ('97 or '98), I'd have to dig it up and look.
>
>Totally agree with you here, the parser is very hard to maintain, lex and
>yacc aren't my friends. And it leaks memory...

Doesn't surprise me :)  Peculiar way of thinking required for 
defining a formal grammar.  
>
>But rather than trying to fix that broken libsensors, writing a new one
>would be more useful IMHO (but this requires finishing the sysfs
>interface as I said before).

For a while there I wasn't sure if Yani's work was going to change 
sysfs names, I didn't get a reply on 'faking' fan_div for fscher, 
perhaps it is better to do fanX_ppr and reflect chip function?

I don't want to rewrite libsensors, I'd like to sidestep it though :o)

Banging against the boundaries again...

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Mon, 9 May 2005 15:35:36 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

Okay, its up, some notes, the script, the runtime output
at http://scatter.mine.nu/hwmon/voltage/

If you could confirm sensors compute can do the transforms in one 
of my earlier answers this morning (before coffee) then we can 
leave it for now.  

I'm thinking an array of u16 'fake' nominal scale readings for internal 
scaling is easiest to do for winbond, that way all drivers have similar 
looking scaling transform, it works, I had it in at some stage.

Probably less confusing than having R1/R2 scaling perhaps just in
winbond chips, a comment would advise derivation of values.  Yes?

Problem now is the backwards compatability issue, or simply document 
what has been done and move on.  I'd prefer to see correct mV from 
sysfs.  Same as fan rpm, temperature -- other oddball is pwm presented 
as 0..255 rather than percentage?

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Khali,
On Tue, 10 May 2005 14:35:31 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:

Sorry for mixing the thread up.  Just got a working set of computes 
for w83697hf chip using sensors.conf.

Its the comments up the top of file wrong, down further they mention 
the 3.6 volt offset but unfortunately comment:
"
# The math is convoluted, so we hope that your motherboard
# uses the recommended resistor values.
"
I'd have to agree with convoluted math :)

>and motherboards have a long history of not following the
>recommendations anyway.

This is the issue what I'm trying to redress by exposing resistor 
values in the computes, and providing (planning?) a user-space 
program for those with non-standard values on their mobo's.

I've changed Winbond datasheet values to E24 values as I suspect 
that is what's on my mobo.  These work for me, CVS lm_sensors 
(so I did compile that other patch, later :)

ignore in1
compute in3 @ * (50 + 34) / 50,         @ * 50 / (50 + 34)
compute in4 @ * (56 + 20) / 20,         @ * 20 / (56 + 20)
compute in5 ((@ - 3.6) * 100 / 24) + @, 3.6 - ((3.6 - @) * 24 / (100 + 24))
compute in6 ((@ - 3.6) * 120 / 56) + @, 3.6 - ((3.6 - @) * 56 / (120 + 56))
compute in7 @ * (33 + 17) / 33,         @ * 33 / (33 + 17)

These can be simplified back, but then we lose traceability?  

From a documentation point of view the verbose example may be 
better?

At least I've learned a bit more about libsensors + sensors.conf 
today, not quite as bad as first look :o)

This is using 2.6.12-rc3-mm3 standard driver (lsmod):

w83627hf               29480  0
i2c_sensor              2944  1 w83627hf
i2c_isa                 1856  0

--Grant.

RFC parameter based voltage scaling

[Mark Studebaker]

Grant Coady wrote:
> Hi Khali,
> On Tue, 10 May 2005 14:35:31 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:
> 
> 
>>Hi Grant,
>>

> 
> Future resistor values come in E96 series which is a noisy calculation, 
> the other option is resnet's where you might get 10/20 ratio or 10/30 
> ratio which is also covered in E24 series.  
> 
> I've already demonstrated that E24 resistor ratios are below the basic 
> error of the sensor chip.  E24 series over two decades gives ratios to 
> much better than 1/2%, point 2: is that mobo makers are likely to use 
> cheap 5% resistors, 
> 

Maybe, maybe not... IIRC 1% 0603 resistors are about $20.00 for a reel
of 5000, where I used to work we used only 1% to minimize inventory,
of course we weren't in Taiwan. But using 5% resistors in front of
a sensor is just bad design. The Winbond datasheets  I've looked at
have 1% resistors in the schematics. What's the basis for
your 5% assumption?


> Sort of, datasheets can be poorly expressed, poorly understood when 
> one doesn't have the hardware, sure.  The errors I'm finding are way 
> beyond that.  You're trying to tell a former electronics design 
> engineer who was working with 50000 count A/D converters 20 years 
> ago how to read datasheets and where error terms come from?  
> 

You aren't the only EE around here, please don't give us a bad name by being
snippy.

mds

RFC parameter based voltage scaling

[Mark Studebaker]

Grant Coady wrote:
> Hi Khali,
> On Tue, 10 May 2005 14:35:31 +0200 (CEST), "Jean Delvare" <khali@linux-fr.org> wrote:
> 
> Sorry for mixing the thread up.  Just got a working set of computes 
> for w83697hf chip using sensors.conf.
> 
> Its the comments up the top of file wrong, down further they mention 
> the 3.6 volt offset but unfortunately comment:
> "
> # The math is convoluted, so we hope that your motherboard
> # uses the recommended resistor values.
> "
> I'd have to agree with convoluted math :)
> 

IIRC the comment, and these original formulas, are mine.
    compute in5 (5.14 * @) - 14.91  ,  (@ + 14.91) / 5.14
    compute in6 (3.14 * @) -  7.71  ,  (@ +  7.71) / 3.14

If I made a mistake doing the formulas on the back of a napkin,
or they aren't correct for newer
Winbond chips (is the 697f the chip you've been referring to when you say
"Winbond"? - there are lots of separate sections for Winbond chips in
sensors.conf.eg), then let's fix them in sensors.conf.eg.
Or you suggested rewriting the formulas to be more transparent -
that's a good idea.

But just because the formula's wrong doesn't mean we should shove
the calculations into the driver. Let's fix the formulas and be done.

I think that's where you are now anyway? not sure...
Do you now think the formula  is wrong or just hard to understand?

mds


> 
>>and motherboards have a long history of not following the
>>recommendations anyway.
> 
> 
> This is the issue what I'm trying to redress by exposing resistor 
> values in the computes, and providing (planning?) a user-space 
> program for those with non-standard values on their mobo's.
> 
> I've changed Winbond datasheet values to E24 values as I suspect 
> that is what's on my mobo.  These work for me, CVS lm_sensors 
> (so I did compile that other patch, later :)
> 
> ignore in1
> compute in3 @ * (50 + 34) / 50,         @ * 50 / (50 + 34)
> compute in4 @ * (56 + 20) / 20,         @ * 20 / (56 + 20)
> compute in5 ((@ - 3.6) * 100 / 24) + @, 3.6 - ((3.6 - @) * 24 / (100 + 24))
> compute in6 ((@ - 3.6) * 120 / 56) + @, 3.6 - ((3.6 - @) * 56 / (120 + 56))
> compute in7 @ * (33 + 17) / 33,         @ * 33 / (33 + 17)
> 
> These can be simplified back, but then we lose traceability?  
> 
>>From a documentation point of view the verbose example may be 
> better?

RFC parameter based voltage scaling

[Grant Coady]

Hi Mark,
On Wed, 11 May 2005 10:23:50 -0400, Mark Studebaker <mds@mds.gotdns.com> wrote:

>                                But using 5% resistors in front of
>a sensor is just bad design. The Winbond datasheets  I've looked at
>have 1% resistors in the schematics. What's the basis for
>your 5% assumption?

1. Inventory = 24 values per decade rather than 96 on stock?  I 
think my local electronics shop only sells 1% now, but in E24 
series, so I framed a bad argument for the 5% E24 series.  My bad.

2. Empirical, I asked for and got no answer for a particular issue, 
coded up a test using E12 series and got a very unambiguous answer, 
I was quite surprised how 'accurate' this method is.  I try for 
different issue and go to E24 series, I did have to look up the 
E96 series :)

The method fails for E96 series as calculation resolution is below 
measurement resolution =>> no repeatability.  

Look at Winbond recommended 56/232 = .241, replace with 24/100 = .240
only ~1 bit error.  Seems to match my mobo BIOS vs sensors.  the 10/28 
translates to 20/56 E24 series -- so that 232k is only E96 value on 
winbond datasheet in functional terms.  The internal resistor values 
can be anything they want: 34/50, 34/51, 17/33 for various chips, 
and whether 5V or 5VSB

>You aren't the only EE around here, please don't give us a bad name by being
>snippy.

Mark, my apologies, I retired 12 years ago, burned out, completed 
a computing degree part time after a motorcycle accident and for 
the last several months been battling medication issues that have 
been very difficult for me, and have spilled over as bad attitude, 
particularly at times in last two months, including last week.

Sometimes I don't hit the delete button as often as I should when 
writing :)

This is what convinces me:
grant@sempro:~$ wq_discover_R1_R2-w83697hf

  Grant's voltage divider value finder, version 2005-05-11
  R1 is from E24 (5%) series, R2 from two decades E24 series

Sync measurement cycle... ... Done.

Working on:    12V
~~~~~~~~~~~~~~~~~~
    R1    R2    Error   100R2/R1
   ----  ----   ------     ---
    20    56    -0.03%     280
    43   120     0.29%     279

Working on:   -12V
~~~~~~~~~~~~~~~~~~
    R1    R2    Error   100R2/R1
   ----  ----   ------     ---
    18    75     0.06%     416
    24   100     0.06%     416
    36   150     0.06%     416

Working on:    -5V
~~~~~~~~~~~~~~~~~~
    R1    R2    Error   100R2/R1
   ----  ----   ------     ---
    56   120    -0.07%     214
    22    47     0.21%     213


   x     raw    BIOS   final   label   R1   R2  100R2/R1
   0    1552    1555    1552   Vcore    0    0
   2    3296    3295    3296     3.3    0    0
   3    3040    5135    5107   *   5   50   34     68
   4    3152   11975   11977      12   20   56     280
   5     624  -11785  -11776     -12   24  100     416
   6     848   -5045   -5049      -5   56  120     214
   7    3280    5075    4969   *5VSB   33   17     51
   8    3376    3375    3376   Vbatt    0    0

                               * internally scaled

Have I cheated?  I appended 5 instead of 0 to each BIOS voltage 
to get extra digit for whole mV value.  I think one could argue 
using 1/2 a digit is okay?

shell script at http://scatter.mine.nu/hwmon/voltage/

Using 100 * R2 / R1 for comparison ratio seems best for fixed 
point math, as R2 > R1.

I've set bailout on absolute error at 0.33%, I'm surprised, 
impressed by how well this method can pick values.  If I change 
the 24/100 for -12V to winbond 56/232:

    5     624  -11785  -11705     -12   56  232     414

That convinces me that my mobo uses 24/100 instead of 56/232.
We're looking at ~65mV resolution here.  Supporting your argument 
that mobo makers use 1% is the fact that this method works at 
as it uses current chip measurement to reconcile BIOS reading :)

I'm trying to make sense of a system that contradicts itself in 
intent and implementation.  The usual patchy documentation that 
GNU/Linux is famous for.  Well, we all plan to do documentation.

I see strangely implemented transforms and thus have a desire for 
audit trail back to datasheet values.  Particularly as I was firmly 
told all chips with internal scaling report pin voltage, and I 
find many do not, then I see quite weird transforms in drivers or 
sensors -- this needs fixing.

When I started this exercise it was not clear that sensors could 
use other inputs in a compute, required for adm9240.  Which I'll 
work on again soon to verify a sensors compute line for SE440BX-2 
mobo, though I'm a few years late for that one.

Besides, nothing beats evidence (as per research data collection 
terminology) to prove a point.  Being told datasheets are in error 
doesn't cut it for me.  

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Mark,
On Wed, 11 May 2005 10:41:35 -0400, Mark Studebaker <mds@mds.gotdns.com> wrote:

>IIRC the comment, and these original formulas, are mine.
>    compute in5 (5.14 * @) - 14.91  ,  (@ + 14.91) / 5.14
>    compute in6 (3.14 * @) -  7.71  ,  (@ +  7.71) / 3.14
>
>If I made a mistake doing the formulas on the back of a napkin,
>or they aren't correct for newer
>Winbond chips (is the 697f the chip you've been referring to when you say
>"Winbond"? - there are lots of separate sections for Winbond chips in
>sensors.conf.eg), then let's fix them in sensors.conf.eg.

I can not tell by inspection whether those computes are correct 
or not, but taking my mobo 624mV through the in5 produces -11.7V
which corresponds to Winbond 56/232 datasheet values.  What had 
me upset was a reference up near top of file saying Winbond values 
better, and was totally bogus formulas as no offset present.

That's what got me 'snippy', not see your formula further down 
until yesterday, I didn't get past the top bit :)  

Again, if I had more patience... but a friend of mine been using 
sensors for years and he had problems always with sensors.conf 
so I started with a negative attitude.

>Or you suggested rewriting the formulas to be more transparent -
>that's a good idea.

That is now what I'm aiming for, transparency in the computes, 
relating back to datasheet where appropriate.

>But just because the formula's wrong doesn't mean we should shove
>the calculations into the driver.

What set me off in that direction was seeing lm87 has inX_scale 
in private memory but without accessors, so close?  So yes, why 
not put entire transform into driver?  I know, wont happen :)

>Let's fix the formulas and be done.

Then we come to practical reality, this is where they'll go, now 
that I can describe traceable computes that _work_ into sensors.conf 
I am much happier with it.

If you had an 'include' command in sensors so that various 
chips can be documented in a modular fashion.  Much less 
intimidating to this new user than one enormous file that 
grew some, over the years.

Couple months ago I'd dismissed sensors.conf as totally stupid, 
like spaghetti code, just too much in one file.

Was only yesterday I find it can work with more transparent 
computes and Jean Delvare told me it can use other input values, 
which is needed for adm9240 as it doesn't have reference to drive 
top of divider for minus voltages, so one uses measured 5V, my 
mobo was 5.14V and nothing worked out until I took that 5V 
variation into account.

My work on fixed point math was in solving a particular problem, 
discovery of mobo resistor ratios, and can be applied to the 
driver or sensors.  
>
>I think that's where you are now anyway? not sure...

That is where I am now, reconciling my experience with yours and 
lmsensors team.  Because I lost trust in sensors early, I've come 
in now with fresh review from datasheets right through system. 
But still a sample, not all the drivers yet.

And now I integrate this review back to lmsensors, as it makes 
sense to me now.

>Do you now think the formula  is wrong or just hard to understand?

Hard to understand.  When I first looked, I couldn't see what '@' 
was, and then the duplication of each formula to get the reciprocal?
Computers can do that.  The response to my query about the unnecessary 
duplication was: 'how else would you do it?'  And, at one point the 
whole shebang looked hopeless to me, yes, very difficult to understand.

So I have provided the 'how else' alternative by going back to the 
parameters.  The dual formula entry is silly as it describes get/set 
via the same transform in two ways, the machine can perform the 
reverse transform all by itself.

This is wrong[1], sensors.conf line 144:
# On almost any mainboard we have seen, the Winbond compute values lead to
# much better results, though.
#
#             Vs     R1,Rin   R2,Rf    Vin
#       in4  +12.0     28      10     +3.00
#       in5  -12.0    210      60.4   +3.00
#       in6   -5.0     90.9    60.4   +3.00
#
# These leads to these declarations:
#       compute in3 ((6.8/10)+1)*@ ,  @/((6.8/10)+1)
#       compute in4 ((28/10)+1)*@  ,  @/((28/10)+1)
#       compute in5 -(210/60.4)*@  ,  -@/(210/60.4)
#       compute in6 -(90.9/60.4)*@ ,  -@/(90.9/60.4)
#

No offsets for Winbond negative values, yet the +12V uses datasheet 
10/28 -- this is what kicked me into the 'totally bogus' response.

Not until line 439 do I read about an offset:

# Same as above for w83781d except that in5 and in6 are computed differently.
# Rather than an internal inverting op amp, the 82d/83s use standard positive
# inputs and the negative voltages are level shifted by a 3.6V reference.
# The math is convoluted, so we hope that your motherboard
# uses the recommended resistor values.

And that paragraph is hopelessly user unfriendly, "so we hope that 
your motherboard...".  Because what it leads to is end-users just 
fudging their numbers to get something that looks okay.  And some 
drivers too.

[1]It is not wrong, in context that Winbond put inverters in some 
chips, it is wrong, when I'm looking for the offset positive 
measurement :)

When I reviewed winbond, I was checking for variations in 5V 
measurement because drivers not scaling it as per guidelines 
of presenting internally scaled pin voltage to sysfs, not looking 
at negative voltage handling as that was outside driver space, 
done in user space, so I missed the inverters in some winbond 
chips.

For that misunderstanding, my apologies.

I take an instant dislike to R1, R2 formulas with a +1 in them.  
There is no reason to 'simplify' formulas when writing software, 
that's the computer's job.  

The compute lines should be traceable to datasheet and/or real world 
values, computers don't mind computing :)

--Grant.

RFC parameter based voltage scaling

[Grant Coady]

Hi Mark,
On Wed, 11 May 2005 10:41:35 -0400, Mark Studebaker <mds@mds.gotdns.com> wrote:

>Do you now think the formula  is wrong or just hard to understand?

Not wrong, hard to understand :)

What do you think of this approach to calibration?

set sensors to 1:1 for unknowns so we read sensor chip's values

ask user for +12V, -5V, -12V BIOS or meter readings

calculate 'y = mx + c' transforms for sensors.conf, based on 
discrete E24 resistor series: one decade for R1, two decades 
for R2:

#    ---o--> +12V
#       |
#       -
#      | | R2        ----------------------              -5V, -12V
#      | |          |                      |   ____       ____
#       -           |          3600mV Vref |--|____|--o--|____|-->
#       |      Vin  |                      |    R1    |    R2
#       o-----------| 0..4096mV            |          |
#       |           |            0..4096mV |----------
#       -           | W83697HF             | Vin
#      | | R1       |                      |
#      | |           ----------------------
#       -                      |
#       |      0V              |                               0V
#    ---o----------------------o--------------------------------->

The technique seems viable, and has accuracy better than chip 
A/D resolution.  For those cases where mobo uses datasheet values 
this technique has no use for end user, but when their voltages 
are messed up, this technique will give a better answer being 
based on a discrete set of viable transform 'x' ratios.

On reflection, end user doesn't want traceable transforms, that's 
for driver writers -- and since we scaling lower sensor voltages in 
user-space now, I doubt it worth changing unless I find errors in 
transforms.  And it is difficult to goof up on 16mV / bit :)

I think I now understand the 'datasheets not be trusted' related 
to their strange formulas, only one datasheet (lm81) had a decent 
transform, I've had to go back to basics to retrace path you guys 
already done. 

Is there a reason why sensors doesn't do the reverse transform for 
voltage set functions?  (rather than the explicit dual compute)

Thanks,
--Grant.