[PATCH] ARM: avoid Cortex-A9 livelock on tight dmb loops

[Keerthy]

On Wednesday 11 April 2018 06:22 PM, Russell King - ARM Linux wrote:
> On Tue, Apr 10, 2018 at 05:12:37PM +0300, Tero Kristo wrote:
>> On 10/04/18 16:41, Tony Lindgren wrote:
>>> * Russell King <rmk+kernel at armlinux.org.uk> [180410 10:43]:
>>>> diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
>>>> index 021b5a8b9c0a..d4ddc78b2a0b 100644
>>>> --- a/arch/arm/mach-omap2/prm_common.c
>>>> +++ b/arch/arm/mach-omap2/prm_common.c
>>>> @@ -523,7 +523,7 @@ void omap_prm_reset_system(void)
>>>>  	prm_ll_data->reset_system();
>>>>  	while (1)
>>>> -		cpu_relax();
>>>> +		cpu_do_idle();
>>>>  }
>>>
>>> Hmm we need to check so the added WFI here does not cause an
>>> undesired change to a low power state. Adding Tero to Cc also.
>>
>> Generally it is a bad idea to call arbitrary WFI within OMAP architecture,
>> as this triggers a PRCM power transition and will most likely cause a hang
>> if not controlled properly.
>>
>> Has this patch been tested on any platform that supports proper power
>> management?
> 
> That will also go for the other locations in this patch too, as they
> are all callable on _any_ platform.
> 
> It sounds like we need to abstract this so that platforms where "wfi"
> is complex can handle the "spin on this CPU forever" appropriately.
> 
> While we could use dsb, we're asking a CPU to indefinitely spin in a
> tight loop, which isn't going to be good for power consumption - what
> if we have three CPUs doing that, could it push a SoC over the thermal
> limits?  I don't think that's a question we can confidently answer
> except for specific SoCs.

Yes. If the ondemand governor detects that CPU was busy greater than
80% of the time it bumps to the highest OPP and can lead to higher
temperatures though CPU might not be doing anything useful.

>