Tero, On Mon, May 21, 2012 at 3:51 PM, Tero Kristo <t-kristo@xxxxxx> wrote: > On Wed, 2012-05-16 at 17:31 -0700, Kevin Hilman wrote: >> Tero Kristo <t-kristo@xxxxxx> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
