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

[Russell King - ARM Linux <linux@armlinux.org.uk>]

On Wed, Apr 11, 2018 at 07:11:39AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@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@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.

In which case, how about using:

	while (1) {
		cpu_relax();
		wfe();
	}

instead - that appears to also have the desired effect, allowing kdump
to work on the SDP4430.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up