* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [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@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. 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 -- 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
