* Jean Delvare <khali at linux-fr.org> [2003-03-27 14:31:40 +0100]: > > Ah, and I don't want to do small corrections like 1 or 2 percent up or > > or down, but things like this for lm80: > > compute in0 (24/14.7 + 1) * @ , @ / (24/14.7 + 1) > > compute in2 (22.1/30 + 1) * @ , @ / (22.1/30 + 1) > > compute in3 (2.8/1.9) * @, @ * 1.9/2.8 > > compute in4 (160/30.1 + 1) * @, @ / (160/30.1 + 1) > > > > These differ a lot. And as stated in the sensors.conf seem to be from > > the datasheet of the lm80 and not mainboard specific. > > They may be mainboard specific. The formulae rely on *suggested* > resistor values, which the integrators may or may not follow. There > definitely is a need for userspace conversion. Libsensors needs to be > tunable by the user. > > I don't know about the kernel conversion Jan is talking about (never > coded a sensor driver myself), so I can't talk about this half, but I'm > pretty sure you shouldn't even think of moving all conversions into > kernel space. > > Mark, Phil, maybe you could explain the reasons better than I would? I'm not the Mark to which Jean refers, but anyway... he is correct. The sensor chip cannot read temperatures directly, only voltage. The conversion from degress C to V is dependent on the mainboard for the reasons Jean mentions. But also, the chip driver cannot read voltage directly, only bits in a register. *That* conversion is *not* mainboard dependent; it is sensor chip specific. Even when the subject in question is voltage (e.g. power supply +12V), there is mainboard dependent nonsense between the "real value" and what is presented at the pin of the sensor chip. So there is a legitimate need for two conversions. IMHO, the mainboard dependent one *must* be done in userspace (as Jean says). But the conversion of raw register values to volts should happen in the kernel; fixed point maths are sufficient for that. (Yes I'm simplifying; external sensors can present data to sensors chips in other electrical formats, e.g. PWM. Same argument applies.) Regards, -- Mark M. Hoffman mhoffman at lightlink.com
