From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754935Ab3BDNEP (ORCPT ); Mon, 4 Feb 2013 08:04:15 -0500 Received: from mail.skyhub.de ([78.46.96.112]:53976 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753996Ab3BDNEN (ORCPT ); Mon, 4 Feb 2013 08:04:13 -0500 Date: Mon, 4 Feb 2013 14:04:03 +0100 From: Borislav Petkov To: Viresh Kumar Cc: "Rafael J. Wysocki" , cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org, robin.randhawa@arm.com, Steve.Bannister@arm.com, Liviu.Dudau@arm.com Subject: Re: [PATCH 0/4] CPUFreq: Implement per policy instances of governors Message-ID: <20130204130403.GD13909@pd.tnic> Mail-Followup-To: Borislav Petkov , Viresh Kumar , "Rafael J. Wysocki" , cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, linaro-dev@lists.linaro.org, robin.randhawa@arm.com, Steve.Bannister@arm.com, Liviu.Dudau@arm.com References: <5808458.pvV2iHpBWm@vostro.rjw.lan> <20130204123221.GA22340@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 On Mon, Feb 04, 2013 at 06:24:19PM +0530, Viresh Kumar wrote: > That's why i am highlighting it again and again. :) Ah, see, someone caught up with it :). > What i believe is, the place where this directory was present earlier > (cpu/cpufreq/) wasn't the right place. Everything else was in cpu/cpu*/cpufreq, > then why this in cpu/cpufreq/ ? For the simple reason that the "cpu*" stuff is per-cpu - the "cpu/cpufreq" is per system, i.e. one governor for the whole system. > I don't know how much of a pain it would be to fix userspace for it, > but i know it wouldn't be that small. I wouldn't fix userspace but simply not touch it. You can add your per-policy stuff in "cpu/cpu*" as new sysfs nodes and no need to change anything. And, also, as I suggested earlier, you should make it configurable since this code wouldn't make sense on x86, for example, where one system-wide governor should suffice. > I had another idea of doing this only for platforms where we have > multiple struct policy alive at the same time. But didn't wanted to > implement it before discussing this further. Simply put it behind a config option like CONFIG_CPU_IDLE_MULTIPLE_DRIVERS, call the whole menu "Multi-power-domain-policy" something and that should be modulary enough. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. --