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:

quoted

Patrick Mahoney wrote:

quoted

Hello pple,

<snip>

quoted

}
#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/

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/