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@xxxxxxxxxxxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
