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: 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 exist. 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, Roger -----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: 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 needed. * 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
