mpc8xx - power save modes - PIT

mpc8xx - power save modes - PIT

[Patrick Mahoney]

Hello pple,

My setup: MPC850 on a RPXlite_dw board.

My problem:

I am trying toggle between power saving modes and evaluate the current
drops with an ampermeter.

I succeeded in switching to several power modes, but each time i
switch, my serial connection dies, even if i switch to the  'normal
low mode', which is supposed to keep all functionnalities  present.

I am looking to use the PIT to automatically bring back the chip to
normal full power mode.

I tried the following:

      init_timer(&timer);
      timer.expires=1000;
      timer.function=timer_handler;
      add_timer(&timer);

without success. The kernel oops'es everytime. Ive been browsing the
kernel sources, but have yet to see where the PIT was
initialized/used.

Would anyone have successfully used the several power modes of the
mpc850 (or equivalent) through linux 2.4? If so, is there any code
snippet available?

Also, do you have any idea as to why the serial connection dies? Is it
a uart syncing -type problem?

Best regards,


Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

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

Patrick Mahoney wrote:
>
> Hello pple,
>
> My setup: MPC850 on a RPXlite_dw board.
>
> My problem:
>
> I am trying toggle between power saving modes and evaluate the current
> drops with an ampermeter.
>
> I succeeded in switching to several power modes, but each time i
> switch, my serial connection dies, even if i switch to the  'normal
> low mode', which is supposed to keep all functionnalities  present.
>
> I am looking to use the PIT to automatically bring back the chip to
> normal full power mode.
>
> I tried the following:
>
>       init_timer(&timer);
>       timer.expires=1000;
>       timer.function=timer_handler;
>       add_timer(&timer);
>
> without success. The kernel oops'es everytime. Ive been browsing the
> kernel sources, but have yet to see where the PIT was
> initialized/used.
>
> Would anyone have successfully used the several power modes of the
> mpc850 (or equivalent) through linux 2.4? If so, is there any code
> snippet available?
>

	I have played with some of the power saving modes on our custom
850 board and have had no problems. I have toyed with the Doze High and
Doze Low modes in the idle loop. Attached is a hacked up idle loop for
kernel 2.4.19 that works for me.

Do you have the SCCR[PRQEN] bit set?

Is there any particular reason you want to wake up the processor with
the PIT instead of just letting any old interrupt wake it up?

> Also, do you have any idea as to why the serial connection dies? Is it
> a uart syncing -type problem?

I'm not sure but could the SCCR[CRQEN] bit not being set and a normal low
clock speed set to low to allow the CPM to work properly cause this?

>
> Best regards,
>
> Pat Mahoney
>

You should be able to drop my idle.c in place of the old one. To disable
my hack just comment out the #define MPC8XX_POWERSAVE . My comments
shouldn't be to hard to understand. Also I have the SCCR[PRQEN] and the
SCCR[CRQEN] bits set.

Please let me know how this works.

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


[-- Attachment #2: idle.c --]
[-- Type: text/plain, Size: 10104 bytes --]

/*
 * BK Id: SCCS/s.idle.c 1.20 03/19/02 15:04:39 benh
 */
/*
 * Idle daemon for PowerPC.  Idle daemon will handle any action
 * that needs to be taken when the system becomes idle.
 *
 * Written by Cort Dougan (cort@cs.nmt.edu)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 */
#include <linux/config.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/stddef.h>
#include <linux/unistd.h>
#include <linux/ptrace.h>
#include <linux/slab.h>

#include <asm/pgtable.h>
#include <asm/uaccess.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/processor.h>
#include <asm/mmu.h>
#include <asm/cache.h>
#include <asm/cputable.h>


#define MPC8XX_POWERSAVE


#ifdef MPC8XX_POWERSAVE
#include <asm/mpc8xx.h>
#include <asm/8xx_immap.h>
#endif


void zero_paged(void);

#ifndef MPC8XX_POWERSAVE
void power_save(void);
#endif

unsigned long zero_paged_on = 0;
unsigned long powersave_nap = 0;

unsigned long *zero_cache;    /* head linked list of pre-zero'd pages */
atomic_t zerototal;      /* # pages zero'd over time */
atomic_t zeropage_hits;  /* # zero'd pages request that we've done */
atomic_t zero_sz;	      /* # currently pre-zero'd pages */
atomic_t zeropage_calls; /* # zero'd pages request that've been made */

int idled(void)
{
#ifdef MPC8XX_POWERSAVE
	int reg;
#else
	int do_power_save = 0;
	/* Check if CPU can powersave */
	if (cur_cpu_spec[smp_processor_id()]->cpu_features &
		(CPU_FTR_CAN_DOZE | CPU_FTR_CAN_NAP))
		do_power_save = 1;
#endif
	/* endless loop with no priority at all */
	current->nice = 20;
	current->counter = -100;
	init_idle();
	for (;;) {
#ifdef CONFIG_SMP
		if (!do_power_save) {
			/*
			 * Deal with another CPU just having chosen a thread to
			 * run here:
			 */
			int oldval = xchg(&current->need_resched, -1);

			if (!oldval) {
				while(current->need_resched == -1)
					; /* Do Nothing */
			}
		}
#endif

#ifdef MPC8XX_POWERSAVE
/*********************************************************

	IMPORTANT!!

if using doze modes make sure the SCCR[PRQEN] is set!

*********************************************************/



		while(!current->need_resched) {
			_nmask_and_or_msr( ( MSR_POW | MSR_EE ), 0);	/* disable interupts and Powersave Mode*/
			/* we disable interupts to avoid losing an interupt that should cause a wake up.
			Powersave Mode needs to be disabled to prevent entering Powersaving Mode right
			after PLPRCR is writen. We need to re-enable interupts first or we won't wake up */

			((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;	/*unlock PLPRCR register*/
			reg = ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr;  /*Read current PLPRCR*/
			((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg ; /* program PLPRCR */
			/* Reset the TMIST bit here or we might not (probaly won't) make it to Powersaving mode */
			reg &= 0xFFFFF8FF;		/*clear CSRC bit and the LPM bits*/
			((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;	/*unlock PLPRCR register*/
/*			reg |= 0x00000400; */		/*set just the CSRC bit placing in Normal Low Mode */
			/* Note Noramal Low Mode just keeps reprograming its self and has interupts blocked most
			of the time. Should not be much of a problem as long as DFNL is not set to divide clock
			by too much. This probably won't save very much power */
/*			reg |= 0x00000100; */		/*set LPM bits to 01 placing in Doze High Mode */
			reg |= 0x00000500;		/*set the CSRC bit and the LPM bits placing in Doze Low Mode*/
			((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg;	/* program PLPRCR */
			_nmask_and_or_msr(0, MSR_POW | MSR_EE); /*re-enable interupts set into Powersave Mode*/
			/* processor should transition in to powersave mode as soon as MSR bits are set*/
/*			_nmask_and_or_msr(MSR_POW,0);*/ /*dissable Powersave Mode (probably not needed)*/
		}
			schedule();
			check_pgt_cache();

#else

		if (do_power_save && !current->need_resched)
			power_save();

		if (current->need_resched) {
			schedule();
			check_pgt_cache();
		}
#endif
	}
	return 0;
}

/*
 * SMP entry into the idle task - calls the same thing as the
 * non-smp versions. -- Cort
 */
int cpu_idle(void)
{
	idled();
	return 0;
}

#if 0
/*
 * Returns a pre-zero'd page from the list otherwise returns
 * NULL.
 */
unsigned long get_zero_page_fast(void)
{
	unsigned long page = 0;

	atomic_inc(&zero_cache_calls);
	if ( zero_quicklist )
	{
		/* atomically remove this page from the list */
		register unsigned long tmp;
		asm (	"101:lwarx  %1,0,%3\n"  /* reserve zero_cache */
			"    lwz    %0,0(%1)\n" /* get next -- new zero_cache */
			"    stwcx. %0,0,%3\n"  /* update zero_cache */
			"    bne-   101b\n"     /* if lost reservation try again */
			: "=&r" (tmp), "=&r" (page), "+m" (zero_cache)
			: "r" (&zero_quicklist)
			: "cc" );
#ifdef CONFIG_SMP
		/* if another cpu beat us above this can happen -- Cort */
		if ( page == 0 )
			return 0;
#endif /* CONFIG_SMP */
		/* we can update zerocount after the fact since it is not
		 * used for anything but control of a loop which doesn't
		 * matter since it won't affect anything if it zeros one
		 * less page -- Cort
		 */
		atomic_inc((atomic_t *)&zero_cache_hits);
		atomic_dec((atomic_t *)&zero_cache_sz);

		/* zero out the pointer to next in the page */
		*(unsigned long *)page = 0;
		return page;
	}
	return 0;
}

/*
 * Experimental stuff to zero out pages in the idle task
 * to speed up get_free_pages(). Zero's out pages until
 * we've reached the limit of zero'd pages.  We handle
 * reschedule()'s in here so when we return we know we've
 * zero'd all we need to for now.
 */
int zero_cache_water[2] = { 25, 96 }; /* high and low water marks for zero cache */
void zero_paged(void)
{
	unsigned long pageptr = 0;	/* current page being zero'd */
	unsigned long bytecount = 0;
        register unsigned long tmp;
	pte_t *pte;

	if ( atomic_read(&zero_cache_sz) >= zero_cache_water[0] )
		return;
	while ( (atomic_read(&zero_cache_sz) < zero_cache_water[1]) && (!current->need_resched) )
	{
		/*
		 * Mark a page as reserved so we can mess with it
		 * If we're interrupted we keep this page and our place in it
		 * since we validly hold it and it's reserved for us.
		 */
		pageptr = __get_free_pages(GFP_ATOMIC, 0);
		if ( !pageptr )
			return;

		if ( current->need_resched )
			schedule();

		/*
		 * Make the page no cache so we don't blow our cache with 0's
		 */
		pte = find_pte(&init_mm, pageptr);
		if ( !pte )
		{
			printk("pte NULL in zero_paged()\n");
			return;
		}

		pte_uncache(*pte);
		flush_tlb_page(find_vma(&init_mm,pageptr),pageptr);
		/*
		 * Important here to not take time away from real processes.
		 */
		for ( bytecount = 0; bytecount < PAGE_SIZE ; bytecount += 4 )
		{
			if ( current->need_resched )
				schedule();
			*(unsigned long *)(bytecount + pageptr) = 0;
		}

		/*
		 * If we finished zero-ing out a page add this page to
		 * the zero_cache atomically -- we can't use
		 * down/up since we can't sleep in idle.
		 * Disabling interrupts is also a bad idea since we would
		 * steal time away from real processes.
		 * We can also have several zero_paged's running
		 * on different processors so we can't interfere with them.
		 * So we update the list atomically without locking it.
		 * -- Cort
		 */

		/* turn cache on for this page */
		pte_cache(*pte);
		flush_tlb_page(find_vma(&init_mm,pageptr),pageptr);
		/* atomically add this page to the list */
		asm (	"101:lwarx  %0,0,%2\n"  /* reserve zero_cache */
			"    stw    %0,0(%3)\n" /* update *pageptr */
#ifdef CONFIG_SMP
			"    sync\n"            /* let store settle */
#endif
			"    stwcx. %3,0,%2\n"  /* update zero_cache in mem */
			"    bne-   101b\n"     /* if lost reservation try again */
			: "=&r" (tmp), "+m" (zero_quicklist)
			: "r" (&zero_quicklist), "r" (pageptr)
			: "cc" );
		/*
		 * This variable is used in the above loop and nowhere
		 * else so the worst that could happen is we would
		 * zero out one more or one less page than we want
		 * per processor on the machine.  This is because
		 * we could add our page to the list but not have
		 * zerocount updated yet when another processor
		 * reads it.  -- Cort
		 */
		atomic_inc((atomic_t *)&zero_cache_sz);
		atomic_inc((atomic_t *)&zero_cache_total);
	}
}
#endif /* 0 */

#ifndef MPC8XX_POWERSAVE
#define DSSALL		.long	(0x1f<<26)+(0x10<<21)+(0x336<<1)

void power_save(void)
{
	unsigned long hid0;
	int nap = powersave_nap;

	/* 7450 has no DOZE mode mode, we return if powersave_nap
	 * isn't enabled
	 */
	if (!(nap || (cur_cpu_spec[smp_processor_id()]->cpu_features & CPU_FTR_CAN_DOZE)))
		return;
	/*
	 * Disable interrupts to prevent a lost wakeup
	 * when going to sleep.  This is necessary even with
	 * RTLinux since we are not guaranteed an interrupt
	 * didn't come in and is waiting for a __sti() before
	 * emulating one.  This way, we really do hard disable.
	 *
	 * We assume that we're sti-ed when we come in here.  We
	 * are in the idle loop so if we're cli-ed then it's a bug
	 * anyway.
	 *  -- Cort
	 */
	_nmask_and_or_msr(MSR_EE, 0);
	if (!current->need_resched)
	{
		__asm__ __volatile__("mfspr %0,1008" : "=r" (hid0) :);
		hid0 &= ~(HID0_NAP | HID0_SLEEP | HID0_DOZE);
		hid0 |= (powersave_nap? HID0_NAP: HID0_DOZE) | HID0_DPM;
		__asm__ __volatile__("mtspr 1008,%0" : : "r" (hid0));
		/* Flush pending data streams, consider this instruction
		 * exist on all altivec capable CPUs
		 */
		__asm__ __volatile__(
			"98:	" stringify(DSSALL) "\n"
			"	sync\n"
			"99:\n"
			".section __ftr_fixup,\"a\"\n"
			"	.long %0\n"
			"	.long %1\n"
			"	.long 98b\n"
			"	.long 99b\n"
			".previous" : : "i" (CPU_FTR_ALTIVEC), "i" (CPU_FTR_ALTIVEC));

		/* set the POW bit in the MSR, and enable interrupts
		 * so we wake up sometime! */
		_nmask_and_or_msr(0, MSR_POW | MSR_EE);
	}
	_nmask_and_or_msr(0, MSR_EE);
}
#endif

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Conn,

Thanks a lot for your reply.

> 	I have played with some of the power saving modes on our custom
> 850 board and have had no problems. I have toyed with the Doze High and
> Doze Low modes in the idle loop. Attached is a hacked up idle loop for
> kernel 2.4.19 that works for me.

I recompiled and booted... it crashed on me! :( Maybe some differences
with the platform... I'll look into that tomorrow.

>
> Do you have the SCCR[PRQEN] bit set?

Have tried with and without sccr[prqen] bit set.

> Is there any particular reason you want to wake up the processor with
> the PIT instead of just letting any old interrupt wake it up?

Well i'd just like to be able to say : "im going to sleep. please wake
me in 5 seconds". If theres an easier way, please enlighten me! :)


> You should be able to drop my idle.c in place of the old one. To disable
> my hack just comment out the #define MPC8XX_POWERSAVE . My comments
> shouldn't be to hard to understand. Also I have the SCCR[PRQEN] and the
> SCCR[CRQEN] bits set.

Yep, i'll dig into it tomorrow. I'm kind of allergic to inline
assembly, but it's allright... ill have some pills! ;)

Once again, thanks a lot for your help.
Best regards,


Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Patrick Mahoney wrote:
>
> Conn,
>
> Thanks a lot for your reply.
>
> >       I have played with some of the power saving modes on our custom
> > 850 board and have had no problems. I have toyed with the Doze High and
> > Doze Low modes in the idle loop. Attached is a hacked up idle loop for
> > kernel 2.4.19 that works for me.
>
>
> I recompiled and booted... it crashed on me! :( Maybe some differences
> with the platform... I'll look into that tomorrow.
>

I forgot to mention my kernel source tree was directly from kernel.org

When using my idle loop, does it crash right away or only when you try to
use the PIT?


>
>
> > Is there any particular reason you want to wake up the processor with
> > the PIT instead of just letting any old interrupt wake it up?
>
> Well i'd just like to be able to say : "im going to sleep. please wake
> me in 5 seconds". If theres an easier way, please enlighten me! :)

	Well if you put the power saving code in the idle loop, when there
isn't anything to do the processor sleeps. When an interrupt happens it
wakes up to service the interrupt then checks to see if it is needed for
other things and if not it goes back to bed (much like me ;-)). If you need
to do something 5 seconds later a sleep call should do the trick unless
you need more precision.

>
> > You should be able to drop my idle.c in place of the old one. To disable
> > my hack just comment out the #define MPC8XX_POWERSAVE . My comments
> > shouldn't be to hard to understand. Also I have the SCCR[PRQEN] and the
> > SCCR[CRQEN] bits set.
>
> Yep, i'll dig into it tomorrow. I'm kind of allergic to inline
> assembly, but it's allright... ill have some pills! ;)
>

	I had it all in C at one point which worked. I have to disable
interrupts and I don't like to be in this state any longer than I have to.
Its a practice I got driven into my head from my Z80 days. Besides, the
inline asm is quicker and smaller and saves you more power because you get
the processor to sleep sooner ;-) . If we all wrote our idle loops in
assembly we could get nothing done a lot quicker.

>
> Once again, thanks a lot for your help.
> Best regards,
>
> Pat Mahoney

If you find something out please let me know.

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Hi Conn,


> I forgot to mention my kernel source tree was directly from kernel.org

Fell free to correct me, but I believe the ppc patched kernel is
identical to the one at source.mvista.com. Still, I'll try with the
latest patch (2.4.18) available on kernel.org.

> When using my idle loop, does it crash right away or only when you try to
> use the PIT?

It crashes before I get a chance to load my module. I dont get to the
shell. It's got nothing to do with the PIT. Here's what my console
gives me:

	i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.5 (20020915)
	i2c-rpx.o: i2c MPC8xx module version 2.6.5 (20020915)
	i2c-algo-8xx.o: scanning bus m8xx...
	Machine check in kernel mode.
	Caused by (from SRR1=1000): Transfer error ack signal
	Oops: machine check, sig: 7
	NIP: 00004038 XER: 20000000 LR: 0002B91C SP: C0143F30 REGS: c0143e80 TRAP: 0200	   Not tainted
	MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
	TASK = c0141fa0[0] 'swapper' Last syscall: 120
	last math 00000000 last altivec 00000000
	GPR00: 00000000 C0143F30 C0141FA0 00000000 00048000 00000000 00000001 FFFFFC18
	GPR08: 00000100 C015F00C C014DBFF C014DCEE 0000000D FA202210 00000000 00000000
	GPR16: 00000000 00000000 00000000 00000000 42004022 00EA5F40 00000000 C0004654
	GPR24: 00000000 00000000 FA200000 743D2F62 00000000 C0160000 C014DC01 55CCAA32
	Call backtrace:
	C0005C94 C0005CA8 C0002268 C0152544 C0002138
	Kernel panic: Attempted to kill the idle task!
	In idle task - not syncing
	<0>Rebooting in 180 seconds..

... and it normally fives me...


	i2c-core.o: i2c core module version 2.6.5 (20020915)
	i2c-dev.o: i2c /dev entries driver module version 2.6.5 (20020915)
	i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.5 (20020915)
	i2c-rpx.o: i2c MPC8xx module version 2.6.5 (20020915)
	 i2c-algo-8xx.o: scanning bus m8xx...
	(90)(a8)(aa)
	i2c-proc.o version 2.6.5 (20020915)
	CPM UART driver version 0.03
	ttyS00 at 0x0280 is a SMC
	eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:33:ce


Hmmm... It seems to oops in the i2c initialisation...

<recompiling...>

Ok. I took out the i2c stuff. It doesn't oops anymore... In fact, in
enters the power saving mode (doze?) you put in the idle.c file before
reaching the console! :))

Could be stuck waiting for a never-coming-interrupt? I gave the
parameter "init=/bin/sash" to the kernel... Any logical explanation to this?


> 	Well if you put the power saving code in the idle loop, when there
> isn't anything to do the processor sleeps. When an interrupt happens it
> wakes up to service the interrupt then checks to see if it is needed for
> other things and if not it goes back to bed (much like me ;-)). If you need
> to do something 5 seconds later a sleep call should do the trick unless
> you need more precision.

It's not a precision thing. It's not so important. It would be neat,
thats all.  :)


Thanks again for your help.
Best regards,



Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

First I must appologize, I sent you the stable C code version instead of the
stable inlined asm version. It appears I deleted the wrong file a month or
so ago  :-( . Oh well it appears you like C anyway.




Patrick Mahoney wrote:
>
> Hi Conn,
>
> > I forgot to mention my kernel source tree was directly from kernel.org
>
> Fell free to correct me, but I believe the ppc patched kernel is
> identical to the one at source.mvista.com. Still, I'll try with the
> latest patch (2.4.18) available on kernel.org.
>
> > When using my idle loop, does it crash right away or only when you try to
> > use the PIT?

Strange....... Hmmmm.....


>
> It crashes before I get a chance to load my module. I dont get to the
> shell. It's got nothing to do with the PIT. Here's what my console
> gives me:
>
>         i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.5 (20020915)
>         i2c-rpx.o: i2c MPC8xx module version 2.6.5 (20020915)
>         i2c-algo-8xx.o: scanning bus m8xx...
>         Machine check in kernel mode.
>         Caused by (from SRR1=1000): Transfer error ack signal
>         Oops: machine check, sig: 7
>         NIP: 00004038 XER: 20000000 LR: 0002B91C SP: C0143F30 REGS: c0143e80 TRAP: 0200    Not tainted
>         MSR: 00001000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
>         TASK = c0141fa0[0] 'swapper' Last syscall: 120
>         last math 00000000 last altivec 00000000
>         GPR00: 00000000 C0143F30 C0141FA0 00000000 00048000 00000000 00000001 FFFFFC18
>         GPR08: 00000100 C015F00C C014DBFF C014DCEE 0000000D FA202210 00000000 00000000
>         GPR16: 00000000 00000000 00000000 00000000 42004022 00EA5F40 00000000 C0004654
>         GPR24: 00000000 00000000 FA200000 743D2F62 00000000 C0160000 C014DC01 55CCAA32
>         Call backtrace:
>         C0005C94 C0005CA8 C0002268 C0152544 C0002138
>         Kernel panic: Attempted to kill the idle task!
>         In idle task - not syncing
>         <0>Rebooting in 180 seconds..
>
> ... and it normally fives me...
>
>         i2c-core.o: i2c core module version 2.6.5 (20020915)
>         i2c-dev.o: i2c /dev entries driver module version 2.6.5 (20020915)
>         i2c-algo-8xx.o: i2c mpc8xx algorithm module version 2.6.5 (20020915)
>         i2c-rpx.o: i2c MPC8xx module version 2.6.5 (20020915)
>          i2c-algo-8xx.o: scanning bus m8xx...
>         (90)(a8)(aa)
>         i2c-proc.o version 2.6.5 (20020915)
>         CPM UART driver version 0.03
>         ttyS00 at 0x0280 is a SMC
>         eth0: CPM ENET Version 0.2 on SCC2, 00:10:ec:00:33:ce
>
> Hmmm... It seems to oops in the i2c initialisation...
>
> <recompiling...>
>
> Ok. I took out the i2c stuff. It doesn't oops anymore... In fact, in
> enters the power saving mode (doze?) you put in the idle.c file before
> reaching the console! :))

PHEW... Good.


>
> Could be stuck waiting for a never-coming-interrupt? I gave the
> parameter "init=/bin/sash" to the kernel... Any logical explanation to this?
>

Strange you should be getting some intermitant interupts from things such as
the real time clock and other misc things and timers. Hmmm... Must be a RPX
hardware thing or something.


> >       Well if you put the power saving code in the idle loop, when there
> > isn't anything to do the processor sleeps. When an interrupt happens it
> > wakes up to service the interrupt then checks to see if it is needed for
> > other things and if not it goes back to bed (much like me ;-)). If you need
> > to do something 5 seconds later a sleep call should do the trick unless
> > you need more precision.
>
> It's not a precision thing. It's not so important. It would be neat,
> thats all.  :)
>
> Thanks again for your help.
> Best regards,
>
> Pat Mahoney

Well I have no idea whats going on. You should be getting some interrupts.
Unless your RPX board is entering the idle loop before these things get
initalized (which I don't think is possible). This has me stumped...

Good Luck,

	Conn

--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Hi Conn,

> Strange you should be getting some intermitant interupts from things such as
> the real time clock and other misc things and timers. Hmmm... Must be a RPX
> hardware thing or something.

That was one of the reasons why i tried playing with the PIT... As I
said, the following code snippet crashes on me...

      init_timer(&timer);
      timer.expires=1000;
      timer.function=timer_handler;
      add_timer(&timer);

I guess I'll have to dig in the kernel sources to find out exacly why
it crashes before playing with the power modes... I'm running out of
options here... :(

Thanks a _lot_ for your help, Conn.
I very much appreciate.


Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Patrick Mahoney wrote:
>
> Hi Conn,
>
> I apologize for sticking to the topic... Getting to doze low mode is
> very important to our project...
>
> You say you got the ppc version of the 2.4.19 kernel from
> ftp.kernel.org... This can't be, since the latest available ppc patch
> is for the 2.4.18 kernel...
>
> So what kernel version/provider did you use your patch on?
>
> Once again, thanks a lot...
>
> Pat Mahoney
>
> > > >       I have played with some of the power saving modes on our custom
> > > > 850 board and have had no problems. I have toyed with the Doze High and
> > > > Doze Low modes in the idle loop. Attached is a hacked up idle loop for
> > > > kernel 2.4.19 that works for me.
>
> [...]
>
> > I forgot to mention my kernel source tree was directly from kernel.org

I got my kernel from ftp.kernel.org . I belive the patches to 2.4.18 were
submitted and included into 2.4.19 from ftp.kernel.org . I don't think there
has been an official patch released for 2.4.19 as of yet.

good luck,

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Patrick Mahoney wrote:
>
> Hello Conn,
>
> Progress has been made... I can succesfully raise the clock rate
> divider up to a factor of 8 before the kernel starts. This makes the
> current consumption drop from 0.41A to 0.32A...

Where are you doing this?
Is the divide by 8 in the SCCR[DFNH] or SCCR[DFNL]?
If you are going to have a SCCR[DFNL] divider that drops your clock
speed below 24MHz you need to set the SCCR[CRQEN] bit to keep ethernet
working. (assuming your DFNH keeps it above 24MHz)

>
> Also, the timer thing, that was a rookie mistake... The timer variable
> was declared on init_module stack, which disappeared before the timer
> interrupt. (Thanks to Hollis for that one).
>
> One more thing. I thought I had SCCR[PRQEN] set, but I did not. Thats
> why your idle.c hack caused a hang before the shell came up. I now
> set SCCR[PRQEN] from the planetcore bootloader and can reach the
> shell.
>
> phew!
>
> All right... Now I know 'idled' gets called... The thing is... Power
> consumption stays the same! :(

Power consumption will stay the same as long as you aren't taxing the
CPU with some task. When you have task running that that needs scheduling
it prevents the idle loop from running the power saving code. When the
CPU is kept busy chewing on this task power consumption should rise back
to about what it was before.

>  The only modification i brought is
> going into doze high instead of doze low... Going to doze low changes
> the clock rate and hangs my kernel...


Could you check and see what you have the SCCR[CRQEN] set to?
I belive if your SCCR[DFNL] is set to a divide ratio that is to high
it could keep the CPM from functioning correctly if the SCCR[CRQEN]
bit is not set. If this bit is set your processor should pop back
into normal high mode for any CPM activity.

I recommend that you set the SCCR[DFNH] to divide by 1 (000 binary)
and SCCR[DFNL] to divide by 8 (010 binary) since your board seems to
function that slowly. Also make sure that the SCCR[CRQEN] bit is set.

IF this works we might beable to try a higher division factor in your
SCCR[DFNL] to save more power.

> Here is my comment-stripped
> loop:
>
>                 while(!current->need_resched) {
>                         _nmask_and_or_msr( ( MSR_POW | MSR_EE ), 0);
>                         ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;
>                         reg = ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr;
>                         ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg ;
>                         reg &= 0xFFFFF8FF;
>                         ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;
>                         reg |= 0x00000100;
>                         ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg;
>                         _nmask_and_or_msr(0, MSR_POW | MSR_EE);
>                 }
>                 schedule();
>                 check_pgt_cache();
>
> Waddaya think?
> Thanks for you help,
>
> Pat Mahoney
>
> On Thu, Oct 10, 2002 at 02:49:32PM -0700, Conn Clark wrote:
> > Patrick Mahoney wrote:
> > >
> > > Hello pple,

<snip>

> > }
> > #endif

	Your idle loop should work fine. I still don't see why Doze Low mode
hangs your kernel. If you have the SCCR[CRQEN] bit set the only time the CPU
should be in Doze Low mode is when its in the idle loop and no CPM activity
is present. If there is CPM activity it should transparently pop into Doze
High mode then back after the CPM activity has finished. Any interupt should
snap it out of either Doze mode and into Normal High mode until the idle loop
power saving code gets executed again. If the SCCR[CRQEN] bit is set then
Doze High and Doze Low modes in the idle loop should be indistingushable from
one another.

There has to be something fishy about a setting for this not to work.

Please keep me advised.

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Conn,

I noticed a couple of things...

1- If SCCR[PRQEN] is NOT set, your idle.c patch makes the current
consumption drop as expected, but the processor never wakes up, which
is normal, but not what we want.

2- If SCCR[PRQEN] IS set, your idle.c patch seems to put the processor
in doze mode at each loop, but the current consumption does not
drop. I printk'ed the 'jiffies' global variable immediately before and
immediately after the
	_nmask_and_or_msr(0, MSR_POW | MSR_EE);
instruction. The printed values are all distant of 3 or 4 jiffies,
which suuggests that the processor spends as much time in doze mode
than in high mode. But the current consumption stays the same...

Any idea?

Regards,



Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Patrick Mahoney wrote:
>
> > > Progress has been made... I can succesfully raise the clock rate
> > > divider up to a factor of 8 before the kernel starts. This makes the
> > > current consumption drop from 0.41A to 0.32A...
> >
> > Where are you doing this?
> > Is the divide by 8 in the SCCR[DFNH] or SCCR[DFNL]?
> > If you are going to have a SCCR[DFNL] divider that drops your clock
> > speed below 24MHz you need to set the SCCR[CRQEN] bit to keep ethernet
> > working. (assuming your DFNH keeps it above 24MHz)
>
> I do this in the planetcore bootloader... Ethernet works fine. Note
> that I am not currently combining this technique with any power saving
> mode...

Does the Planetcore Bootloader allow you to specify both the SCCR[DFNH] and
SCCR[DNFL]?

If it doesn't I would recommend you set the board to run at its highest
speed and set the SCCR[DFNL] in the m8xx_setup.c to something like divide
by 8.


>
> > > All right... Now I know 'idled' gets called... The thing is... Power
> > > consumption stays the same! :(
> >
> > Power consumption will stay the same as long as you aren't taxing the
> > CPU with some task. When you have task running that that needs scheduling
> > it prevents the idle loop from running the power saving code. When the
> > CPU is kept busy chewing on this task power consumption should rise back
> > to about what it was before.
>
> I poorly expressed myself here... Let me rephrase...
>
> The idled routine gets executed repeatedly, as it should be. The
> current consumption, however, does not drop. It stays as high as it
> normally is in full high mode.
>

This may be due to other components current demands making the CPU current
seem insignifigant. This power saving idle loop only saved us about .3 watts
or 50mA in current. We are running a 49.1MHz clock with a normal high
division factor of 1 and a normal low division factor of 2. I found that
using Doze Low doubled our current savings vs Doze High. I would expect
better results with a higher normal low division factor.


> > Could you check and see what you have the SCCR[CRQEN] set to?
>
> PLPRCR[CRQEN] and PLPRCR[PRQEN] are both set in the planetcore
> bootloader. If either one of those bit is not set, the chip never
> wakes up from doze mode.


If the PLPRCR[CRQEN] is not set the chip will still wake up. However your
CPM may not work correctly if the clock speed in normal low mode is not
fast enough.

>
> > I belive if your SCCR[DFNL] is set to a divide ratio that is to high
> > it could keep the CPM from functioning correctly if the SCCR[CRQEN]
> > bit is not set. If this bit is set your processor should pop back
> > into normal high mode for any CPM activity.
>
> Currently, the clock divider = 1. This should not be an issue.
>
> >
> > I recommend that you set the SCCR[DFNH] to divide by 1 (000 binary)
> > and SCCR[DFNL] to divide by 8 (010 binary) since your board seems to
> > function that slowly. Also make sure that the SCCR[CRQEN] bit is set.
>
> Why play with SCCR[DFNL] since i use neither normal low nor doze low
> mode?
>

So that you can use Doze Low Mode to save more power.

> >
> >       Your idle loop should work fine. I still don't see why Doze Low mode
> > hangs your kernel.
>
> I found that one out. The kernel does not support runtime clock rate
> modifications. As simple as that.
>

If I have done the idle loop code correctly the kernel shouldn't be able to
tell. I should have sent you an updated idle.c in my response to Cameron.
Try it in Doze Low mode and see if it works with your board now.

>
> Any explanation as to why the consumption does not drop, even if idled
> get called?
>

As explaned earlier your other commponents may swamp the CPU current draw
making savings unnoticable. In Doze high I noticed we only saved about
25mA.

>
> Thanks a lot,
>
> Pat Mahoney

Good luck and keep me advised.

--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

RE: mpc8xx - power save modes - PIT

[Steven Blakeslee]

In the 850 user manual I found the following to describe the SCCR[DNFH].
"Division factor high frequency. Sets the VCOOUT frequency division factor
for general system
clocks to be used in normal mode. In normal mode, the MPC850 automatically
switches to the
DFNH frequency. To select the DFNH frequency, load this Þeld with the divide
value and clear
CSRC. A loss-of-lock condition does not occur when this Þeld is changed.
This Þeld is cleared by a power-on or hard reset."

You have the following code.
imp->im_clkrst.car_plprcr |= 1<<21;		// plprcr[csrc]=1

It seems like it should be cleared, not set.




-----Original Message-----
From: Patrick Mahoney [mailto:pmahoney@8d.com]
Sent: Thursday, October 10, 2002 4:47 PM
To: Steven Blakeslee
Subject: Re: mpc8xx - power save modes - PIT


I therefore conclude that the register MSB is in the variable
LBS. Thats always goot to know! :) Thanks for the tip...

... but i still lose my console when i switch eith power mode or clock
divider. Ex:

    /* Normal high mode
     * clock divider set to 2
     * (sccr[dfnh]=110)
     */
    imp = (immap_t *)IMAP_ADDR;
    imp->im_clkrst.car_sccr &= ~(0x7<<5);
    imp->im_clkrst.car_sccr |= 0x1<<5;

Would you happen to know why?
Thanks again,


Pat Mahoney



On Thu, Oct 10, 2002 at 04:20:34PM -0400, Steven Blakeslee wrote:
> The line
> imp->im_clkrst.car_plprcr |= 1<<21;
> seems to be incorrect.  This line sets bit 10.  If you are setting
> plprcr[csrc] you would do the following
> imp->im_clkrst.car_plprcr |= 0x80;
>
> The line
> imp->im_clkrst.car_plprcr &= ~(0x3<<22);
> seems to be incorrect.  This line clears 9 and 8.  If you want to clear
> PLPRCR[LPM] you would do the following
> imp->im_clkrst.car_plprcr &= ~(0x100 | 0x200);
>
>
>
> -----Original Message-----
> From: Patrick Mahoney [mailto:pmahoney@8d.com]
> Sent: Thursday, October 10, 2002 3:40 PM
> To: Steven Blakeslee
> Subject: Re: mpc8xx - power save modes - PIT
>
>
> That was supposed to be:
>
>     /* Normal low mode
>      */
>     imp = (immap_t *)IMAP_ADDR;
>     imp->im_clkrstk.cark_plprcrk = ~KAPWR_KEY;
>     imp->im_clkrstk.cark_plprcrk = KAPWR_KEY;
>     imp->im_clkrst.car_plprcr |= 1<<21;
>     imp->im_clkrst.car_plprcr &= ~(0x3<<22);
>
> Sorry bout that.
> Thanks again,
>
>
> Pat Mahoney
>
>
> On Thu, Oct 10, 2002 at 03:33:19PM -0400, Patrick Mahoney wrote:
> > Hi Steven,
> >
> > In my module's init_module function, i do:
> >
> >     /* Normal low mode
> >      * ref: p. 14-21 of mpc850 ref book.
> >      */
> >     imp = (immap_t *)IMAP_ADDR;
> >     imp->im_clkrstk.cark_sccrk = ~KAPWR_KEY;	// unlock the
> >     imp->im_clkrstk.cark_sccrk = KAPWR_KEY;	// 	register key
> >     imp->im_clkrst.car_plprcr |= 1<<21;		// plprcr[csrc]=1
> >     imp->im_clkrst.car_plprcr &= ~(0x3<<22);	// PLPRCR[LPM]=00
> >
> > Did you succeed in toggling between power modes?
> >
> > Thanks for your support.
> > Best regards,
> >
> >
> > Pat Mahoney
> >
> > On Thu, Oct 10, 2002 at 03:19:58PM -0400, Steven Blakeslee wrote:
> > > What are you doing to put the processor into low power mode?  What
> registers
> > > are you changing?
> > >
> > >
> > > -----Original Message-----
> > > From: Patrick Mahoney [mailto:pmahoney@8d.com]
> > > Sent: Thursday, October 10, 2002 2:35 PM
> > > To: linuxppc-embedded@lists.linuxppc.org
> > > Subject: mpc8xx - power save modes - PIT
> > >
> > >
> > >
> > > Hello pple,
> > >
> > > My setup: MPC850 on a RPXlite_dw board.
> > >
> > > My problem:
> > >
> > > I am trying toggle between power saving modes and evaluate the current
> > > drops with an ampermeter.
> > >
> > > I succeeded in switching to several power modes, but each time i
> > > switch, my serial connection dies, even if i switch to the  'normal
> > > low mode', which is supposed to keep all functionnalities  present.
> > >
> > > I am looking to use the PIT to automatically bring back the chip to
> > > normal full power mode.
> > >
> > > I tried the following:
> > >
> > >       init_timer(&timer);
> > >       timer.expires=1000;
> > >       timer.function=timer_handler;
> > >       add_timer(&timer);
> > >
> > > without success. The kernel oops'es everytime. Ive been browsing the
> > > kernel sources, but have yet to see where the PIT was
> > > initialized/used.
> > >
> > > Would anyone have successfully used the several power modes of the
> > > mpc850 (or equivalent) through linux 2.4? If so, is there any code
> > > snippet available?
> > >
> > > Also, do you have any idea as to why the serial connection dies? Is it
> > > a uart syncing -type problem?
> > >
> > > Best regards,
> > >
> > >
> > > Pat Mahoney
> > >

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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Hi Steven,

On Fri, Oct 11, 2002 at 09:15:21AM -0400, Steven Blakeslee wrote:
>
> In the 850 user manual I found the following to describe the SCCR[DNFH].
> "Division factor high frequency. Sets the VCOOUT frequency division factor
> for general system
> clocks to be used in normal mode. In normal mode, the MPC850 automatically
> switches to the
> DFNH frequency. To select the DFNH frequency, load this ?eld with the divide
> value and clear
> CSRC. A loss-of-lock condition does not occur when this ?eld is changed.
> This ?eld is cleared by a power-on or hard reset."
>
> You have the following code.
> imp->im_clkrst.car_plprcr |= 1<<21;		// plprcr[csrc]=1

In fact, that was erronoeus because of the bit ordering stuff
mentioned in a previous mail within this thread. I meant to write:

imp->im_clkrst.car_plprcr |= 0x00000400         // plprcr[csrc]=1

Anyway, i was trying to move to 'normal low mode', which is supposed
to be 100% functionnal, only at a slower pace.

If i either change the dfnh clock divider (ex: sccr[dfnh]=110b) or
move to the normal low mode (plprcr[csrc]=1), i lose my console. :(

Thanks for your support.
Best regards,


Pat Mahoney

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

RE: mpc8xx - power save modes - PIT

[Cameron Rich]

Hi,

I've been following this series of emails closely as we are interested in
low power mode also.

I've tried Conn's code, but I'm experiencing problems with PLPRCR[CSCR] as
being 1 all the time after a rfi. I am also occasionally seeing MSR_POW set
to 1 after the rfi return.

I can work around this problem by setting PLPRCR[CSCR] = 0 and MSR_POW = 0
after the rfi and this eventually works. But is this the solution? I'm also
noticing no great decrease in power consumption even though I've only got a
couple of (sleeping) processes. And it seems that there is (mostly) no time
between entering Doze Low mode and the rfi which confirms the unsatisfactory
power consumption figures.

I have SCCR[CPQEN] (and SCCR[PRQEN]) set to 1.

I'm using a PPC850 processor with Doze Low mode set. DFNL=DFNH=0 and I'm
running 2.4.17 (with a RTAI patch).

Cheers,

Cameron


-----Original Message-----
From: Conn Clark [mailto:clark@esteem.com]
Sent: Wednesday, 16 October 2002 11:09 AM
To: Patrick Mahoney
Cc: May Ling List
Subject: Re: mpc8xx - power save modes - PIT



Patrick Mahoney wrote:
>
> Hello Conn,
>
> Progress has been made... I can succesfully raise the clock rate
> divider up to a factor of 8 before the kernel starts. This makes the
> current consumption drop from 0.41A to 0.32A...

Where are you doing this?
Is the divide by 8 in the SCCR[DFNH] or SCCR[DFNL]?
If you are going to have a SCCR[DFNL] divider that drops your clock
speed below 24MHz you need to set the SCCR[CRQEN] bit to keep ethernet
working. (assuming your DFNH keeps it above 24MHz)

>
> Also, the timer thing, that was a rookie mistake... The timer variable
> was declared on init_module stack, which disappeared before the timer
> interrupt. (Thanks to Hollis for that one).
>
> One more thing. I thought I had SCCR[PRQEN] set, but I did not. Thats
> why your idle.c hack caused a hang before the shell came up. I now
> set SCCR[PRQEN] from the planetcore bootloader and can reach the
> shell.
>
> phew!
>
> All right... Now I know 'idled' gets called... The thing is... Power
> consumption stays the same! :(

Power consumption will stay the same as long as you aren't taxing the
CPU with some task. When you have task running that that needs scheduling
it prevents the idle loop from running the power saving code. When the
CPU is kept busy chewing on this task power consumption should rise back
to about what it was before.

>  The only modification i brought is
> going into doze high instead of doze low... Going to doze low changes
> the clock rate and hangs my kernel...


Could you check and see what you have the SCCR[CRQEN] set to?
I belive if your SCCR[DFNL] is set to a divide ratio that is to high
it could keep the CPM from functioning correctly if the SCCR[CRQEN]
bit is not set. If this bit is set your processor should pop back
into normal high mode for any CPM activity.

I recommend that you set the SCCR[DFNH] to divide by 1 (000 binary)
and SCCR[DFNL] to divide by 8 (010 binary) since your board seems to
function that slowly. Also make sure that the SCCR[CRQEN] bit is set.

IF this works we might beable to try a higher division factor in your
SCCR[DFNL] to save more power.

> Here is my comment-stripped
> loop:
>
>                 while(!current->need_resched) {
>                         _nmask_and_or_msr( ( MSR_POW | MSR_EE ), 0);
>                         ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk =
KAPWR_KEY;
>                         reg = ((immap_t
*)IMAP_ADDR)->im_clkrst.car_plprcr;
>                         ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg
;
>                         reg &= 0xFFFFF8FF;
>                         ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk =
KAPWR_KEY;
>                         reg |= 0x00000100;
>                         ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr =
reg;
>                         _nmask_and_or_msr(0, MSR_POW | MSR_EE);
>                 }
>                 schedule();
>                 check_pgt_cache();
>
> Waddaya think?
> Thanks for you help,
>
> Pat Mahoney
>
> On Thu, Oct 10, 2002 at 02:49:32PM -0700, Conn Clark wrote:
> > Patrick Mahoney wrote:
> > >
> > > Hello pple,

<snip>

> > }
> > #endif

	Your idle loop should work fine. I still don't see why Doze Low mode
hangs your kernel. If you have the SCCR[CRQEN] bit set the only time the CPU
should be in Doze Low mode is when its in the idle loop and no CPM activity
is present. If there is CPM activity it should transparently pop into Doze
High mode then back after the CPM activity has finished. Any interupt should
snap it out of either Doze mode and into Normal High mode until the idle
loop
power saving code gets executed again. If the SCCR[CRQEN] bit is set then
Doze High and Doze Low modes in the idle loop should be indistingushable
from
one another.

There has to be something fishy about a setting for this not to work.

Please keep me advised.

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

> I've tried Conn's code, but I'm experiencing problems with PLPRCR[CSCR] as
> being 1 all the time after a rfi. I am also occasionally seeing MSR_POW set
> to 1 after the rfi return.

Well the 2.4 Linux kernel does not support runtime modifications to
the clock rate. So what's the point of playing with CSCR?

>
> I can work around this problem by setting PLPRCR[CSCR] = 0 and MSR_POW = 0
> after the rfi and this eventually works. But is this the solution? I'm also
> noticing no great decrease in power consumption even though I've only got a
> couple of (sleeping) processes. And it seems that there is (mostly) no time
> between entering Doze Low mode and the rfi which confirms the unsatisfactory
> power consumption figures.

I notice no decrease at all!  :(

I set both crqen and prqen in the bootloader. The idled routine gets
entered and executed repeatedly, but no decrease in current
consumption can be observed.


Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Patrick Mahoney wrote:
>
> > I've tried Conn's code, but I'm experiencing problems with PLPRCR[CSCR] as
> > being 1 all the time after a rfi. I am also occasionally seeing MSR_POW set
> > to 1 after the rfi return.
>
> Well the 2.4 Linux kernel does not support runtime modifications to
> the clock rate. So what's the point of playing with CSCR?

If the CPU is dozing The kernel will never know we changed it as long as
we change it back when the CPU wakes up.

>
> >
> > I can work around this problem by setting PLPRCR[CSCR] = 0 and MSR_POW = 0
> > after the rfi and this eventually works. But is this the solution? I'm also
> > noticing no great decrease in power consumption even though I've only got a
> > couple of (sleeping) processes. And it seems that there is (mostly) no time
> > between entering Doze Low mode and the rfi which confirms the unsatisfactory
> > power consumption figures.
>
> I notice no decrease at all!  :(

You may be expecting to much.

>
> I set both crqen and prqen in the bootloader. The idled routine gets
> entered and executed repeatedly, but no decrease in current
> consumption can be observed.
>
> Pat Mahoney

	Compile up a version of top and see how much time the CPU is Idle.

Good luck

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Patrick Mahoney]

Hello people,

First of all, this might help some...

HW: rpxlite_dw mpc850
SW: linux 2.4 monta vista

I cut my board's consumption by 800mW by
1) taking off the power leds (100mA)
2) bypassing the power regulator (700mA)

I give 2 sources of current to the board: a 5V and a 3.3V, hence
modelising an ideal regulator. Turns out that the board regulator has
a 66% efficiency.

> > Well the 2.4 Linux kernel does not support runtime modifications to
> > the clock rate. So what's the point of playing with CSCR?
>
> If the CPU is dozing The kernel will never know we changed it as long as
> we change it back when the CPU wakes up.

I 100% agree with you... But it doesn't work... Here are the results I
get:

SCCR[DFHL]:SCCR[DFNL]	| Results
(clock divisers)	|
________________________|_______________________

2x:2x			Works fine

1x:2x			Never wakes up

1x:64x			Kernel oopses
output: "Caused by (from SRR1=40001000): Transfer error ack signal"

SCCR[PRQEN] was '1' for all these tests.


Conn: could you give me the complete values of SCCR and PLPRCR registers?


Thanks again,


Pat Mahoney

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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

Hi Everyone,


	Patrick,

	I can give you what I have our SCCR and PLPRCR registers set to.
However I cannot guaranty it will work for your board.

Our board's SCCR is set to 0x2260000H
This corresponse to setting
COM = 01 to set clock output to half strength
TBS = 1  to set Timebase freq source to GCLK2 divided by 16
RTDIV = 0 clock is divided by 4
RTSEL = 0  OSCM is selected
CRQEN = 1 System switches to high speed clk durring CPM activity
PRQEN = 1 System switches Normal high on interrupt
EBDF = 00 CLKOUT is GCLK2 divided by 1
DFSYNC = 0 SYNCCLK divded by 1
DFBRG = 00 BRGCLK divide by 1
DFNL = 000 divide clk by 2
DFNH = 000 divide clk by 1

RES = 0 all reserved bits set to 0

in binary
RES |COM | RES | TBS | RTDIV | RTSEL | CRQEN | PRQEN | RES | EBDF | RES | DFSYNC |
DFBRG | DFNL | DFNH | RES
0   | 01 | 000 | 1   | 0     | 0     | 1     | 1     | 00  | 00   | 00  | 00     |
00    | 000  | 000  | 00000



Our board's PLPRCR is set to 0x0090X000 in Normal High Mode
This corresponse to setting
MF = 000000001001  multiply OSCCLK by 10
SPLSS, TEXPS, and TMIST are represented by X because they are status bits
CSRC = 0  sys clk generated by DFNH
LPM = 00 Normal High Mode
CSR = 0 No reset on checkstop
LOLRE = 0  No reset on Loss Of lock
FIOPD = 0  No pulldown on address and data busss during sleep

When put into Doze Low Mode it changes to 0X00900500
CSRC = 1 sys clock generated by DFNL
LPM = 01 Doze high/low mode




Patrick Mahoney wrote:
>
> Hello people,
>
> First of all, this might help some...
>
> HW: rpxlite_dw mpc850
> SW: linux 2.4 monta vista
>
> I cut my board's consumption by 800mW by
> 1) taking off the power leds (100mA)
> 2) bypassing the power regulator (700mA)
>
> I give 2 sources of current to the board: a 5V and a 3.3V, hence
> modelising an ideal regulator. Turns out that the board regulator has
> a 66% efficiency.
>
> > > Well the 2.4 Linux kernel does not support runtime modifications to
> > > the clock rate. So what's the point of playing with CSCR?
> >
> > If the CPU is dozing The kernel will never know we changed it as long as
> > we change it back when the CPU wakes up.
>
> I 100% agree with you... But it doesn't work... Here are the results I
> get:
>
> SCCR[DFHL]:SCCR[DFNL]   | Results
> (clock divisers)        |
> ________________________|_______________________
>
> 2x:2x                   Works fine
>
> 1x:2x                   Never wakes up
>
> 1x:64x                  Kernel oopses
> output: "Caused by (from SRR1=40001000): Transfer error ack signal"
>
> SCCR[PRQEN] was '1' for all these tests.
>
> Conn: could you give me the complete values of SCCR and PLPRCR registers?
>
> Thanks again,
>
> Pat Mahoney

I hope this helps

	Conn

--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


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

Re: mpc8xx - power save modes - PIT

[Conn Clark]

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

Cameron Rich wrote:
>
> Hi,
>
> I've been following this series of emails closely as we are interested in
> low power mode also.
>
> I've tried Conn's code, but I'm experiencing problems with PLPRCR[CSCR] as
> being 1 all the time after a rfi. I am also occasionally seeing MSR_POW set
> to 1 after the rfi return.

	An interrupt doesn't change the MSR_POW bit.So seeing the MSR_POW bit
set is to be expected. However there may be a problem with the PLPRCR[CSRC].
The MPC860 and MPC850 User's Manuals were vague on the subject of the
PLPRCR[CSRC] gets cleared by an interrupt if the SCCR[PRQEN] is set. I
contacted our motorola rep to ask about it and he said it was. I have not
checked it to be certain that this was true. On our system everything worked
beautifully so I assumed that this was so.


>
> I can work around this problem by setting PLPRCR[CSCR] = 0 and MSR_POW = 0
> after the rfi and this eventually works. But is this the solution? I'm also

I may be wrong about the PLPRCR[CSRC] bit being reset by an interrupt. It might
be necessary to clear the PLPRCR[CSRC] after a rfi.

I did have something that reset the MSR_POW bit but commented it out because I
didn't think it was needed.

I have attached a revised idle.c that makes certain that the PLPRCR[CSRC] gets
cleared.

> noticing no great decrease in power consumption even though I've only got a
> couple of (sleeping) processes. And it seems that there is (mostly) no time
> between entering Doze Low mode and the rfi which confirms the unsatisfactory
> power consumption figures.
>
> I have SCCR[CPQEN] (and SCCR[PRQEN]) set to 1.
>
> I'm using a PPC850 processor with Doze Low mode set. DFNL=DFNH=0 and I'm
> running 2.4.17 (with a RTAI patch).
>
> Cheers,
>
> Cameron
>

There may be something with the RTAI patch that generates alot of interrupts
or prevents or reduces the time the idle loop from running which would reduce
power savings. Setting the SCCR[DFNL] to a higher number will help.


--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


[-- Attachment #2: idle.c --]
[-- Type: text/plain, Size: 10334 bytes --]

/*
 * BK Id: SCCS/s.idle.c 1.20 03/19/02 15:04:39 benh
 */
/*
 * Idle daemon for PowerPC.  Idle daemon will handle any action
 * that needs to be taken when the system becomes idle.
 *
 * Written by Cort Dougan (cort@cs.nmt.edu)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version
 * 2 of the License, or (at your option) any later version.
 */
#include <linux/config.h>
#include <linux/errno.h>
#include <linux/sched.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/smp.h>
#include <linux/smp_lock.h>
#include <linux/stddef.h>
#include <linux/unistd.h>
#include <linux/ptrace.h>
#include <linux/slab.h>

#include <asm/pgtable.h>
#include <asm/uaccess.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/processor.h>
#include <asm/mmu.h>
#include <asm/cache.h>
#include <asm/cputable.h>


#define MPC8XX_POWERSAVE


#ifdef MPC8XX_POWERSAVE
#include <asm/mpc8xx.h>
#include <asm/8xx_immap.h>
#endif


void zero_paged(void);

#ifndef MPC8XX_POWERSAVE
void power_save(void);
#endif

unsigned long zero_paged_on = 0;
unsigned long powersave_nap = 0;

unsigned long *zero_cache;    /* head linked list of pre-zero'd pages */
atomic_t zerototal;      /* # pages zero'd over time */
atomic_t zeropage_hits;  /* # zero'd pages request that we've done */
atomic_t zero_sz;	      /* # currently pre-zero'd pages */
atomic_t zeropage_calls; /* # zero'd pages request that've been made */

int idled(void)
{
#ifdef MPC8XX_POWERSAVE
	int reg;
#else
	int do_power_save = 0;
	/* Check if CPU can powersave */
	if (cur_cpu_spec[smp_processor_id()]->cpu_features &
		(CPU_FTR_CAN_DOZE | CPU_FTR_CAN_NAP))
		do_power_save = 1;
#endif
	/* endless loop with no priority at all */
	current->nice = 20;
	current->counter = -100;
	init_idle();
	for (;;) {
#ifdef CONFIG_SMP
		if (!do_power_save) {
			/*
			 * Deal with another CPU just having chosen a thread to
			 * run here:
			 */
			int oldval = xchg(&current->need_resched, -1);

			if (!oldval) {
				while(current->need_resched == -1)
					; /* Do Nothing */
			}
		}
#endif

#ifdef MPC8XX_POWERSAVE
/*********************************************************

	IMPORTANT!!

if using doze modes make sure the SCCR[PRQEN] is set!

*********************************************************/



		while(!current->need_resched) {
			_nmask_and_or_msr( ( MSR_POW | MSR_EE ), 0);	/* disable interupts and Powersave Mode*/
			/* we disable interupts to avoid losing an interupt that should cause a wake up.
			Powersave Mode needs to be disabled to prevent entering Powersaving Mode right
			after PLPRCR is writen. We need to re-enable interupts first or we won't wake up */

			((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;	/*unlock PLPRCR register*/
			reg = ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr;  /*Read current PLPRCR*/
			((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg ; /* program PLPRCR */
			/* Reset the TMIST bit here or we might not (probaly won't) make it to Powersaving mode */
			reg &= 0xFFFFF8FF;		/*clear CSRC bit and the LPM bits*/
			((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;	/*unlock PLPRCR register*/
/*			reg |= 0x00000400; */		/*set just the CSRC bit placing in Normal Low Mode */
			/* Note Noramal Low Mode just keeps reprograming its self and has interupts blocked most
			of the time. Should not be much of a problem as long as DFNL is not set to divide clock
			by too much. This probably won't save very much power */
/*			reg |= 0x00000100; */		/*set LPM bits to 01 placing in Doze High Mode */
			reg |= 0x00000500;		/*set the CSRC bit and the LPM bits placing in Doze Low Mode*/
			((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr = reg;	/* program PLPRCR */
			_nmask_and_or_msr(0, MSR_POW | MSR_EE); /*re-enable interupts set into Powersave Mode*/
			/* processor should transition in to powersave mode as soon as MSR bits are set*/

			((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk = KAPWR_KEY;	/*unlock PLPRCR register*/
				/*clear CSRC bit to make certain we pop back into Normal High Mode */
			((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr &= 0xFFFFFBFF;

/*			_nmask_and_or_msr(MSR_POW,0);*/ /*dissable Powersave Mode (probably not needed)*/
		}
			schedule();
			check_pgt_cache();

#else

		if (do_power_save && !current->need_resched)
			power_save();

		if (current->need_resched) {
			schedule();
			check_pgt_cache();
		}
#endif
	}
	return 0;
}

/*
 * SMP entry into the idle task - calls the same thing as the
 * non-smp versions. -- Cort
 */
int cpu_idle(void)
{
	idled();
	return 0;
}

#if 0
/*
 * Returns a pre-zero'd page from the list otherwise returns
 * NULL.
 */
unsigned long get_zero_page_fast(void)
{
	unsigned long page = 0;

	atomic_inc(&zero_cache_calls);
	if ( zero_quicklist )
	{
		/* atomically remove this page from the list */
		register unsigned long tmp;
		asm (	"101:lwarx  %1,0,%3\n"  /* reserve zero_cache */
			"    lwz    %0,0(%1)\n" /* get next -- new zero_cache */
			"    stwcx. %0,0,%3\n"  /* update zero_cache */
			"    bne-   101b\n"     /* if lost reservation try again */
			: "=&r" (tmp), "=&r" (page), "+m" (zero_cache)
			: "r" (&zero_quicklist)
			: "cc" );
#ifdef CONFIG_SMP
		/* if another cpu beat us above this can happen -- Cort */
		if ( page == 0 )
			return 0;
#endif /* CONFIG_SMP */
		/* we can update zerocount after the fact since it is not
		 * used for anything but control of a loop which doesn't
		 * matter since it won't affect anything if it zeros one
		 * less page -- Cort
		 */
		atomic_inc((atomic_t *)&zero_cache_hits);
		atomic_dec((atomic_t *)&zero_cache_sz);

		/* zero out the pointer to next in the page */
		*(unsigned long *)page = 0;
		return page;
	}
	return 0;
}

/*
 * Experimental stuff to zero out pages in the idle task
 * to speed up get_free_pages(). Zero's out pages until
 * we've reached the limit of zero'd pages.  We handle
 * reschedule()'s in here so when we return we know we've
 * zero'd all we need to for now.
 */
int zero_cache_water[2] = { 25, 96 }; /* high and low water marks for zero cache */
void zero_paged(void)
{
	unsigned long pageptr = 0;	/* current page being zero'd */
	unsigned long bytecount = 0;
        register unsigned long tmp;
	pte_t *pte;

	if ( atomic_read(&zero_cache_sz) >= zero_cache_water[0] )
		return;
	while ( (atomic_read(&zero_cache_sz) < zero_cache_water[1]) && (!current->need_resched) )
	{
		/*
		 * Mark a page as reserved so we can mess with it
		 * If we're interrupted we keep this page and our place in it
		 * since we validly hold it and it's reserved for us.
		 */
		pageptr = __get_free_pages(GFP_ATOMIC, 0);
		if ( !pageptr )
			return;

		if ( current->need_resched )
			schedule();

		/*
		 * Make the page no cache so we don't blow our cache with 0's
		 */
		pte = find_pte(&init_mm, pageptr);
		if ( !pte )
		{
			printk("pte NULL in zero_paged()\n");
			return;
		}

		pte_uncache(*pte);
		flush_tlb_page(find_vma(&init_mm,pageptr),pageptr);
		/*
		 * Important here to not take time away from real processes.
		 */
		for ( bytecount = 0; bytecount < PAGE_SIZE ; bytecount += 4 )
		{
			if ( current->need_resched )
				schedule();
			*(unsigned long *)(bytecount + pageptr) = 0;
		}

		/*
		 * If we finished zero-ing out a page add this page to
		 * the zero_cache atomically -- we can't use
		 * down/up since we can't sleep in idle.
		 * Disabling interrupts is also a bad idea since we would
		 * steal time away from real processes.
		 * We can also have several zero_paged's running
		 * on different processors so we can't interfere with them.
		 * So we update the list atomically without locking it.
		 * -- Cort
		 */

		/* turn cache on for this page */
		pte_cache(*pte);
		flush_tlb_page(find_vma(&init_mm,pageptr),pageptr);
		/* atomically add this page to the list */
		asm (	"101:lwarx  %0,0,%2\n"  /* reserve zero_cache */
			"    stw    %0,0(%3)\n" /* update *pageptr */
#ifdef CONFIG_SMP
			"    sync\n"            /* let store settle */
#endif
			"    stwcx. %3,0,%2\n"  /* update zero_cache in mem */
			"    bne-   101b\n"     /* if lost reservation try again */
			: "=&r" (tmp), "+m" (zero_quicklist)
			: "r" (&zero_quicklist), "r" (pageptr)
			: "cc" );
		/*
		 * This variable is used in the above loop and nowhere
		 * else so the worst that could happen is we would
		 * zero out one more or one less page than we want
		 * per processor on the machine.  This is because
		 * we could add our page to the list but not have
		 * zerocount updated yet when another processor
		 * reads it.  -- Cort
		 */
		atomic_inc((atomic_t *)&zero_cache_sz);
		atomic_inc((atomic_t *)&zero_cache_total);
	}
}
#endif /* 0 */

#ifndef MPC8XX_POWERSAVE
#define DSSALL		.long	(0x1f<<26)+(0x10<<21)+(0x336<<1)

void power_save(void)
{
	unsigned long hid0;
	int nap = powersave_nap;

	/* 7450 has no DOZE mode mode, we return if powersave_nap
	 * isn't enabled
	 */
	if (!(nap || (cur_cpu_spec[smp_processor_id()]->cpu_features & CPU_FTR_CAN_DOZE)))
		return;
	/*
	 * Disable interrupts to prevent a lost wakeup
	 * when going to sleep.  This is necessary even with
	 * RTLinux since we are not guaranteed an interrupt
	 * didn't come in and is waiting for a __sti() before
	 * emulating one.  This way, we really do hard disable.
	 *
	 * We assume that we're sti-ed when we come in here.  We
	 * are in the idle loop so if we're cli-ed then it's a bug
	 * anyway.
	 *  -- Cort
	 */
	_nmask_and_or_msr(MSR_EE, 0);
	if (!current->need_resched)
	{
		__asm__ __volatile__("mfspr %0,1008" : "=r" (hid0) :);
		hid0 &= ~(HID0_NAP | HID0_SLEEP | HID0_DOZE);
		hid0 |= (powersave_nap? HID0_NAP: HID0_DOZE) | HID0_DPM;
		__asm__ __volatile__("mtspr 1008,%0" : : "r" (hid0));
		/* Flush pending data streams, consider this instruction
		 * exist on all altivec capable CPUs
		 */
		__asm__ __volatile__(
			"98:	" stringify(DSSALL) "\n"
			"	sync\n"
			"99:\n"
			".section __ftr_fixup,\"a\"\n"
			"	.long %0\n"
			"	.long %1\n"
			"	.long 98b\n"
			"	.long 99b\n"
			".previous" : : "i" (CPU_FTR_ALTIVEC), "i" (CPU_FTR_ALTIVEC));

		/* set the POW bit in the MSR, and enable interrupts
		 * so we wake up sometime! */
		_nmask_and_or_msr(0, MSR_POW | MSR_EE);
	}
	_nmask_and_or_msr(0, MSR_EE);
}
#endif