* Andrew F. Davis <afd@xxxxxx> [170217 12:28]: > On 02/17/2017 09:55 AM, Tony Lindgren wrote: > > * Tony Lindgren <tony@xxxxxxxxxxx> [170216 11:08]: > >> * Tony Lindgren <tony@xxxxxxxxxxx> [170216 08:55]: > >>> For your use case, probably all we need is runtime checks for HS in > >>> addition to parking cpu1 for kexec. If that's not enough, then maybe > >>> a device specific DT property for never-reset-no-matter-what. > >> > >> Below is a first take on the last resort cpu1 reset done based on > >> configured CPU1_WAKEUP_NS_PA_ADDR_OFFSET for omap4 and 5. Note that > >> we can't merge it yet as it will break kexec boot for dra7. To fix that, > >> we need to first do what you're suggesting and properly park cpu1 for > >> kexec. > > > > Something like the patch below might be doable for the first fix > > before we have something to park cpu1 for kexec. I've added more checks > > to attemp to detect cpu1 being in WFI. At least things keep on working > > for kexec on omap4/5 and GP dra7. > > > > Andrew, care to give it a try and see if can add some HS dra7 checks > > there too to have kexec work on it? Basically we want to attempt to > > detect if there's a chance cpu1 is in WFI, and if I think the only > > optino is to reset it before bringing it up as otherwise outcome will > > be unpredictable. > > > > This patch seems stop the reset issue on my boards, so as long as it is > just a temporary workaround until we can fix the real issue (a core that > should be off going into omap_do_wfi() instead of parking), then this > patch works for me. OK > > + > > + /* REVISIT: Anything to check for HS dra7? */ > > + if (soc_is_dra74x() && omap_secure_apis_support()) > > + return; > > omap_secure_apis_support() only returns true when cpu_is_omap44xx() is > true, so this will never be true. Someday we may add the secure APIs to > secure DRA7xx devices, but I don't know of a good way to detect this > from kernel right now. OK so that can be removed. Can you check what happens with suspend/resume cycle? Based on what I've seen omap5 and dra7 currently always hit the "smp_ops.cpu_die() returned, trying to resuscitate" on resume meaning it will get sent to secondary_start_kernel on resume. Regards, Tony -- 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
