Re: [PATCH v3] k10temp: temperature sensor for AMD Family 10h/11h CPUs

Jean Delvare
2009-11-23T19:05:25Z

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