Cannot wake-up from standby with MPC8313

Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

after entering:

echo standby > /sys/power/state

I'm unable to wake up the MPC8313 (on our custom designed
MPC8313 board).

I need it to wake up through GPIO IRQ.
I cause multiple GPIO interrupts (all properly handled by an isr),
but the MPC8313 does not wake up.

How should one wake up via GPGIO IRQ ?

I'm using v2.6.29 and I wonder whether this is related to
our custom 8313 board and/or v2.6.29 and/or missing kernel
patches or maybe this never worked ?

Also, I do not understand line 220 of arch/powerpc/platforms/83xx/suspend.c

219         } else {
220                 out_be32(&pmc_regs->mask, PMCER_PMCI);
221
222                 mpc6xx_enter_standby();

How can wake up ever work if TSEC/GPIO/TIMER/etc.. wake up events
are disabled ?

changing this into "out_be32(&pmc_regs->mask, PMCER_PMCI|PMCER_GPIO);"
gives same result.

MPC8313 is in PCI HOST mode and here's a relevant part
of the DTS:

         pmc: power@b00 {
             compatible = "fsl,mpc8313-pmc", "fsl,mpc8349-pmc";
             reg = <0xb00 0x100 0xa00 0x100>;
             interrupts = <80 8>;
             interrupt-parent = <&ipic>;
             fsl,mpc8313-wakeup-timer = <&gtm1>;

             /* Remove this (or change to "okay") if you have
              * a REVA3 or later board, if you apply one of the
              * workarounds listed in section 8.5 of the board
              * manual, o if you are adapting this device treeSE=
              * to a different board.
              */
             status = "okay";
         };

         gtm1: timer@500 {
             compatible = "fsl,mpc8313-gtm", "fsl,gtm";
             reg = <0x500 0x100>;
             interrupts = <90 8 78 8 84 8 72 8>;
             interrupt-parent = <&ipic>;
         };


Any help/advice/answer is more than welcome.

---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/04/2012 10:19 AM, Norbert van Bolhuis wrote:
> 
> after entering:
> 
> echo standby > /sys/power/state
> 
> I'm unable to wake up the MPC8313 (on our custom designed
> MPC8313 board).
> 
> I need it to wake up through GPIO IRQ.
> I cause multiple GPIO interrupts (all properly handled by an isr),
> but the MPC8313 does not wake up.
> 
> How should one wake up via GPGIO IRQ ?
> 
> I'm using v2.6.29 and I wonder whether this is related to
> our custom 8313 board and/or v2.6.29 and/or missing kernel
> patches or maybe this never worked ?
> 
> Also, I do not understand line 220 of arch/powerpc/platforms/83xx/suspend.c
> 
> 219         } else {
> 220                 out_be32(&pmc_regs->mask, PMCER_PMCI);
> 221
> 222                 mpc6xx_enter_standby();
> 
> How can wake up ever work if TSEC/GPIO/TIMER/etc.. wake up events
> are disabled ?
> 
> changing this into "out_be32(&pmc_regs->mask, PMCER_PMCI|PMCER_GPIO);"
> gives same result.

It's been a while since I've touched this, but IIRC the PMC events are
mainly important for deep sleep, and for normal sleep (standby) you can
wake from any interrupt other than core interrupts like timebase.  I'm
not sure to what extent setting PMCCR[SLPEN] affects this -- I don't see
where the documentation says what "system low power state" means.  I
would be surprised if GPIO were affected, though, since it's supported
as a wakeup source even in deep sleep.  I think I was able to wake from
standby on a UART interrupt even with SLPEN set.

Are you sure the GPIO block is asserting an interrupt, and that it
hasn't been masked during the preparation for standby?

What happens if you modify mpc6xx_enter_standby() to not actually set
MSR_POW?

-Scott

Re: Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/04/12 22:08, Scott Wood wrote:

...

> It's been a while since I've touched this, but IIRC the PMC events are
> mainly important for deep sleep, and for normal sleep (standby) you can
> wake from any interrupt other than core interrupts like timebase.  I'm
> not sure to what extent setting PMCCR[SLPEN] affects this -- I don't see
> where the documentation says what "system low power state" means.  I
> would be surprised if GPIO were affected, though, since it's supported
> as a wakeup source even in deep sleep.  I think I was able to wake from
> standby on a UART interrupt even with SLPEN set.
>
> Are you sure the GPIO block is asserting an interrupt, and that it
> hasn't been masked during the preparation for standby?
>
> What happens if you modify mpc6xx_enter_standby() to not actually set
> MSR_POW?
>


thanks for your response.

not setting MSR_POW gives same result.

if I set kernel.powersave-nap=1 it works fine, so apparently
NAP/DOZE mode does work (if CPU is idle). This saves almost no
power though. Standby mode saves about 300-500 mW.

The problem could well be our board though, today I learned it does
work by connecting an (inactive) JTAG debugger.
Also, on another board it always works.

And indeed wake-up occurs through GPIO interrupt or UART interrupt
(key press on console).


---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
> thanks for your response.
> 
> not setting MSR_POW gives same result.

OK, so you're not getting an interrupt regardless of low-power state.

Check whether the interrupt is getting masked during standby preparation.

Does the interrupt handler run when you're not trying to enter standby?

> if I set kernel.powersave-nap=1 it works fine,

What is "it"?  Do you mean that powersave-nap doesn't break things, or
that standby works when you specify that?

> so apparently NAP/DOZE mode does work (if CPU is idle). This saves almost no
> power though. Standby mode saves about 300-500 mW.
> 
> The problem could well be our board though, today I learned it does
> work by connecting an (inactive) JTAG debugger.
> Also, on another board it always works.

You mean connecting a JTAG but not doing anything with it made
wake-from-standby work?

There was a bug like that on early revisions of the mpc8313erdb board --
though in that case if you had a bad board the system would hang
whenever you access any PMC register.  I'm not sure what the mechanism
of failure was; IIRC the fix was adding a resistor.

-Scott

Re: Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/05/12 19:22, Scott Wood wrote:
> On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
>> thanks for your response.
>>
>> not setting MSR_POW gives same result.
>
> OK, so you're not getting an interrupt regardless of low-power state.
>
> Check whether the interrupt is getting masked during standby preparation.
>
> Does the interrupt handler run when you're not trying to enter standby?
>


The GPIO/UART interrupt nor the PMC interrupt are being masked during standby
preperation.
The GPIO/UART interrupt works fine in "operational" mode.
The PMC interrupt I do not know, is it possible to to get PMC interrupt
without going to standby or deep-sleep ?
In anyway there is no PMC interrupt for NAP mode (if kernel.powersave-nap=1).


>> if I set kernel.powersave-nap=1 it works fine,
>
> What is "it"?  Do you mean that powersave-nap doesn't break things, or
> that standby works when you specify that?
>


I mean powersave-nap itself seems to work and does not break things.


>> so apparently NAP/DOZE mode does work (if CPU is idle). This saves almost no
>> power though. Standby mode saves about 300-500 mW.
>>
>> The problem could well be our board though, today I learned it does
>> work by connecting an (inactive) JTAG debugger.
>> Also, on another board it always works.
>
> You mean connecting a JTAG but not doing anything with it made
> wake-from-standby work?
>
> There was a bug like that on early revisions of the mpc8313erdb board --
> though in that case if you had a bad board the system would hang
> whenever you access any PMC register.  I'm not sure what the mechanism
> of failure was; IIRC the fix was adding a resistor.
>


yes, connecting a JTAG but not doing anything with it makes
wake-from-standby work.

I don't know what's wrong with (some of) our boards... it looks
like external interrupts are blocked and/or core stays in reset..

I doubt there's a SW PMC race/deadlock that causes this.


---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote:
> On 01/05/12 19:22, Scott Wood wrote:
>> On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
>>> thanks for your response.
>>>
>>> not setting MSR_POW gives same result.
>>
>> OK, so you're not getting an interrupt regardless of low-power state.
>>
>> Check whether the interrupt is getting masked during standby preparation.
>>
>> Does the interrupt handler run when you're not trying to enter standby?
>>
> 
> 
> The GPIO/UART interrupt nor the PMC interrupt are being masked during
> standby
> preperation.
> The GPIO/UART interrupt works fine in "operational" mode.
> The PMC interrupt I do not know, is it possible to to get PMC interrupt
> without going to standby or deep-sleep ?

The PMC interrupt is mainly of interest when running as a PCI agent, to
be notified when the host changed the desired suspend state in config space.

What changes from operational mode to the test where you omit setting
MSR_POW?

Try dumping SIPNR/SIMSR and GPIER/GPIMR/GPDAT at various points.

-Scott

Re: Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/06/12 22:03, Scott Wood wrote:
 > On 01/06/2012 07:53 AM, Norbert van Bolhuis wrote:
 >> On 01/05/12 19:22, Scott Wood wrote:
 >>> On 01/05/2012 09:58 AM, Norbert van Bolhuis wrote:
 >>>> thanks for your response.
 >>>>
 >>>> not setting MSR_POW gives same result.
 >>>
 >>> OK, so you're not getting an interrupt regardless of low-power state.
 >>>
 >>> Check whether the interrupt is getting masked during standby preparation.
 >>>
 >>> Does the interrupt handler run when you're not trying to enter standby?
 >>>
 >>
 >>
 >> The GPIO/UART interrupt nor the PMC interrupt are being masked during
 >> standby
 >> preperation.
 >> The GPIO/UART interrupt works fine in "operational" mode.
 >> The PMC interrupt I do not know, is it possible to to get PMC interrupt
 >> without going to standby or deep-sleep ?
 >
 > The PMC interrupt is mainly of interest when running as a PCI agent, to
 > be notified when the host changed the desired suspend state in config space.
 >
 > What changes from operational mode to the test where you omit setting
 > MSR_POW?
 >
 > Try dumping SIPNR/SIMSR and GPIER/GPIMR/GPDAT at various points.
 >


I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
but they do not change just before entering standby (via mpc6xx_enter_standby
which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
not pending.

I tried to log to physical memory to see what's going on whenever the
board fails to wake-up.
(I can examine physical memory after CPU is stuck in sleep, by connecting
  a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
  re-configured)

It looks like an interupt does occur, but do_IRQ seems to be stuck
in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.

I have no idea why, any more suggestions ?


---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
> but they do not change just before entering standby (via
> mpc6xx_enter_standby
> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
> not pending.
> 
> I tried to log to physical memory to see what's going on whenever the
> board fails to wake-up.
> (I can examine physical memory after CPU is stuck in sleep, by connecting
>  a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
>  re-configured)

Are you sure this isn't going to disturb anything?  Why does U-Boot need
to be involved, and the SDRAM reconfigured?

> It looks like an interupt does occur, but do_IRQ seems to be stuck
> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.

Stuck as in the load never completes, or as in ipic_get_irq() gets
called repeatedly?  If the latter, what value is it reading out?  Is the
interrupt pending in SIPNR at this point?

-Scott

Re: Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/16/12 21:22, Scott Wood wrote:
> On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
>> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
>> but they do not change just before entering standby (via
>> mpc6xx_enter_standby
>> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
>> not pending.
>>
>> I tried to log to physical memory to see what's going on whenever the
>> board fails to wake-up.
>> (I can examine physical memory after CPU is stuck in sleep, by connecting
>>   a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
>>   re-configured)
>
> Are you sure this isn't going to disturb anything?  Why does U-Boot need
> to be involved, and the SDRAM reconfigured?
>


If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM ctrl.
SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
survive such a soft-reset.


>> It looks like an interupt does occur, but do_IRQ seems to be stuck
>> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
>
> Stuck as in the load never completes, or as in ipic_get_irq() gets
> called repeatedly?  If the latter, what value is it reading out?  Is the
> interrupt pending in SIPNR at this point?
>


I think I was wrong. I enabled tracing do_IRQ just a little bit too soon
(in suspend_enter). The interrupt I saw was probably one that occured
just before CPU entered sleep (mpc6xx_enter_standby).

Right now I see no external interrupt happening, so that brings us back
where we were before: I'm not getting an interrupt regardless of low-power state.
So now my main question is: how can JTAG and/or any other external signal
cause this ?

Another weird thing I noticed is that whenever I dump CPU memmap
(which starts at 0xe0000000) under linux it always crashes with a "check stop"
when it is displaying somewhere at 0xe0000800-0xe0001000
If I connect our JTAG debugger it never crashes and dumping CPU memmap
always works.


---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/17/2012 10:56 AM, Norbert van Bolhuis wrote:
> On 01/16/12 21:22, Scott Wood wrote:
>> On 01/13/2012 08:13 AM, Norbert van Bolhuis wrote:
>>> I dumped SIPNR/SIMSR and uart IIR/EIR (since console triggers wake-up)
>>> but they do not change just before entering standby (via
>>> mpc6xx_enter_standby
>>> which omits setting MSR_POW). uart IRQ is always enabled, unmasked and
>>> not pending.
>>>
>>> I tried to log to physical memory to see what's going on whenever the
>>> board fails to wake-up.
>>> (I can examine physical memory after CPU is stuck in sleep, by
>>> connecting
>>>   a JTAG debugger, start u-boot and stop after DDR2 SDRAM ctrl is
>>>   re-configured)
>>
>> Are you sure this isn't going to disturb anything?  Why does U-Boot need
>> to be involved, and the SDRAM reconfigured?
>>
> 
> 
> If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
> which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM
> ctrl.

Why is a reset needed in order to examine physical memory?

> SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
> survive such a soft-reset.

And all register and device state is as Linux left it?

>>> It looks like an interupt does occur, but do_IRQ seems to be stuck
>>> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
>>
>> Stuck as in the load never completes, or as in ipic_get_irq() gets
>> called repeatedly?  If the latter, what value is it reading out?  Is the
>> interrupt pending in SIPNR at this point?
>>
> 
> 
> I think I was wrong. I enabled tracing do_IRQ just a little bit too soon
> (in suspend_enter). The interrupt I saw was probably one that occured
> just before CPU entered sleep (mpc6xx_enter_standby).
> 
> Right now I see no external interrupt happening, so that brings us back
> where we were before: I'm not getting an interrupt regardless of
> low-power state.
> So now my main question is: how can JTAG and/or any other external signal
> cause this ?

I can't help you with the hardware side of it, other than to say that it
sounds similar to an issue we had on early revs of mpc8313erdb.  Could
you make sure that TRST (JTAG Test Reset) is not being asserted except
while PORESET is asserted?

If that's not it, I'm wondering what the relevant difference is on the
software side to differentiate the case where you go through all the
motions but don't set MSR[POW] from the case where you don't try to
suspend at all (just take the interrupt during normal execution).  Are
you sure that you're making it to mpc6xx_enter_standby, and that it's
not hanging on a PMC register access?

> Another weird thing I noticed is that whenever I dump CPU memmap
> (which starts at 0xe0000000) under linux it always crashes with a "check
> stop"
> when it is displaying somewhere at 0xe0000800-0xe0001000
> If I connect our JTAG debugger it never crashes and dumping CPU memmap
> always works.

Is it 0xe0000bXX?  A hang when accessing the PMC registers is what I saw
with the mpc8313erdb bug.

-Scott

Re: Cannot wake-up from standby with MPC8313

[Norbert van Bolhuis]

On 01/17/12 23:09, Scott Wood wrote:

...

>>
>> If CPU is stuck in sleep, JTAG will send HRESET or SRESET (i'm nor sure
>> which one it is) and u-boot is needed to reconfigure CPU and DDR2 SDRAM
>> ctrl.
>
> Why is a reset needed in order to examine physical memory?
>


Because CPU is stuck in sleep and I use the CPU to dump the physical memory
(which contains the log entries made just before CPU got stuck).


>> SDRAM contents (for physical memory "unknown" to u-boot and linux) seems to
>> survive such a soft-reset.
>
> And all register and device state is as Linux left it?
>


Probably not, but at least the physical memory contents seems to survive
the soft-reset.


>>>> It looks like an interupt does occur, but do_IRQ seems to be stuck
>>>> in ppc_md.get_irq=ipic_get_irq where it reads SIVCR.
>>>
>>> Stuck as in the load never completes, or as in ipic_get_irq() gets
>>> called repeatedly?  If the latter, what value is it reading out?  Is the
>>> interrupt pending in SIPNR at this point?
>>>
>>
>>
>> I think I was wrong. I enabled tracing do_IRQ just a little bit too soon
>> (in suspend_enter). The interrupt I saw was probably one that occured
>> just before CPU entered sleep (mpc6xx_enter_standby).
>>
>> Right now I see no external interrupt happening, so that brings us back
>> where we were before: I'm not getting an interrupt regardless of
>> low-power state.
>> So now my main question is: how can JTAG and/or any other external signal
>> cause this ?
>
> I can't help you with the hardware side of it, other than to say that it
> sounds similar to an issue we had on early revs of mpc8313erdb.  Could
> you make sure that TRST (JTAG Test Reset) is not being asserted except
> while PORESET is asserted?
>
> If that's not it, I'm wondering what the relevant difference is on the
> software side to differentiate the case where you go through all the
> motions but don't set MSR[POW] from the case where you don't try to
> suspend at all (just take the interrupt during normal execution).  Are
> you sure that you're making it to mpc6xx_enter_standby, and that it's
> not hanging on a PMC register access?
>
>> Another weird thing I noticed is that whenever I dump CPU memmap
>> (which starts at 0xe0000000) under linux it always crashes with a "check
>> stop"
>> when it is displaying somewhere at 0xe0000800-0xe0001000
>> If I connect our JTAG debugger it never crashes and dumping CPU memmap
>> always works.
>
> Is it 0xe0000bXX?  A hang when accessing the PMC registers is what I saw
> with the mpc8313erdb bug.
>
> -Scott
>
>

Yes this is it!
You mentioned mpc8313erdb bug before, I guess you had to mention it twice before
I looked at mpc8313erdb bug description.

The mpc8313erdb bug is described as follows:

3.5 Power management control (PMC) registers cannot be
accessed?
The PMC registers range from IMMR + 0x0B00 to IMMR + 0x0BFF. When this
area is accessed in u-boot,
the RDB hangs up. It appears that the PMC block is related to the JTAG
interface; TRST must not be pulled
down for normal operation of the PMC block. Possible workarounds are as
follows:
• Attach a debugger to drive TRST high during normal operation.
• Remove the pull-down resistor (R37) for TRST. Although this tested on
some RDBs without any
problem, it violates the hardware specification. If it does not work on
your RDB, use another workaround.


I guess this is an MPC8313 problem rather than an MPC8313E-RDB problem ?
and I would expect it to be mentioned in MPC8313E Errata (which isn't the
case).

Anyway, thanks a lot for all help!

---
NvBolhuis

Re: Cannot wake-up from standby with MPC8313

[Scott Wood]

On 01/18/2012 04:16 AM, Norbert van Bolhuis wrote:
> Yes this is it!
> You mentioned mpc8313erdb bug before, I guess you had to mention it
> twice before
> I looked at mpc8313erdb bug description.
>=20
> The mpc8313erdb bug is described as follows:
>=20
> 3.5 Power management control (PMC) registers cannot be
> accessed?
> The PMC registers range from IMMR + 0x0B00 to IMMR + 0x0BFF. When this
> area is accessed in u-boot,
> the RDB hangs up. It appears that the PMC block is related to the JTAG
> interface; TRST must not be pulled
> down for normal operation of the PMC block. Possible workarounds are as
> follows:
> =95 Attach a debugger to drive TRST high during normal operation.
> =95 Remove the pull-down resistor (R37) for TRST. Although this tested =
on
> some RDBs without any
> problem, it violates the hardware specification. If it does not work on
> your RDB, use another workaround.
>=20
>=20
> I guess this is an MPC8313 problem rather than an MPC8313E-RDB problem =
?
> and I would expect it to be mentioned in MPC8313E Errata (which isn't t=
he
> case).

It is mentioned in the MPC8313E manual (4.2.2 step #10) that TRST must
not be asserted except when PORESET is asserted.  The mpc8313erdb bug
was that the board was not complying with this.

-Scott

Re: Cannot wake-up from standby with MPC8313

[ehodys]

Hello al,

I am newbie about porting Linux on a ADS512101 Dev tool and I don't  
know how to put the video display at work. The only thing that works  
is the serial interface and I find no information to switch to the LCD  
display.

Can some one help me please, thank you.

Best regards

Edgar

Cannot wake-up from standby with MPC8313

[nvbolhuis]

>
> It is mentioned in the MPC8313E manual (4.2.2 step #10) that TRST must
> not be asserted except when PORESET is asserted.  The mpc8313erdb bug
> was that the board was not complying with this.
>

ok, I see.

The board did not comply to the spec and as a side-effect PMC
registers could not be accessed.

Thanks again for all help!

---
NvBolhuis