[lm-sensors] [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs
clemens at ladisch.de
Fri Nov 27 14:03:29 CET 2009
Jean Delvare wrote:
> On Wed, 25 Nov 2009 10:51:38 +0100, Clemens Ladisch wrote:
> > temp1_input: -1000
> > temp1_max: 40000
> > temp1_relative: 0
> > Should the values be labeled as "1 °C below normal" and "40 °C above
> > normal", and how should the application know that 0 is to be labeled
> > "normal"? It might make more sense to display the temperature just as
> > "41 °C below max", in which case the actual value of temp1_relative is
> > not used at all.
> Except that there may be no temp1_max, just a temperature value
> relative to the "normal" operating point of the CPU. In that case we
> can't fallback to the max limit.
> Even your initial proposal doesn't work there yet: the hwmon interface
> has no standard name for "normal operating temperature", so we can't put
> that name in temp#_relative. [...]
> If the base has a meaning (normal operating temperature, or critical
> temperature, etc.) we have to let the user know somehow.
I chose that example because "normal" does not exist; and it's a bad
example because "normal" actually has a meaning.
Better take the AMD CPUs: The base of all relative values is zero (by
definition), _not_ 70000, and the meaning of that base is just "70 °C
below the temperature at which the processor wants 100% cooling". This
base value is meaningless for any monitoring purposes.
If any point on the scale has a meaning, it should be reported with some
temp#_whatever file. However, the base itself does not necessarily have
As long as we have some corresponding _max or _crit limit that can be
used for comparisons, we do not need a base value. Only if there is
no known predefined limit do we need a temp#_relative value.
> Or maybe create a new label (temp#_relative_label or similar) but I'm
> not sure how we would integrate this into libsensors and applications.
> In particular I am worried about translation issues if we make the
> drivers too verbose.
All known CPUs with relative temperature scale also have known _max
limits, and I don't think that a CPU with relative scale and both
unknown _max and _crit will ever be designed. In other words,
temp#_relative* is not needed at the moment. I think we should not
try to define how the semantics of such an unknown scale can be
> > > Additionally it wouldn't fit in libsensors as it exists today.
> > Then the best bet would probably be an entry like temp#_unit, with
> > 0 = absolute °C (default); 1 = relative °C or °K; other values
> > "unknown". Even if some silly scale is introduced later, applications
> > that read this entry then know that they must not display a unit like °C
> > for unknown unit specifications.
> This could work, yes. Note that current drivers and libsensors don't
> have/know about this file yet, and they generally use an absolute °C
> scale. So the absence of temp#_unit file would be interpreted exactly
> as if the file was there and contained value 0.
> (I'd rather name that file temp#_scale - but that's an implementation
@@ -314,6 +314,19 @@ temp_reset_history
Reset temp_lowest and temp_highest for all sensors
+temp[1-*]_scale Temperature scale type.
+ 0: millidegrees Celsius (default if no _scale entry)
+ 1: relative millidegrees Celsius; see below
+ 2: millivolts; see below
+ other values: unknown
+ When scale=1 (relative), the temperature value 0 does not
+ correspond to zero degrees Celsius but to some unknown
+ temperature. In this case, temperate values should not be
+ interpreted or displayed as absolute values and make sense
+ only when compared to other values of the same channel.
Some chips measure temperature using external thermistors and an ADC, and
report the temperature measurement as a voltage. Converting this voltage
back to a temperature (or the other way around for limits) requires
Hmm, which drivers use millivolt temperatures?
More information about the lm-sensors