Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936067AbdGTOpj (ORCPT ); Thu, 20 Jul 2017 10:45:39 -0400 Received: from merlin.infradead.org ([205.233.59.134]:53396 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934805AbdGTOph (ORCPT ); Thu, 20 Jul 2017 10:45:37 -0400 Date: Thu, 20 Jul 2017 16:45:30 +0200 From: Peter Zijlstra To: "Rafael J. Wysocki" Cc: Viresh Kumar , Florian Fainelli , Linux Kernel Mailing List , Linux PM , "Rafael J. Wysocki" , Markus Mayer , Daniel Lezcano Subject: Re: cpuidle and cpufreq coupling? Message-ID: <20170720144530.da6bqpdvt2cvbjjs@hirez.programming.kicks-ass.net> References: <20170720071846.GK352@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1454 Lines: 29 On Thu, Jul 20, 2017 at 11:52:41AM +0200, Rafael J. Wysocki wrote: > On Thu, Jul 20, 2017 at 9:18 AM, Viresh Kumar wrote: > > On 20-07-17, 01:17, Rafael J. Wysocki wrote: > >> On Thu, Jul 20, 2017 at 12:54 AM, Florian Fainelli wrote: > >> > Hi, > >> > > >> > We have a particular ARM CPU design that is drawing quite a lot of > >> > current upon exit from WFI, and it does so in a way even before the > >> > first instruction out of WFI is executed. That means we cannot influence > >> > directly the exit from WFI other than by changing the state in which it > >> > would be previously entered because of this "dead" time during which the > >> > internal logic needs to ramp up back where it left. > >> > > >> > A naive approach to solving this problem because we have CPU frequency > >> > scaling available would be to do the following: > >> > > >> > - just before entering WFI, switch to a low frequency OPP > >> > - enter WFI > >> > - upon exit from WFI, ramp up the frequency back to e.g: highest OPP > >> > > >> > Some of the parts that I am not exactly clear on would be: > >> > > >> > - would that qualify as a cpuidle governor of some kind that ties in > >> > which cpufreq? > >> > - would using cpufreq_driver_fast_switch() be an appropriate API to use > >> > from outside Can your ARM part change OPP without scheduling? Because (for obvious reasons) the idle thread is not supposed to block.