On Wed, 2012-05-16 at 17:31 -0700, Kevin Hilman wrote:
> Tero Kristo <t-kri...@ti.com> writes:
> 
> > If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back
> > to off. 
> 
> Why is it waking up then?  (I know the answer, but will forget.  The
> changelog serves as my long-term memory.)

Will add comment. (Both cpus will wake-up after device-off reset.)

> 
> > This is needed during wakeup from device off to prevent cpu1
> > from being stuck indefinitely in the wakeup loop 
> 
> Why does it get stuck?

Related to the above, if the AUX_CORE_BOOT0 is not set, the code will
wait for it indefinitely in busy loop.

> 
> > and also to prevent wakeup problem on GP chips with device off mode.
> 
> What wakeup problem?

This is apparently related to the GIC restore issue addressed with patch
3/8 of the core-ret set (workaround for the ROM bug because of CA9 r2pX
gic register change), the interrupts get disabled. Maybe Santosh has
some comments on this one.
> 
> > Signed-off-by: Tero Kristo <t-kri...@ti.com>
> 
> Assembly code should have some comments to aid comprehension.

Will add.

> 
> 
> > ---
> >  arch/arm/mach-omap2/omap-headsmp.S |   45 
> > ++++++++++++++++++++++++++++++++---
> >  1 files changed, 41 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/omap-headsmp.S 
> > b/arch/arm/mach-omap2/omap-headsmp.S
> > index d602555..59c6578 100644
> > --- a/arch/arm/mach-omap2/omap-headsmp.S
> > +++ b/arch/arm/mach-omap2/omap-headsmp.S
> > @@ -17,8 +17,37 @@
> >  
> >  #include <linux/linkage.h>
> >  #include <linux/init.h>
> > +#include <mach/omap-secure.h>
> > +#include "prcm_mpu44xx.h"
> > +
> > +#define CPU1_PWRSTCTRL (OMAP4430_PRCM_MPU_BASE + 
> > OMAP4430_PRCM_MPU_CPU1_INST + \
> > +                   OMAP4_PM_CPU1_PWRSTCTRL_OFFSET)
> >  
> >     __CPUINIT
> > +
> > +ENTRY(omap_cpu1_off)
> > +   ldr     r12, =CPU1_PWRSTCTRL
> > +   ldr     r0, [r12]
> > +   and     r0, #3
> > +   cmp     r0, #2
> > +   beq     exit_cpu1_off
> > +
> > +   mov     r0, #0x3
> > +   mov     r1, #0x0
> > +   ldr     r12, =OMAP4_MON_SCU_PWR_INDEX
> 
> Help!  no comments.
> 
> > +   dsb
> > +   smc     #0
> 
> The DO_SMC in sleep44xx.S suggests there should be another dsb here.

Not sure if that is needed here as we have multiple barriers following
this, but I'll add it just to be sure.

> 
> > +   isb
> > +   dsb
> > +   dmb
> > +   wfi
> > +   nop
> > +   nop
> 
> Shoudln't this use omap_do_wfi?

Can't, as we don't have stack yet at this point, and omap_do_wfi
attempts to push stuff into stack.

-Tero

> 
> Kevin
> 
> > +exit_cpu1_off:
> > +   mov     pc, lr
> > +ENDPROC(omap_cpu1_off)
> > +
> >  /*
> >   * OMAP4 specific entry point for secondary CPU to jump from ROM
> >   * code.  This routine also provides a holding flag into which
> > @@ -27,32 +56,40 @@
> >   * register AuxCoreBoot0.
> >   */
> >  ENTRY(omap_secondary_startup)
> > -hold:      ldr     r12,=0x103
> > +   ldr     r12,=0x103
> >     dsb
> >     smc     #0                      @ read from AuxCoreBoot0
> >     mov     r0, r0, lsr #9
> >     mrc     p15, 0, r4, c0, c0, 5
> >     and     r4, r4, #0x0f
> >     cmp     r0, r4
> > -   bne     hold
> > +   beq     omap_cont_boot
> > +
> > +   bl      omap_cpu1_off
> > +   b       omap_secondary_startup
> >  
> >     /*
> >      * we've been released from the wait loop,secondary_stack
> >      * should now contain the SVC stack for this core
> >      */
> > +omap_cont_boot:
> >     b       secondary_startup
> >  ENDPROC(omap_secondary_startup)
> >  
> >  ENTRY(omap_secondary_startup_4460)
> > -hold_2:    ldr     r12,=0x103
> > +   ldr     r12,=0x103
> >     dsb
> >     smc     #0                      @ read from AuxCoreBoot0
> >     mov     r0, r0, lsr #9
> >     mrc     p15, 0, r4, c0, c0, 5
> >     and     r4, r4, #0x0f
> >     cmp     r0, r4
> > -   bne     hold_2
> > +   beq     omap4460_cont_boot
> > +
> > +   bl      omap_cpu1_off
> > +   b       omap_secondary_startup_4460
> >  
> > +omap4460_cont_boot:
> >     /*
> >      * GIC distributor control register has changed between
> >      * CortexA9 r1pX and r2pX. The Control Register secure


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to