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

Andrew F. Davis afd at ti.com
Fri Feb 17 12:27:07 PST 2017


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.

[...]

> +
> +	/* 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



More information about the linux-arm-kernel mailing list