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 _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
