Tero,

On Mon, May 21, 2012 at 3:51 PM, Tero Kristo [off-list ref] wrote:

On Wed, 2012-05-16 at 17:31 -0700, Kevin Hilman wrote:

quoted

Tero Kristo [off-list ref] writes:

quoted

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.)

quoted

quoted

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.

quoted

quoted

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.

quoted

Not sure what you mean wakeup issue on GP device.

IIUC, the issue is:
Wakeup from device OFF, hardware releases the reset for both CPUs,
This is special case and applicable only for device OFF. The reason
CPU1 needs to be hold back, because the security SW is affined with
CPU0 which needs to be up and running for any of the ROM code APIs
to work. Like setting up SMP bit, AUX control etc. Without CPU0 booted,
CPU1 won't be able to execute those ROM functions and hence won't be
able to boot properly.

I think the limitation is applicable to all OMAP4 devices as well as OMAP5
devices.

Regards
Santosh