[lm-sensors] Why internal sensor on atom cpu isn't yet supported?

[lm-sensors] Why internal sensor on atom cpu isn't yet supported?

[Maxim Levitsky]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

I use an old patch, and it works fine, was it forgotten?

Best regards,
	Maxim Levitky

I attach the patch I use for reference, I didn't wrote it
(I did slight modifications to apply it on latest kernels)

Best regards,
	Maxim Levitsky

[-- Attachment #2: 0001-Add-intel-atom-support-to-coretemp.patch --]
[-- Type: text/x-patch, Size: 3968 bytes --]

From 7415b9249a8fd03baea37f292da765aa77926208 Mon Sep 17 00:00:00 2001
From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Fri, 14 Nov 2008 22:52:42 +0200
Subject: [PATCH] Add intel atom support to coretemp

---
 Documentation/hwmon/coretemp |   14 ++++++++------
 drivers/hwmon/coretemp.c     |   18 +++++++++++++-----
 2 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp
index dbbe6c7..d85c8fa 100644
--- a/Documentation/hwmon/coretemp
+++ b/Documentation/hwmon/coretemp
@@ -4,7 +4,7 @@ Kernel driver coretemp
 Supported chips:
   * All Intel Core family
     Prefix: 'coretemp'
-    CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17
+    CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17, 0x1c
     Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
                Volume 3A: System Programming Guide
                http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
@@ -14,10 +14,11 @@ Author: Rudolf Marek
 Description
 -----------
 
-This driver permits reading temperature sensor embedded inside Intel Core CPU.
-Temperature is measured in degrees Celsius and measurement resolution is
-1 degree C. Valid temperatures are from 0 to TjMax degrees C, because
-the actual value of temperature register is in fact a delta from TjMax.
+This driver permits reading temperature sensor embedded inside Intel
+Core  and Intel Atom CPUs. Temperature is measured in degrees Celsius
+and measurement resolution is 1 degree C. Valid temperatures are from 0
+to TjMax degrees C, because the actual value of temperature register is
+in fact a delta from TjMax.
 
 Temperature known as TjMax is the maximum junction temperature of processor.
 Intel defines this temperature as 85C or 100C. At this temperature, protection
@@ -35,4 +36,5 @@ temp1_label	 - Contains string "Core X", where X is processor
 
 The TjMax temperature is set to 85 degrees C if undocumented model specific
 register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as
-(sometimes) documented in processor datasheet.
+(sometimes) documented in processor datasheet. The Intel Atom has TjMax 95C
+as per the specification.
diff --git a/drivers/hwmon/coretemp.c b/drivers/hwmon/coretemp.c
index 93c1722..0f58eff 100644
--- a/drivers/hwmon/coretemp.c
+++ b/drivers/hwmon/coretemp.c
@@ -1,7 +1,7 @@
 /*
  * coretemp.c - Linux kernel module for hardware monitoring
  *
- * Copyright (C) 2007 Rudolf Marek <r.marek@assembler.cz>
+ * Copyright (C) 2007, 2008 Rudolf Marek <r.marek@assembler.cz>
  *
  * Inspired from many hwmon drivers
  *
@@ -244,8 +244,14 @@ static int __devinit coretemp_probe(struct platform_device *pdev)
 		}
 	}
 
-	data->tjmax = adjust_tjmax(c, data->id, &pdev->dev);
-	platform_set_drvdata(pdev, data);
+	/* Intel Atom has only fixed TjMax at 95C */
+
+	if (c->x86_model == 0x1c) {
+		data->tjmax = 95000;
+	} else {
+		/* Adjust the TjMax for the rest of Core2 family */
+		data->tjmax = adjust_tjmax(c, data->id, &pdev->dev);
+	}
 
 	/* read the still undocumented IA32_TEMPERATURE_TARGET it exists
 	   on older CPUs but not in this register */
@@ -265,6 +271,8 @@ static int __devinit coretemp_probe(struct platform_device *pdev)
 		}
 	}
 
+	platform_set_drvdata(pdev, data);
+
 	if ((err = sysfs_create_group(&pdev->dev.kobj, &coretemp_group)))
 		goto exit_dev;
 
@@ -413,11 +421,11 @@ static int __init coretemp_init(void)
 	for_each_online_cpu(i) {
 		struct cpuinfo_x86 *c = &cpu_data(i);
 
-		/* check if family 6, models 0xe, 0xf, 0x16, 0x17, 0x1A */
+		/* check if family 6, models 0xe, 0xf, 0x16, 0x17, 0x1A, 0x1C */
 		if ((c->cpuid_level < 0) || (c->x86 != 0x6) ||
 		    !((c->x86_model == 0xe) || (c->x86_model == 0xf) ||
 			(c->x86_model == 0x16) || (c->x86_model == 0x17) ||
-			(c->x86_model == 0x1A))) {
+			(c->x86_model == 0x1A) || c->x86_model == 0x1C)) {
 
 			/* supported CPU not found, but report the unknown
 			   family 6 CPU */
-- 
1.5.6.3


[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Rudolf Marek]

Maxim Levitsky wrote:
> I use an old patch, and it works fine, was it forgotten?

Hi,

Well I think there are more atoms with different TjMax and I became tired to ask 
Intel again and again.

Rudolf

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Jean Delvare]

On Tue, 28 Apr 2009 12:39:32 +0200, Rudolf Marek wrote:
> Maxim Levitsky wrote:
> > I use an old patch, and it works fine, was it forgotten?
> 
> Hi,
> 
> Well I think there are more atoms with different TjMax and I became tired to ask 
> Intel again and again.

What's the plan then, never ever support the Atom thermal sensors?
Seems wrong, TjMax for Core/Core2 is not that clear either, but we
still do support these.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Maxim Levitsky]

On Tue, 2009-04-28 at 15:13 +0200, Jean Delvare wrote:
> On Tue, 28 Apr 2009 12:39:32 +0200, Rudolf Marek wrote:
> > Maxim Levitsky wrote:
> > > I use an old patch, and it works fine, was it forgotten?
> > 
> > Hi,
> > 
> > Well I think there are more atoms with different TjMax and I became tired to ask 
> > Intel again and again.
> 
> What's the plan then, never ever support the Atom thermal sensors?
> Seems wrong, TjMax for Core/Core2 is not that clear either, but we
> still do support these.
> 

Lets just expose raw value, and let usespace (or user do the
calculation)

Just expose the  (30 degrees below maximum or so)

Best regards,
	Maxim Levitsky


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Jean Delvare]

On Tue, 28 Apr 2009 16:18:45 +0300, Maxim Levitsky wrote:
> On Tue, 2009-04-28 at 15:13 +0200, Jean Delvare wrote:
> > On Tue, 28 Apr 2009 12:39:32 +0200, Rudolf Marek wrote:
> > > Maxim Levitsky wrote:
> > > > I use an old patch, and it works fine, was it forgotten?
> > > 
> > > Hi,
> > > 
> > > Well I think there are more atoms with different TjMax and I became tired to ask 
> > > Intel again and again.
> > 
> > What's the plan then, never ever support the Atom thermal sensors?
> > Seems wrong, TjMax for Core/Core2 is not that clear either, but we
> > still do support these.
> > 
> 
> Lets just expose raw value, and let usespace (or user do the
> calculation)
> 
> Just expose the  (30 degrees below maximum or so)

This doesn't fit in our standard interface. If we want to do this (I'm
not sure) we need to define a new interface first.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Philip Pokorny]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

--===============5637066188382201236==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9C805.06E850DC"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 1689 bytes --]

The Intel EPSD systems with IPMI are now reporting 'margins' instead of 'temperatres' for many sensors.

A margin is measured in degrees and is a negative number.  As the CPU or other device gets hotter the value increases towards zero.  If it goes positive, then you have 'overheated' and exceeded the spec.

I would agree that you should expose thw value from the sensor but would suggest we label these as 'margins' and not 'temperatures'

Phil P.

-- 
Philip Pokorny, RHCE
Chief Hardware Architect
Penguin Computing  http://www.penguincomputing.com

 -----Original Message-----
From: 	Maxim Levitsky [mailto:maximlevitsky@gmail.com]
Sent:	Tuesday, April 28, 2009 06:21 AM Pacific Standard Time
To:	Jean Delvare
Cc:	lm-sensors@lm-sensors.org
Subject:	Re: [lm-sensors] Why internal sensor on atom cpu isn't yet supported?

On Tue, 2009-04-28 at 15:13 +0200, Jean Delvare wrote:
> On Tue, 28 Apr 2009 12:39:32 +0200, Rudolf Marek wrote:
> > Maxim Levitsky wrote:
> > > I use an old patch, and it works fine, was it forgotten?
> > 
> > Hi,
> > 
> > Well I think there are more atoms with different TjMax and I became tired to ask 
> > Intel again and again.
> 
> What's the plan then, never ever support the Atom thermal sensors?
> Seems wrong, TjMax for Core/Core2 is not that clear either, but we
> still do support these.
> 

Lets just expose raw value, and let usespace (or user do the
calculation)

Just expose the  (30 degrees below maximum or so)

Best regards,
	Maxim Levitsky


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[-- Attachment #3: Type: text/html, Size: 2538 bytes --]

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Philip Pokorny]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

--===============4730096418932039472==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9C805.9B643420"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 1817 bytes --]

Why doesn't this fit the current temperature interface?  What is there in the interface that says it has to be an absolute temperature and not a relative temperature?

Alarms, min-max, hysterisis, etc all still work the same, they are just shifted so that the max limit is zero and the typical values are less than zero.  We allow negative temperatures in the library.

Phil P.

-- 
Philip Pokorny, RHCE
Chief Hardware Architect
Penguin Computing  http://www.penguincomputing.com

 -----Original Message-----
From: 	Jean Delvare [mailto:khali@linux-fr.org]
Sent:	Tuesday, April 28, 2009 06:26 AM Pacific Standard Time
To:	Maxim Levitsky
Cc:	lm-sensors@lm-sensors.org
Subject:	Re: [lm-sensors] Why internal sensor on atom cpu isn't yet supported?

On Tue, 28 Apr 2009 16:18:45 +0300, Maxim Levitsky wrote:
> On Tue, 2009-04-28 at 15:13 +0200, Jean Delvare wrote:
> > On Tue, 28 Apr 2009 12:39:32 +0200, Rudolf Marek wrote:
> > > Maxim Levitsky wrote:
> > > > I use an old patch, and it works fine, was it forgotten?
> > > 
> > > Hi,
> > > 
> > > Well I think there are more atoms with different TjMax and I became tired to ask 
> > > Intel again and again.
> > 
> > What's the plan then, never ever support the Atom thermal sensors?
> > Seems wrong, TjMax for Core/Core2 is not that clear either, but we
> > still do support these.
> > 
> 
> Lets just expose raw value, and let usespace (or user do the
> calculation)
> 
> Just expose the  (30 degrees below maximum or so)

This doesn't fit in our standard interface. If we want to do this (I'm
not sure) we need to define a new interface first.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[-- Attachment #3: Type: text/html, Size: 2677 bytes --]

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Maxim Levitsky]

On Tue, 2009-04-28 at 06:27 -0700, Philip Pokorny wrote:
> The Intel EPSD systems with IPMI are now reporting 'margins' instead
> of 'temperatres' for many sensors.
> 
> A margin is measured in degrees and is a negative number.  As the CPU
> or other device gets hotter the value increases towards zero.  If it
> goes positive, then you have 'overheated' and exceeded the spec.
> 
> I would agree that you should expose thw value from the sensor but
> would suggest we label these as 'margins' and not 'temperatures'

Actually, I think that there even is no need to know the tjmax.
Why would user care how hot cpu is?

I would just know that it is below its maximum designed temperature, and
how much, thus raw value would work just fine.

Regards,
	Maxim Levitsky




_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Why internal sensor on atom cpu isn't yet

[Jean Delvare]

On Tue, 28 Apr 2009 06:31:16 -0700, Philip Pokorny wrote:
> Why doesn't this fit the current temperature interface?  What is there in the interface that says it has to be an absolute temperature and not a relative temperature?

This isn't spelt out explicitly, but it is pretty implicit. Suddenly
reporting relative temperature margins the same way we report absolute
temperature values will only confuse the user (and ourselves.) When
sensors report "+20 degrees", how will you know whether the system is
totally overheating or if it is rather cold?

If we start reporting temperature margins, the interface must be
different from what we have today so that libsensors and other tools
relying on our sysfs interface aren't screwed up. We want sensors and
other tools to clearly label temperature margins as such.

And really I think it makes a lot of sense to report relative
temperatures, I have no objection to doing that. The absolute
temperature is one thing, but the key information is whether the system
is running within its thermal specs or not.

> Alarms, min-max, hysterisis, etc all still work the same, they are just shifted so that the max limit is zero and the typical values are less than zero.  We allow negative temperatures in the library.

Just because we support them in the library doesn't mean all
applications support them. I fixed a bug with negative temperatures in
sensord a few months ago... Anyway the problem is not with negative
values. The problem is that users must _know_ what they are seeing.

So please let's not rush here. The proper interface, both at the sysfs
and libsensors levels, should be discussed.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors