mpc8xx - power save modes - PIT
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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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/
mpc8xx - power save modes - PIT
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 0x226H 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 | 0 Our board's PLPRCR is set to 0x0090X000 in Normal High Mode This corresponse to setting MF = 1001 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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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:[EMAIL PROTECTED]
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 &= 0xF8FF;
> ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk =
KAPWR_KEY;
> reg |= 0x0100;
> ((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,
> > }
> > #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
mpc8xx - power save modes - PIT
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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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/
mpc8xx - power save modes - PIT
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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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 at esteem.com
Electronic Systems Technology Inc. www.esteem.com
-- next part --
/*
* 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 at 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
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MPC8XX_POWERSAVE
#ifdef MPC8XX_POWERSAVE
#include
#include
#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(¤t->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 P
mpc8xx - power save modes - PIT
> 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/
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 &= 0xF8FF;
> ((immap_t *)IMAP_ADDR)->im_clkrstk.cark_plprcrk =
> KAPWR_KEY;
> reg |= 0x0100;
> ((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,
> > }
> > #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 at esteem.com
Electronic Systems Technology Inc. www.esteem.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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/
mpc8xx - power save modes - PIT
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 |= 0x0400 // 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/
mpc8xx - power save modes - PIT
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: 4038 XER: 2000 LR: 0002B91C SP: C0143F30 REGS: c0143e80 TRAP: 0200Not tainted MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 TASK = c0141fa0[0] 'swapper' Last syscall: 120 last math last altivec GPR00: C0143F30 C0141FA0 00048000 0001 FC18 GPR08: 0100 C015F00C C014DBFF C014DCEE 000D FA202210 GPR16: 42004022 00EA5F40 C0004654 GPR24: FA20 743D2F62 C016 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... 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/
mpc8xx - power save modes - PIT
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... H. > > 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: 4038 XER: 2000 LR: 0002B91C SP: C0143F30 REGS: c0143e80 > TRAP: 0200Not tainted > MSR: 1000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00 > TASK = c0141fa0[0] 'swapper' Last syscall: 120 > last math last altivec > GPR00: C0143F30 C0141FA0 00048000 0001 > FC18 > GPR08: 0100 C015F00C C014DBFF C014DCEE 000D FA202210 > > GPR16: 42004022 00EA5F40 > C0004654 > GPR24: FA20 743D2F62 C016 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... > > > > 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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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:[EMAIL PROTECTED] 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 at 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 at 8d.com] > > > Sent: Thursday, October 10, 2002 2:35 PM > > > To: linuxppc-embedded at 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/
mpc8xx - power save modes - PIT
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/
mpc8xx - power save modes - PIT
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 at esteem.com Electronic Systems Technology Inc. www.esteem.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
mpc8xx - power save modes - PIT
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 at esteem.com
Electronic Systems Technology Inc. www.esteem.com
-- next part --
/*
* 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 at 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
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MPC8XX_POWERSAVE
#ifdef MPC8XX_POWERSAVE
#include
#include
#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(¤t->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*
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/
