pc87360 sensor-driver results

Jean Delvare khali at linux-fr.org
Tue Apr 27 16:51:05 CEST 2004


> Awesome. Temp3 appears to be reporting accurate readings (in celcius)
> of what my bios says is the cpu temperature. The high and low
> temperatures are also stated correctly (with the default values,
> according to the pc87366 data sheet). The temperature is also slowly
> rising for temp3, so there there is definitely constant measurement
> happening.

Great :)

> However, temp1 and temp2 still display negative -128 instead of
> zero. I'll look into my board and see if this chip is trying to
> measure other temperatures, but I doubt it.

That's accordingly strange. According to the datasheet, it should
report either +127 (open diode) or 0 (unused). That said, -128 is
obviously no random value. A dump of the registers would appreciate,
see below.

> Also, I tried looking for information about what temp3 should be 
> reporting (the nat.semi. ship temp or the cpu temp) but was unable
> to locate anything. I'll have a closer look.

I have a theory about that. On the PC87366 (as opposed to the PC87365),
there are three additional channels on the VLM (voltage level monitor)
module. They are supposed to be temperature channels. This sounds
strange, and at first (admittedly quick) read I thought that it was
simply the three temperature channels of the TMS (temperature sensor)
module, replicated for convenience (I didn't see how convenient if was,
but still...). Now after reading it once again, the datasheet clearly
states that these are different temperature measurements (thermistor
based, as opposed to thermal diodes). So possibly your CPU temperature
is there, and our temp3 is the PC87366 temperature. This also complies
with the fact that an internal temperature measurement normally cannot
be disabled, to temp3 really has to be the PC87366 temperature.

I will try to implement the three additional temperature channels this
evening. Could you please provide the output for the following
commands:

isadump -f 0xecd0 16 11
isadump -f 0xecd0 16 12
isadump -f 0xecd0 16 13
isadump -f 0xecf0 16 0
isadump -f 0xecf0 16 1
isadump -f 0xecf0 16 2

This will dump the registers value for all six temperature channels,
hopefully this will bring some light ;)

> Fans are working as they have. I can set minimum values without a 
> problem. However I noticed 2 oddities:
> 1:) echoing a value that is greater than the current fan rotation
> speed will yield a different number for minimum in "sensors" or in
> the proc entry.

Nothing unusual here. Fan speed measurements have a limited (and
non-linear) resolution. Only values of the form C/(r*d) can be measured
and used as limits, where C is a clock frequency, r is a register value
and d is the divisor. For the PC87366 the clock is 480000, and d is 1,
2, 4 or 8. r is naturally between 0 and 255. See below.

Note that this is *not* related to the fact that the limit is over the
current measurement.

> 2:) the alarm flags don't wear off even if I set the minimum value
> under the current fans speed (after having a previous setting that
> was higher than the fan speed)

Nice catching, this was a bug. I was clearing the bits for temperatures
and voltages, but not fans. This is fixed, thanks.

> Pwmconfig still appears to be confused about the fans. After running
> it (and after it has shut down both my fans and restarted them), I
> get the overflow flags in "sensors" and the speeds are reported as
> -1.

OK, there must be something wrong then. I invite you to do some tests
manually, rather than using pwmconfig. Just go to the
/proc/sys/dev/sensors/pc87366-isa-ecc0 directory, and try echoing
values (between 0 and 255) to the pwm files. See what happens each
time, and report to me after you have found what is going wrong.

> For he above, even though I echoed fan2 to have a min value of 2170,
> it is reporting 2181. I had a similar problem with fan1's min, but
> echoing 2400 gave no problems.

Remember the formula above. 480000/(2170*2) = 110.59, which is stored
as
110 in the register. When applied the other way around, 480000/(110*2)
= 2181, which is what you get. The difference is because we work with
integer values.

OTOH, 480000/(2400*1) = 200, exactly. So there is no rounding done and
the value you read back is exactly the same.

>   temp1_crit: 127.00 (temp1_crit)
>   temp1_status: 127.00 (temp1_status)
> (...)
>   temp2_crit: 127.00 (temp2_crit)
>   temp2_status: 127.00 (temp2_status)
> (...)
>   temp3_crit: 127.00 (temp3_crit)
>   temp3_status: 127.00 (temp3_status)

I'm surprised by the status values, looks like a bug, most likely in
the
library. I'll take a look.

> Thanks for your continuing work on this driver!

Thanks a lot for testing :) I could hardly do anything without your
help!

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/



More information about the lm-sensors mailing list