"Shilimkar, Santosh" <santosh.shilim...@ti.com> writes: > Tero, > > On Mon, May 21, 2012 at 3:51 PM, Tero Kristo <t-kri...@ti.com> wrote: >> 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. >>> > 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.
That's a nice description of the problem. Please incorporate a summary like this into the changlog to describe the problem, then describe the solution. Thanks, Kevin > I think the limitation is applicable to all OMAP4 devices as well as OMAP5 > devices. -- 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
