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

Tony Lindgren tony at atomide.com
Wed Apr 11 07:11:39 PDT 2018


* Russell King - ARM Linux <linux at armlinux.org.uk> [180411 12:53]:
> 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.

We already have code in the kernel (and in the bootrom) to "park" a
cpu after starting. But using it without resetting the cpu would require
1-1 memory mapping or modifying the code. That is if we wanted to use
the same code also for parking the cpus for kexec without resetting
them.

Regards,

Tony



More information about the linux-arm-kernel mailing list