From: Jean Delvare <khali@linux-fr.org>
To: Clemens Ladisch <clemens@ladisch.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Serge Belyshev <belyshev@depni.sinp.msu.ru>,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs
Date: Mon, 23 Nov 2009 20:05:27 +0100 [thread overview]
Message-ID: <20091123200527.1114cbc2@hyperion.delvare> (raw)
In-Reply-To: <4B0AAA55.3040702@ladisch.de>
On Mon, 23 Nov 2009 16:29:25 +0100, Clemens Ladisch wrote:
> Jean Delvare wrote:
> > On Mon, 23 Nov 2009 08:45:58 +0100, Clemens Ladisch wrote:
> >> Documentation/hwmon/k10temp | 57 ++++++++++++
> >> drivers/hwmon/k10temp.c | 142 ++++++++++++++++++++++++++++++++
> >
> > The name k10temp is a problem, as AMD insists that there is no such
> > things as K10 and K11, but instead "family 10h" and "family 11h"
> > processors.
>
> K10 was AMD's internal code name, and is widely used in practice.
> I'd like to keep this name since it is consistent with the older
> k8temp driver.
>
> What name would you propose instead? "amdfam10temp"?
Not very readable, I admit. "amd10temp" would do, I guess. But I agree
it doesn't matter that much, it's only a driver name after all.
> >> + control cooling systems. Tctl is a non-physical temperature on an
> >> + arbitrary scale measured in degrees. It does _not_ represent an actual
> >> + physical temperature like die or case temperature. Instead, it specifies
> >> + the processor temperature relative to the point at which the system must
> >> + supply the maximum cooling for the processor's specified maximum case
> >> + temperature and maximum thermal power dissipation.
> >> +
> >> +The maximum value for Tctl is defined as 70 degrees, so, as a rule of thumb,
> >> +this value should not exceed 60 degrees.
> >
> > Now I am puzzled. If the temperature value is on an arbitrary scale,
> > then the value returned by the driver is essentially fake?
>
> Yes (and it's near enough the absolute value to look plausible).
I don't know if it is a good or bad idea. Bad, I guess.
> > Don't we have additional information about the actual maximum Tcase
> > value for the different supported models, as we have in coretemp?
>
> For AMD, Tcase is the physical temperature. Did you mean Tctl?
I meant the physical temperature when Tctl = 70. In other words, the
offset between Tctl and the physical temperature.
> I'll add Tctl max (= "100% cooling, please") as temp1_max, and there's
Yes, good idea.
> a register that contains the Tctl value at which the processor starts
> throttling, which could be exported as temp1_crit(_hyst), if I
> understand the lm-sensors documentation correctly.
This is correct.
> As for your other comments, I'll integrate them in the next version of
> the patch.
>
> > If not, then it might be the right time to introduce a new interface
> > for relative temperature values. This needs some work, as we must first
> > define the interface, then implement support in libsensors and sensors,
> > and other monitoring applications, and then convert the affected
> > drivers. But apparently we will have to, as major CPU makers are not
> > able to implement something as simple as an absolute temperature
> > sensor :(
>
> There still is the built-in diode to be read by the motherboard, but the
> internal sensor was never intended to be an absolute measurement but
> just as a means for controlling the cooling.
Still we use it for that purpose at the moment. Maybe we simply should
not?
--
Jean Delvare
next prev parent reply other threads:[~2009-11-23 19:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4AF91F70.10106@ladisch.de>
2009-11-20 8:15 ` [PATCH] k10temp: temperature sensor for AMD Family 10h/11h CPUs Clemens Ladisch
2009-11-20 10:22 ` Serge Belyshev
2009-11-20 10:44 ` [lm-sensors] " Jean Delvare
2009-11-20 10:47 ` [PATCH v2] " Clemens Ladisch
2009-11-20 11:30 ` [lm-sensors] " Jean Delvare
2009-11-20 11:56 ` Clemens Ladisch
2009-11-20 12:18 ` Jean Delvare
2009-11-23 7:45 ` [PATCH v3] " Clemens Ladisch
2009-11-23 13:51 ` Jean Delvare
2009-11-23 15:29 ` Clemens Ladisch
2009-11-23 19:05 ` Jean Delvare [this message]
2009-11-24 8:43 ` Clemens Ladisch
2009-11-24 13:26 ` Jean Delvare
2009-11-24 14:09 ` Clemens Ladisch
2009-11-24 20:11 ` Jean Delvare
2009-11-25 9:51 ` Clemens Ladisch
2009-11-26 20:44 ` Jean Delvare
2009-11-27 13:03 ` Clemens Ladisch
2010-01-10 14:45 ` Jean Delvare
2010-01-15 9:57 ` Clemens Ladisch
2010-01-15 13:31 ` Jean Delvare
2009-11-24 8:43 ` [PATCH v4] " Clemens Ladisch
2009-11-25 19:45 ` Andrew Morton
2009-11-26 7:46 ` Clemens Ladisch
2009-11-27 15:43 ` Jean Delvare
2009-11-28 7:48 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091123200527.1114cbc2@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=akpm@linux-foundation.org \
--cc=belyshev@depni.sinp.msu.ru \
--cc=clemens@ladisch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lm-sensors@lm-sensors.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox