From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965317AbcBDMPn (ORCPT ); Thu, 4 Feb 2016 07:15:43 -0500 Received: from foss.arm.com ([217.140.101.70]:41153 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964837AbcBDMPl (ORCPT ); Thu, 4 Feb 2016 07:15:41 -0500 Date: Thu, 4 Feb 2016 12:16:20 +0000 From: Juri Lelli To: Vincent Guittot Cc: Morten Rasmussen , linux-kernel , "linux-pm@vger.kernel.org" , LAK , "devicetree@vger.kernel.org" , Peter Zijlstra , Rob Herring , Mark Rutland , Russell King - ARM Linux , Sudeep Holla , Lorenzo Pieralisi , Catalin Marinas , Will Deacon , Dietmar Eggemann , Mark Brown , "Rafael J. Wysocki" , Viresh Kumar Subject: Re: [PATCH v3 2/6] drivers/cpufreq: implement init_cpu_capacity_default() Message-ID: <20160204121620.GB29586@e106622-lin> References: <1454500799-18451-1-git-send-email-juri.lelli@arm.com> <1454500799-18451-3-git-send-email-juri.lelli@arm.com> <20160204093559.GA14099@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vincent, On 04/02/16 13:03, Vincent Guittot wrote: > On 4 February 2016 at 10:36, Morten Rasmussen wrote: > > On Wed, Feb 03, 2016 at 10:04:37PM +0100, Vincent Guittot wrote: > >> On 3 February 2016 at 12:59, Juri Lelli wrote: > > [snip] > > >> > diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile > >> > index 9e63fb1..c4025fd 100644 > >> > --- a/drivers/cpufreq/Makefile > >> > +++ b/drivers/cpufreq/Makefile > >> > @@ -1,5 +1,5 @@ > >> > # CPUfreq core > >> > -obj-$(CONFIG_CPU_FREQ) += cpufreq.o freq_table.o > >> > +obj-$(CONFIG_CPU_FREQ) += cpufreq.o freq_table.o cpufreq_capacity.o > >> > >> Do you really want to have the calibration of capacity dependent of > >> cpufreq ? It means that we can't use it without a cpufreq driver. > >> IMHO, this creates a unnecessary dependency. I understand that you > >> must ensure that core runs at max fequency if a driver is present but > >> you should be able to calibrate the capacity if cpufreq is not > >> available but you have different capacity because micro architecture > > > > We could remove the dependency on cpufreq, but it would make things more > > complicated for systems which do have frequency scaling as we would have > > to either: > > > > 1) Run the calibration again once cpufreq has been initialized. > > or wait and let time for a driver to initialize and trig the > calibration. If calibration has not been done at the end of the boot, > you can force a calibration. If the cpufeq driver is a module and is > loaded far later for any good or bad reason, we will have to run the > calibration once again but at least the capacity will reflect he > current capacity of the CPUs. > I'm mainly worried that the compilation of the calibration is > dependent of CONFIG_CPU_FREQ not that cpufreq can trig the calibration > sequence > Yes, I guess we can make this work in some way. Out of curiosity, though, are out there heterogenous platforms that don't use cpufreq? I mean, I wouldn't add code and complexity from start, if there are not good reasons to do so. Thanks, - Juri