On Wednesday 11 April 2018 06:22 PM, Russell King - ARM Linux wrote: > 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. Yes. If the ondemand governor detects that CPU was busy greater than 80% of the time it bumps to the highest OPP and can lead to higher temperatures though CPU might not be doing anything useful. > -- 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
