RFC parameter based voltage scaling

Grant Coady grant_lkml at dodo.com.au
Wed May 11 00:59:25 CEST 2005

Hi Khali,
On Tue, 10 May 2005 14:28:54 +0200 (CEST), "Jean Delvare" <khali at 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...


More information about the lm-sensors mailing list