[PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot

[Tony Lindgren]

* Andrew F. Davis <afd at ti.com> [170217 12:28]:
> On 02/17/2017 09:55 AM, Tony Lindgren wrote:
> > * Tony Lindgren <tony at atomide.com> [170216 11:08]:
> >> * Tony Lindgren <tony at atomide.com> [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