* Andrew F. Davis <afd@xxxxxx> [170317 09:28]: > On 03/17/2017 08:57 AM, Tony Lindgren wrote: > > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [170317 02:27]: > >> Why can't you reset the CPU when it's died, possibly releasing the > >> reset again to get it into the boot rom (which is where it'll be at > >> boot time.) > > > > Yes that would make most sense to me. Andrew, does that break your use > > case again for CPU1 for suspend/restore? > > > > We cannot reset the CPU, that is the only constraint I have. If you let > a core go awol then it is lost for good, you should try to avoid that. > The secure side on that core may still be running just fine, and may be > performing very important tasks, resetting the whole core because the > non-secure side lost control of its side is not okay. For suspend/resume, I think the right solution is to put dra7 CPU1 into retention instead trying to put it into off which will fail. This should fix the "smp_ops.cpu_die() returned, trying to resuscitate" issue. And then there is no need to repark CPU1 anywhere for suspend/resume as it's not spinning. And it's context won't get lost and no reset is needed. And some power is saved. For kexec, things are trickier. If CPU1 is in some deeper power state, it will wake to the configured address and there's no way to reconfigure that AFAIK. So reset CPU1 reset is needed from that state. Note that HS omap4 implementations do seem to survive CPU1 off mode just fine. Andrew, does your use case really need kexec supported? If not, I think the sane thing for is to just disable kexec in the HS kernel for dra7 during runtime. And then if it turns out we really need to repark CPU1 for kexec into boot ROM, at least the following changes are needed: 1. We need to differentiate between suspend/resume and kexec for CPU1 hot-unplug so we can put CPU1 into retention for suspend/resume and park CPU1 for kexec 2. When parking CPU1 for kexec, it can be done in two stages. We can first park it to a loop waiting for flat memory mapping, then jump to boot ROM loop. But flat memory mapping is not enough we also need to remap boot ROM and L4.. Probably waiting for MMU off won't work here So depending on the use cases, I don't know if implementing these two are really needed or make sense. 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
