Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752543AbdGLEJW (ORCPT ); Wed, 12 Jul 2017 00:09:22 -0400 Received: from mail-pg0-f42.google.com ([74.125.83.42]:35218 "EHLO mail-pg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751055AbdGLEJU (ORCPT ); Wed, 12 Jul 2017 00:09:20 -0400 Date: Wed, 12 Jul 2017 09:39:17 +0530 From: Viresh Kumar To: Dietmar Eggemann Cc: "Rafael J. Wysocki" , Peter Zijlstra , "Rafael J. Wysocki" , Linux Kernel Mailing List , Linux PM , Russell King - ARM Linux , Greg Kroah-Hartman , Russell King , Catalin Marinas , Will Deacon , Juri Lelli , Vincent Guittot , Morten Rasmussen Subject: Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support Message-ID: <20170712040917.GG17115@vireshk-i7> References: <20170706094948.8779-1-dietmar.eggemann@arm.com> <22f004af-0158-8265-2da5-34743f294bfb@arm.com> <12829054.TWIodSo4bb@aspire.rjw.lan> <20170711060106.GL2928@vireshk-i7> <45224055-7bf1-243b-9366-0f2d3442ef59@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45224055-7bf1-243b-9366-0f2d3442ef59@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1264 Lines: 26 On 11-07-17, 16:06, Dietmar Eggemann wrote: > But in the meantime we're convinced that cpufreq_driver_fast_switch() is > not the right place to call arch_set_freq_scale() since for (future) > arm/arm64 fast-switch driver, the return value of > cpufreq_driver->fast_switch() does not give us the information that the > frequency value did actually change. Yeah, I saw your discussion with Peter on #linux-rt IRC and TBH I wasn't aware that we are going to do fast switching that way. Just trying to get understanding of that idea a bit.. So we will do fast switching from scheduler's point of view, i.e. we wouldn't schedule a kthread to change the frequency. But the real hardware still can't do that without sleeping, like if we have I2C somewhere in between. AFAIU, we will still have some kind of *software* bottom half to do that work, isn't it? And it wouldn't be that we have pushed some instructions to the hardware, which it can do a bit later. For example, the regulator may be accessed via I2C and we need to program that before changing the clock. So, it will be done by some software code only. And now I am wondering on why that would be any better than the kthread in schedutil. Sorry, I haven't understood the idea completely yet :( -- viresh