From mboxrd@z Thu Jan 1 00:00:00 1970 From: Russell King - ARM Linux Subject: Re: [PATCH] ARM: avoid Cortex-A9 livelock on tight dmb loops Date: Wed, 11 Apr 2018 13:52:11 +0100 Message-ID: <20180411125210.GF10990@n2100.armlinux.org.uk> References: <20180410134149.GQ5700@atomide.com> <685f80e3-30b3-8806-b81c-8de456507001@ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <685f80e3-30b3-8806-b81c-8de456507001@ti.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Tero Kristo Cc: Paul Walmsley , Rajendra Nayak , Tony Lindgren , Will Deacon , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-omap@vger.kernel.org On Tue, Apr 10, 2018 at 05:12:37PM +0300, Tero Kristo wrote: > On 10/04/18 16:41, Tony Lindgren wrote: > >* Russell King [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. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: linux@armlinux.org.uk (Russell King - ARM Linux) Date: Wed, 11 Apr 2018 13:52:11 +0100 Subject: [PATCH] ARM: avoid Cortex-A9 livelock on tight dmb loops In-Reply-To: <685f80e3-30b3-8806-b81c-8de456507001@ti.com> References: <20180410134149.GQ5700@atomide.com> <685f80e3-30b3-8806-b81c-8de456507001@ti.com> Message-ID: <20180411125210.GF10990@n2100.armlinux.org.uk> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Apr 10, 2018 at 05:12:37PM +0300, Tero Kristo wrote: > On 10/04/18 16:41, Tony Lindgren wrote: > >* Russell King [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. -- 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