Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965930Ab3HHPxR (ORCPT ); Thu, 8 Aug 2013 11:53:17 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:57182 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965376Ab3HHPw7 (ORCPT ); Thu, 8 Aug 2013 11:52:59 -0400 MIME-Version: 1.0 In-Reply-To: References: <52028719.8070908@wwwdotorg.org> <52029811.9080704@wwwdotorg.org> <1375970318.4276.52.camel@weser.hi.pengutronix.de> <1375971749.4276.61.camel@weser.hi.pengutronix.de> Date: Thu, 8 Aug 2013 10:52:57 -0500 X-Google-Sender-Auth: _ew_B8FrZa-sI_14bAWtqVcNbYA Message-ID: Subject: Re: [PATCH 2/6] ARM: Tegra: Add CPU's OPPs for using cpufreq-cpu0 driver From: Nishanth Menon To: Viresh Kumar Cc: Lucas Stach , Mark Rutland , "devicetree@vger.kernel.org" , linaro-kernel@lists.linaro.org, swarren@nvidia.com, Ian Campbell , Pawel Moll , Stephen Warren , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org, rjw@sisk.pl, Rob Herring , patches@linaro.org, mturquette@linaro.org, linux-arm-kernel@lists.infradead.org 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: 1490 Lines: 33 On Thu, Aug 8, 2013 at 9:37 AM, Viresh Kumar wrote: > On 8 August 2013 19:52, Lucas Stach wrote: >> You can certainly define the mapping table in DT where a specialized >> Tegra cpufreq driver could read it in and then map frequency to voltage. >> But that's a runtime decision, as Speedo and process ID are fuse values >> and can not be represented in DT. > >> The problem with this is that the hardware description now associates >> voltages with certain frequencies and even if they are not used by the >> Linux driver they are plain wrong. > > Hmm. I understand. > Then we probably need mach-tegra/opp.c to call opp_add() for all such > OPPs.. Neither DT nor cpufreq driver are the right place for this. This is similar to what I suspected might be the case on other platforms (in addition to known iMx and OMAP). Could you see/comment on [1] to see if it meets your needs. We should like to avoid dealing custom SoC specific OPP, if we are able to generalize the need. ofcourse, I am yet to submit a official proposal, but more SoCs the current proposal can handle, the better it will be for all of us. [1] http://marc.info/?l=linux-pm&m=137589225305971&w=2 -- Regards, Nishanth Menon -- 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/