From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965340Ab3HHOLT (ORCPT ); Thu, 8 Aug 2013 10:11:19 -0400 Received: from mail-oa0-f41.google.com ([209.85.219.41]:50842 "EHLO mail-oa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965255Ab3HHOLP (ORCPT ); Thu, 8 Aug 2013 10:11:15 -0400 MIME-Version: 1.0 In-Reply-To: <1375970318.4276.52.camel@weser.hi.pengutronix.de> References: <52028719.8070908@wwwdotorg.org> <52029811.9080704@wwwdotorg.org> <1375970318.4276.52.camel@weser.hi.pengutronix.de> Date: Thu, 8 Aug 2013 19:41:13 +0530 Message-ID: Subject: Re: [PATCH 2/6] ARM: Tegra: Add CPU's OPPs for using cpufreq-cpu0 driver From: Viresh Kumar To: Lucas Stach Cc: Stephen Warren , Mark Rutland , "devicetree@vger.kernel.org" , linaro-kernel@lists.linaro.org, swarren@nvidia.com, Ian Campbell , Pawel Moll , linux-pm@vger.kernel.org, patches@linaro.org, linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org, rjw@sisk.pl, Rob Herring , 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 On 8 August 2013 19:28, Lucas Stach wrote: > From what I learned those voltage levels are dependent on both the > Speedo and the process ID of the specific Tegra processor. So you really > get a two dimensional mapping table instead of a single OPP. > Also you can not scale the CPU voltage on it's own, but have to make > sure the core voltage isn't too far away from. Then core voltage also > depends on the operating states of engines like GR2D or even display. So if they depend on a certain type of SoC, which they should, then we can get these initialized from that SoC's dts/dtsi file instead of a common file.. And so that would resolve the issue you just reported. Now I haven't proposed in the patch that we will change these voltage levels at all.. This is regulator specific code and would come into play only when regulators are registered for cpu.. Otherwise we will just play with frequency.. Passing OPP instead of just list of frequencies is the generic way this is done now a days.. From mboxrd@z Thu Jan 1 00:00:00 1970 From: viresh.kumar@linaro.org (Viresh Kumar) Date: Thu, 8 Aug 2013 19:41:13 +0530 Subject: [PATCH 2/6] ARM: Tegra: Add CPU's OPPs for using cpufreq-cpu0 driver In-Reply-To: <1375970318.4276.52.camel@weser.hi.pengutronix.de> References: <52028719.8070908@wwwdotorg.org> <52029811.9080704@wwwdotorg.org> <1375970318.4276.52.camel@weser.hi.pengutronix.de> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 8 August 2013 19:28, Lucas Stach wrote: > From what I learned those voltage levels are dependent on both the > Speedo and the process ID of the specific Tegra processor. So you really > get a two dimensional mapping table instead of a single OPP. > Also you can not scale the CPU voltage on it's own, but have to make > sure the core voltage isn't too far away from. Then core voltage also > depends on the operating states of engines like GR2D or even display. So if they depend on a certain type of SoC, which they should, then we can get these initialized from that SoC's dts/dtsi file instead of a common file.. And so that would resolve the issue you just reported. Now I haven't proposed in the patch that we will change these voltage levels at all.. This is regulator specific code and would come into play only when regulators are registered for cpu.. Otherwise we will just play with frequency.. Passing OPP instead of just list of frequencies is the generic way this is done now a days..