linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* pmud monitoring temperature (Re: powerbook doubles)
@ 2001-01-28 20:25 Brad Midgley
  0 siblings, 0 replies; 7+ messages in thread
From: Brad Midgley @ 2001-01-28 20:25 UTC (permalink / raw)
  To: Iain Sandoe, brad, linuxppc-dev; +Cc: djosg


Iain,

until we have proper heat control in the kernel, maybe pmud should monitor the temperature and put
the machine to sleep if it runs too hot.

> > /proc/cpuinfo does not report the temperature (i'm not sure the hardware
> > can report it).
>
> yes, it can.
> Someone posted a patch some time last year to get the info into the /proc
> entry.  If that no longer applies it shouldn't be too difficult to update
> it.

i found it and i'll try to apply it today:

http://lists.linuxppc.org/listarcs/linuxppc-dev/200009/msg00365.html

thanks
brad

--
Brad
brad@turbolinux.com      http://www.turbolinux.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
@ 2001-01-29  1:49 Brad Midgley
  2001-01-29 14:49 ` Michael Schmitz
  0 siblings, 1 reply; 7+ messages in thread
From: Brad Midgley @ 2001-01-29  1:49 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: djosg


hi,

> > yes, it can.
> > Someone posted a patch some time last year to get the info into the /proc
> > entry.  If that no longer applies it shouldn't be too difficult to update
> > it.

i reworked this patch to work with the current bk tree (argh. i just complained to iain that diffs
against a moving target were gross)

http://redcloud.uccs.edu/~bcmidgle/linux/

btw, it looks like troy wants the _{gs}et_THRM{123} macros changed to use some different macros,
but i'm not familiar with that stuff so i just reenabled the old macros.

> until we have proper heat control in the kernel, maybe pmud should monitor the temperature and
put
> the machine to sleep if it runs too hot.

i'm looking into this part.

btw, what is a dangerous temperature? with the bays empty and a housefan running nearby (ie
relatively cool) it is reporting 42c.

--
Brad
brad@turbolinux.com      http://www.turbolinux.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
  2001-01-29  1:49 Brad Midgley
@ 2001-01-29 14:49 ` Michael Schmitz
  2001-01-29 22:24   ` Troy Benjegerdes
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Schmitz @ 2001-01-29 14:49 UTC (permalink / raw)
  To: Brad Midgley; +Cc: linuxppc-dev, djosg

[-- Attachment #1: Type: TEXT/PLAIN, Size: 897 bytes --]

> i reworked this patch to work with the current bk tree (argh. i just complained to iain that diffs
> against a moving target were gross)
>
> http://redcloud.uccs.edu/~bcmidgle/linux/
>
> btw, it looks like troy wants the _{gs}et_THRM{123} macros changed to use some different macros,
> but i'm not familiar with that stuff so i just reenabled the old macros.

I don't think what changes you propose there but from the comment on your
patch page ('cpu speed not included in calculations') it seems you picked
up the old version of the patch. I attach the version including
conversion time calculation from processor speed (for 2.4.0pre). The CPU
speed is  preset to 500 MHz in case it can't be determined from OF, this
gives too long conversion times for slower processors - does this hurt?
What is the maximum CPU speed for machines without clock_frequency
present in the device tree?

	Michael

[-- Attachment #2: 2.4.0-test9 cputemp patch --]
[-- Type: TEXT/PLAIN, Size: 3855 bytes --]

--- 2.4.0-test9/arch/ppc/kernel/setup.c.cputemp	Tue Sep 12 07:51:56 2000
+++ 2.4.0-test9/arch/ppc/kernel/setup.c	Sun Oct  8 14:50:09 2000
@@ -181,31 +181,84 @@
 	ppc_md.halt();
 }
   
+
+extern int _get_THRM1();
+extern int _get_THRM2();
+extern int _get_THRM3();
+extern int _set_THRM1(int);
+extern int _set_THRM2(int);
+extern int _set_THRM3(int);
+
 unsigned long cpu_temp(void)
 {
 	unsigned char thres = 0;
+	unsigned int othrm1;
+	unsigned int othrm2;
+	unsigned int othrm3;
+	unsigned int thrm1;
+	unsigned int thrm3;
+	unsigned int cnt;
+	unsigned int thresd;
+	unsigned int threst;
+	unsigned int i;
+	unsigned int cpu_freq;
 	
-#if 0
+	othrm1 = _get_THRM1();
+	othrm2 = _get_THRM2();
+	othrm3 = _get_THRM3();
 	/* disable thrm2 */
 	_set_THRM2( 0 );
-	/* threshold 0 C, tid: exceeding threshold, tie: don't generate interrupt */
-	_set_THRM1( THRM1_V );
+	_set_THRM1( 0 );
 
 	/* we need 20us to do the compare - assume 300MHz processor clock */
+	/* max value for sitv is 0x3fff - or 16383 */
+	/* this set for 500 MHz Pismo - how do we get access to clock?? */
+
+	cpu_freq = 500;
+	if ( have_of )
+	{
+		struct device_node *cpu_node;
+		int *fp;
+
+		cpu_node = find_type_devices("cpu");
+		if ( cpu_node ) {
+			fp = (int *) get_property(cpu_node, "clock-frequency", NULL);
+			if ( fp ) cpu_freq = *fp / 1000000;
+		}
+	}
+
+	/* 25 usec conversion time - max for 500 Mhz is approx. 32 usec */
 	_set_THRM3(0);
-	_set_THRM3(THRM3_E | (300*30)<<18 );
+	_set_THRM3(THRM3_E | THRM3_SITV(cpu_freq*25) );
 
-	udelay(100);
-	/* wait for the compare to complete */
-	/*while ( !(_get_THRM1() & THRM1_TIV) ) ;*/
-	if ( !(_get_THRM1() & THRM1_TIV) )
-		printk("no tiv\n");
-	if ( _get_THRM1() & THRM1_TIN )
-		printk("crossed\n");
+	thresd = 1 << 6;
+	threst = thresd;
+	i =  7;
+	while (i > 1 && thresd > 2)
+		{
+		thrm1 = (THRM1_THRES(threst)) | THRM1_V;
+		_set_THRM1(thrm1);
+		cnt = 10000;
+		while ( !((thrm1=_get_THRM1()) & THRM1_TIV) && cnt ) cnt--;
+		/* printk("THRM1 %8x %d %c %d %d %d\n",thrm1,10000-cnt,(thrm1&THRM1_TIN?'x':' '),threst,thresd,i); */
+		if (cnt == 0)
+			{ printk("THRM1: no interrupt %8x\n",thrm1); threst = 0; break; }
+		else
+			{
+			if ( thrm1 & THRM1_TIN )
+				{ thresd = thresd >> 1; threst += thresd; }
+			else
+				{ thresd = thresd >> 1; threst -= thresd; }
+			i--;
+			}
+		}
+	thres = threst;
+	/* printk("THRM1 %d\n",threst); */
 	/* turn everything off */
-	_set_THRM3(0);
-	_set_THRM1(0);
-#endif
+	_set_THRM3(othrm3);
+	/*_set_THRM1(0);*/
+	_set_THRM1(othrm1);
+	_set_THRM2(othrm2);
 		
 	return thres;
 }
--- 2.4.0-test9/include/asm-ppc/processor.h.cputemp	Mon Sep 11 00:45:07 2000
+++ 2.4.0-test9/include/asm-ppc/processor.h	Sun Oct  8 14:27:00 2000
@@ -261,15 +261,16 @@
 #define	  TCR_FIE		0x00800000	/* FIT Interrupt Enable */
 #define	  TCR_ARE		0x00400000	/* Auto Reload Enable */
 #define	SPRN_THRM1	0x3FC	/* Thermal Management Register 1 */
-#define	  THRM1_TIN		(1<<0)
-#define	  THRM1_TIV		(1<<1)
-#define	  THRM1_THRES		(0x7f<<2)
-#define	  THRM1_TID		(1<<29)
-#define	  THRM1_TIE		(1<<30)
-#define	  THRM1_V		(1<<31)
+#define	  THRM1_TIN		(1<<31)		/* these bits were defined in inverted endian sense originally */
+#define	  THRM1_TIV		(1<<30)
+#define	  THRM1_THRES(x)	((x&0x7f)<<23)
+#define	  THRM1_TID		(1<<2)
+#define	  THRM1_TIE		(1<<1)
+#define	  THRM1_V		(1<<0)
 #define	SPRN_THRM2	0x3FD	/* Thermal Management Register 2 */
 #define	SPRN_THRM3	0x3FE	/* Thermal Management Register 3 */
-#define	  THRM3_E		(1<<31)
+#define	  THRM3_E		(1<<0)
+#define   THRM3_SITV(x)		((x&0x3fff)<<1)
 #define	SPRN_TSR	0x3D8	/* Timer Status Register */
 #define	  TSR_ENW		0x80000000	/* Enable Next Watchdog */
 #define	  TSR_WIS		0x40000000	/* WDT Interrupt Status */

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
@ 2001-01-29 15:19 Iain Sandoe
  2001-01-29 16:18 ` Benjamin Herrenschmidt
  0 siblings, 1 reply; 7+ messages in thread
From: Iain Sandoe @ 2001-01-29 15:19 UTC (permalink / raw)
  To: Michael Schmitz, Brad Midgley; +Cc: linuxppc-dev, djosg


> What is the maximum CPU speed for machines without clock_frequency
> present in the device tree?

wouldn't you have to go back quite a long way to find one?
My 9600 has it - and that's nearly prehistoric ;-)

Iain

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
@ 2001-01-29 15:58 Brad Midgley
  0 siblings, 0 replies; 7+ messages in thread
From: Brad Midgley @ 2001-01-29 15:58 UTC (permalink / raw)
  To: Michael Schmitz, Brad Midgley; +Cc: linuxppc-dev, djosg


Michael

> gives too long conversion times for slower processors - does this hurt?

the motorola docs suggest waiting too long is fine. (they talk about how the only problem is the
temp may be changing -- but that the temperature only changes at a max 1C/sec)

i think assuming 500mhz is fine.

--
Brad
brad@turbolinux.com      http://www.turbolinux.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
  2001-01-29 15:19 pmud monitoring temperature (Re: powerbook doubles) Iain Sandoe
@ 2001-01-29 16:18 ` Benjamin Herrenschmidt
  0 siblings, 0 replies; 7+ messages in thread
From: Benjamin Herrenschmidt @ 2001-01-29 16:18 UTC (permalink / raw)
  To: Iain Sandoe, linuxppc-dev


>> What is the maximum CPU speed for machines without clock_frequency
>> present in the device tree?
>
>wouldn't you have to go back quite a long way to find one?
>My 9600 has it - and that's nearly prehistoric ;-)

The problem is that this property is often wrong...

I think Troy's temperature code (in bk _2_5) is an hard-coded value that
should be good enough for most CPUs speeds. We did however notice quite
wrong results with some G4s used in Apple's dual G4s.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: pmud monitoring temperature (Re: powerbook doubles)
  2001-01-29 14:49 ` Michael Schmitz
@ 2001-01-29 22:24   ` Troy Benjegerdes
  0 siblings, 0 replies; 7+ messages in thread
From: Troy Benjegerdes @ 2001-01-29 22:24 UTC (permalink / raw)
  To: Michael Schmitz; +Cc: Brad Midgley, linuxppc-dev, djosg


On Mon, Jan 29, 2001 at 03:49:02PM +0100, Michael Schmitz wrote:
> > i reworked this patch to work with the current bk tree (argh. i just complained to iain that diffs
> > against a moving target were gross)
> >
> > http://redcloud.uccs.edu/~bcmidgle/linux/
> >
> > btw, it looks like troy wants the _{gs}et_THRM{123} macros changed to use some different macros,
> > but i'm not familiar with that stuff so i just reenabled the old macros.
>
> I don't think what changes you propose there but from the comment on your
> patch page ('cpu speed not included in calculations') it seems you picked
> up the old version of the patch. I attach the version including
> conversion time calculation from processor speed (for 2.4.0pre). The CPU
> speed is  preset to 500 MHz in case it can't be determined from OF, this
> gives too long conversion times for slower processors - does this hurt?
> What is the maximum CPU speed for machines without clock_frequency
> present in the device tree?

Guys, you should *really* take a look at the CONFIG_TAU stuff in linuxppc_2_5.
It's interrupt driven, so the delay doesn't really matter, and you can't cause
a DOS by infinitely re-reading /proc/cpuinfo.

And does anyone think this is tested enough to move to linuxppc_2_4?

--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer@drgw.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2001-01-29 22:24 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-01-29 15:19 pmud monitoring temperature (Re: powerbook doubles) Iain Sandoe
2001-01-29 16:18 ` Benjamin Herrenschmidt
  -- strict thread matches above, loose matches on Subject: below --
2001-01-29 15:58 Brad Midgley
2001-01-29  1:49 Brad Midgley
2001-01-29 14:49 ` Michael Schmitz
2001-01-29 22:24   ` Troy Benjegerdes
2001-01-28 20:25 Brad Midgley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).