Message-ID: <20091124211134.12971937@hyperion.delvare>
Date:	Tue, 24 Nov 2009 21:11:34 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
	linux-kernel@...r.kernel.org, lm-sensors@...sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h 
 CPUs

On Tue, 24 Nov 2009 15:09:57 +0100, Clemens Ladisch wrote:
> Jean Delvare wrote:
> > On Tue, 24 Nov 2009 09:43:29 +0100, Clemens Ladisch wrote:
> > > In any case, it might make more sense to show such values as something
> > > like "20 °C below maximum".
> > 
> > I think so, yes. Now the difficulty is to come up with a suitable sysfs
> > interface. Dropping the current interface altogether doesn't sound
> > right as it will take time before a new version of libsensors is
> > written and spread out and all applications add support for the new
> > interface. In the meantime, I guess we want users to still see the
> > approximate value.
> 
> k10temp is a new driver, so no old systems would break if it introduced
> a new class of measurements with names like, e.g., reltemp#_*.

I wasn't necessarily thinking of k10temp breaking a working system,
more of k10temp just not working on current systems (if we don't opt
for parallel implementations.) And there's also the coretemp case,
where we report relative values in some cases; that case would fit in
what we're discussing now, so we would modify an already existing
driver.

> We could add this in parallel with the old interface.  If we wanted to.

I think we want to, yes. I just don't know for how long.

> > So ideally we would come up with an interface that adds up to the one
> > we have currently. Future libsensors/applications could read the extra
> > information to display the value in a different format so that the
> > users see the difference.
> > 
> > An idea I have about this is adding a sysfs file temp#_relative, which
> > would contain the fake temperature value that is used as a reference
> > for the thermal sensor in question. In the case of k10temp, the value
> > would be 70000. So for example we would have:
> > 
> > temp1_input: 46000
> > temp1_relative: 70000
> > 
> > Old applications would display this as 46°C while new ones would
> > display "24°C below the limit".
> 
> In this case, temp1_relative is identical with temp1_max.  In the
> general case, there always must be some kind of limit (whether "max" or
> "crit" or something else) against which the values are measured,
> otherwise a relative value would not make sense.

I would love this to be true, but I can't see any reason why it would
have to be. I can easily imagine a CPU specification reading: "This
register contains a temperature value on an arbitrary scale; higher
values mean higher temperatures." I'm not claiming it would be
particularly useful... but if a CPU maker ever does this, don't we want
to support that? (This is a real question, maybe we don't.)

I really didn't expect the implementations we've seen in Intel Core or
AMD family 10h processors. So I wouldn't be surprised if future
implementations are different again.

> This means that one of the already existing limit values must be the
> reference base, so we'd need just a mechanism to specify which of them
> is it, i.e., "temp1_relative_base: max".  If we'd have
> "temp1_relative: 70000", the application would have to search among the
> limit values for one with the same value.

I fail to see why the application would care about this at all. When in
relative mode, all other values would be offset by the temp#_relative
value. But that value itself would not be displayed (it has no physical
value, otherwise we wouldn't be in absolute mode, would we?)

> (It doesn't really matter which one is the base, as all values are
> relative anyway, so we could just define that temp#_max is the base;
> so we'd have "temp1_relative: true").

This is taking flexibility away from us, for no benefit that I can see.
Am I missing something?

(Additionally it wouldn't fit in libsensors as it exists today. This
doesn't mean it can't be done, but the cost is higher, so it needs to
bring an significant improvement.)

> > It may not be considered flexible enough though... For example it does
> > not support sensors with totally arbitrary scales (where 1000 != 1°C.)
> 
> When the scale differs but is _known_, the driver can just rescale its
> internal register values to millidegrees.

Correct, and actually many drivers do that already. But the scale could
also be totally unknown (as in my theoretical example above), only
bounded by the register size (which would lead to pretty bad temp#_min
and _max IMHO.)

> When we have some scale like "0%...100%", that should probably be
> exported as "pwm#_target" or something like that.

That would be difficult, as we generally don't know which pwm output,
if any, is related to a given CPU. ACPI may know more, but the ACPI
interface to cooling zones and temperatures is very limited IMHO, and
hard to connect to physical devices, I doubt we can get anything usable
out of it. And anyway, deciding that cooling must be somehow
proportional to temperature is pretty arbitrary and doesn't match what
I've seen people do so far.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists