[lm-sensors] RE: vt8231.c and VRM-VID

Roger Lucas roger at planbit.co.uk
Tue Nov 8 16:55:18 CET 2005

Hi Jean,

Sorry to keep sending more patches...  When I tried Rudolf's patch for the
VRM, I couldn't get the VID to work properly.  On investigation, it turned
out that this register ALSO does not exist on the VT8231.  Whoever ported
the original code to the VT8231 didn't check that all the registers ACTUALLY
EXISTED on the VT8231 device!!!  No comment.

Anyhow, I have now checked that all the registers left do actually exist and
that the driver isn't reading garbage from the device.  This has resulted in
the removal of the PWM controls (as in my mail below) and now also the VID
detection as this isn't supported in the chip either.

I also tidied up my code changes for creating the temp/voltage files.  Don't
know what planet I was on with the original code - it was horrible.

Anyhow, revision 4 is attached.  Hopefully this is the last one.

Rudolf's VRM patch works perfectly BTW, and has ended up in this revision 4
code release as it is part of the updated kernel HWMON source I am now
working from.  I hope that this isn't a problem - I can always remove that
section of the patch and send a revised version if it is.

Thanks for all your work in reviewing my code.

- Roger

-----Original Message-----
From: lm-sensors-bounces at lm-sensors.org
[mailto:lm-sensors-bounces at lm-sensors.org] On Behalf Of Roger Lucas
Sent: 07 November 2005 19:57
To: 'Jean Delvare'
Cc: 'LM Sensors'
Subject: RE: [lm-sensors] RE: vt8231.c

Hi Jean,

Attached is revision 3 of the VT8231 driver.  There are a LOT of changes to
implement your suggestions.  Some of these break compatibility with older
vt8231 driver releases as follows:

tempX sequence
Temperatures are now measured temp0,temp1,temp2,etc.  This causes the
"sensors" user-space program to fail with errors as it expects the older
temperature numbering sequence.

tempX scaling 
Given that we have no idea what the temperature curves for a device are, the
driver now returns the 10-bit value directly from the register.  Older
versions of the driver multiplied the register value by 2.5 (reason unknown
as it DEFINITELY didn't scale it to degrees Centigrade, Fahrenheit or
Kelvin).  Older temperature scaling calculations are now completely wrong.

inX scaling
The driver now scales the measurement to mV.  Inputs such as the 3.3v
internal reference are now completely correct.  Inputs such as IN0-IN5 which
report an external pin now return the value at the pin.  SENSORS.CONF still
has to scale these to compensate for external divider chains (if, for
example, the 12v rail is being measured).

tempX/inX presence
The driver only generates measurements for inputs that are genuinely
measured (according to the CONFIG register).  This causes the "sensors"
program to fail as it expects to see all the tempX and inX sources
available, even if you add "ignore xxx" to the sensors.conf file.  IMHO this
is a bug in the "sensors" program, as "ignore xxx" should cause it to fully
ignore that parameter, not still generate warnings if the parameter doesn't

PWM controls
The VT8231 doesn't have any PWM controls.  All the code that was in the
driver was erroneous and has been removed (I suspect it was legacy from some
other driver used as the base for an earlier port).

If the newer vt8231 driver is accepted into the kernel tree, would you like
me to go through v2.9.2 of lm_sensors and try to see what can be done to
resolve the compatibilities issues with this newer vt8231 driver?

As far as the web site for the sensors.conf file is concerned, I have no
time to do this in the near-term.  If I get some spare time in the future,
and no-one has done it by then, I will look into it further.

Best regards,


-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: 07 November 2005 09:24
To: roger at planbit.co.uk
Cc: Knut Petersen; LM Sensors
Subject: RE: [lm-sensors] RE: vt8231.c

Hi Roger,

On 2005-11-06, Roger Lucas wrote:
> One question I have is regarding the "1 mV" calibration, and this returns
> me to a general comment/question with the LM-Sensors system:
> The LM-Sensors system appears to be based on what the sensors chips are
> on the motherboard, rather than what the motherboard is.  From the "probe
> and find out what I have" concept, this is reasonable, but it does cause
> a LOT of problems for users who are less educated.  Many of the sensors
> devices are wired up in different ways on different motherboards, with
> (for example) a voltage input being used for a 12v rail monitor on one
> motherboard and a 5v rail monitor on another. The motherboard
> manufacturer is completely at liberty to wire a device in any way
> they choose.

Completely true.

> This therefore makes a sensors.conf file really a motherboard-specific
> rather than a device specific file.  If you use the configuration file
> according to the device that you have, rather than the motherboard that
> you have, then you run a very high risk of reporting nonsense to a user,
> or (arguably worse) reporting information that looks correct but is
> actually wrong.

True again.

Keep in mind that the folks originally running the project were
passionates with good electronics knowledge. Back then, most users also
had the same profile. This explains a number of technical choices which
turned out not to be suitable for average users. In a way, the project
is the victim of its own success. It is also victim of the increase of
the number of hardware monitoring chips and the exponential growth of
the number of motherboard, each with its own specifics.

We're trying to fix these issues as time permits (e.g. the drivers do no
more set arbitrary limits, and they tend not to reset chips anymore) but
there's still a lot left to do.

> Following this through, when you request that the driver report the
> voltage detected in mV, I am _hoping_ that you are asking for the
> voltage at the pin of the device, rather than the voltage that the
> device happens to be ultimately connected to on this particular
> motherboard?  Reporting the voltage at the device pin is the only
> consistent behaviour that I can see for a motherboard-independent device
> driver.

Yes, of course. Drivers are written for chips. All the rest belongs to
userspace (libsensors or whatever).

> If the above makes sense, then would there be any interest in building
> some kind of database of known good sensors.conf files for specific
> motherboards?

There have been 472 people complaining of the lack of such a database
already. A dozen of these said they would build one. Two of these
actually did. One is already dead, one is available at
http://lm-sensors-db.berlios.de/ but doesn't actually work.

We rejected the idea that we would include the configuration files one by
one in the lm_sensors project as people send them, because it would be
too much work. An external, web-based system where people could post and
retrieve their configuration files would be prefered. But we are still
in need of one which would work.

It might be discussed what to do with the sensors.conf.eg file. It
started as a small file when there were only a couple supported chips,
and motherboard manufacturers were following the chip maker's
recommendations on wiring. Now the file is quite large, and has lots of
conditionals (expressed as comments) to try and help users to get a
working configuration file. according to their hardware. I agree that it
isn't suitable for the average user.

Maybe we should stop installing this file to /etc/sensors.conf
automatically. As you say, It's probably better not to have a
configuration file than to have a bad one. However, this still a good
base for people to start tinkering, so we probably can't get rid of it
unless we actually have a database with configuration files for the most
popular boards.

> I would suggest that the output of "LSHW" or a similar utility is used
> to obtain unique identifying details for the motherboard, and then this
> used to determine the appropriate motherboard conf file.  A simple web
> page with known motherboards on it and their associated .conf would be a
> very good start.  New motherboards could then be added by people with
> their matching .conf file.

We would probably use the DMI fields for board identification (using
dmidecode, which is more standard than lshw I think). However, the
difficult part is to gather the data. What you call "a simple web
page" won't work. We want something the average user can freely
contribute to, with a minimum maintenance workload from us. Briefly:

* Any user can add a configuration file. He/she must pick from a list of
motherboard makers, or add one if his/her aint in the list. Then he/she
types the name of his/her motherboard and uploads his file. Ideally we
would do a brief content check to make sure nobody uploads crap.

* Any user can update (overwrite) a configuration file. We probably need
to backup older files just in case though.

* We need an administration interface to fix about anything (manufacturer
or board name, broken configuration statements) and even delete files if

* Users should have the possibility to alert us if they think something
is wrong.

* Not sure how to deal with duplicates. We probably want one single
configuration file per board, but it might be hard to enforce.

Note that there still is a problem with the fact that not all users of
the same board will use the same fans, so fan limits (and, to some
extent, temperature limits) depend on the user. The configuration files
are still templates. If we want to ultimately install them
automatically, we will probably need to enforce the fact that
configuration files should not set limits for fans and temperatures, nor
ignore statements for fans. These configuration files should essentially
contain label and compute statements.

This ain't simple, else this would have been done already. But if you
want to work on this (preferably *after* we are done with the vt8231
port ;)) you're very welcome.

Jean Delvare
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: kernel-2.6.14_vt8231_r4.patch.txt
URL: <http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20051108/ea17b704/attachment.txt>

More information about the lm-sensors mailing list