Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752780Ab3E0Fdl (ORCPT ); Mon, 27 May 2013 01:33:41 -0400 Received: from mail-oa0-f51.google.com ([209.85.219.51]:33117 "EHLO mail-oa0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751875Ab3E0Fdj (ORCPT ); Mon, 27 May 2013 01:33:39 -0400 MIME-Version: 1.0 In-Reply-To: <20130524132036.7e7d5ffe@amdc308.digital.local> References: <1367590072-10496-1-git-send-email-jonghwa3.lee@samsung.com> <20130522122700.104ca5cd@amdc308.digital.local> <20130522164453.29cd3a7d@amdc308.digital.local> <20130524075640.0a5b80ff@amdc308.digital.local> <20130524103007.7bb206ee@amdc308.digital.local> <20130524132036.7e7d5ffe@amdc308.digital.local> Date: Mon, 27 May 2013 11:03:38 +0530 Message-ID: Subject: Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results From: Viresh Kumar To: Lukasz Majewski Cc: Jonghwa Lee , "Rafael J. Wysocky" , linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org, Vicent Guittot , Daniel Lezcano , MyungJoo Ham , Lukasz Majewski Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2116 Lines: 51 On 24 May 2013 16:50, Lukasz Majewski wrote: >> On 24 May 2013 14:00, Lukasz Majewski wrote: > This is not safe IMHO to add permanently overclocked frequency to the > freq table. Since, for example, thermal framework also asks for > reference to this table. Yes, its wrong. Even adding it permanently this way would be a problem if governor is changed to performance. :) > The idea beneath overclocking is to add "dangerous" frequency to the > frequency table only when necessary (and remove it when not needed). Hmm.. probably the idea beneath is to use dangerous frequency only when we are assured that we will not break system.. It doesn't have anything to do with cpufreq table entries :) > In this way, the thermal framework (as it is done at our platform) will > decrease the frequency (according to thermal governor :-) ) to safe > level. > > Overclocking is disabled in 2 ways (at our setup): > - thermal framework is here to help us > - lab governor disables the overclocking when favorable conditions are > gone. I don't want to discuss OR think about LAB for now.. Want to get overclocking feature in first. > One more remark - enabling tb_en_over_clk at sysfs (echo 1 >> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk) > adds overclock frequency to frequency table and updates policy. What if it is enabled and governor is changed to performance without disabling it... Who will take care of disabling dangerous frequencies? One thing I am certain about is to make overclocking a generic and core feature, rather than platform specific... What about adding overdrive frequencies in freq table permanently but with .index field as: CPUFREQ_ENTRY_OVERDRIVE ?? This way we will use frequencies marked with CPUFREQ_ENTRY_OVERDRIVE only when we have overclocking enabled. And not at other times? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/