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. [...] > + > + /* 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. Andrew -- 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
