From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lukasz Majewski Subject: Re: [PATCH v3 1/2] cpufreq / OPP: Allow boost frequency to be looked up from device tree Date: Wed, 14 May 2014 08:09:30 +0200 Message-ID: <20140514080930.781e0557@amdc2363> References: <1400029380-5372-1-git-send-email-thomas.ab@samsung.com> <1400029380-5372-2-git-send-email-thomas.ab@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-reply-to: Sender: linux-samsung-soc-owner@vger.kernel.org To: Nishanth Menon , Viresh Kumar , Thomas Abraham Cc: "Rafael J. Wysocki" , Rob Herring , "devicetree@vger.kernel.org" , linux-samsung-soc , "linux-pm@vger.kernel.org" , Tomasz Figa , Kukjin Kim , Thomas P Abraham , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org Hi Nishanth, Viresh If I may add my 2 cents. > On Tue, May 13, 2014 at 10:40 PM, Viresh Kumar > wrote: > > On 14 May 2014 06:32, Thomas Abraham wrote: > [...] > >> +#ifdef CONFIG_CPU_FREQ_BOOST_SW > >> + if (of_find_property(dev->of_node, "boost-frequency", > >> &len)) { > > > > Does this mean another block inside the cpu node ? Like this: ? > > > > cpu@0 { > > compatible = "arm,cortex-a9"; > > reg = <0>; > > next-level-cache = <&L2>; > > operating-points = < > > /* kHz uV */ > > 792000 1100000 > > 396000 950000 > > 198000 850000 > > >; > > boost-frequency = < > > 792000 > > 198000 > > >; I think that the above approach is more appealing [*]. > > }; > > > > I think it we might better add another field in the opp block as > > these OPPs are rather boost one.. > > If we change the meaning to be: > operating-points = < > /* kHz uV boost? */ > 792000 1100000 1 > 396000 950000 0 > > We are adding a modifier to the OPP definition here and does imply > every platform which may or maynot require "boost" need to indicate > that - basically fails at least my "least common" description for a > generic definition. As I had indicated in other threads -> we are back > to the discussion of "additional properties" to an OPP.. > Option 1: > - describe modifiers separately (as in boost-frequencies) - that > operate based on data from opp table. > Option 2: > - keep adding to the description of opp as time goes by - every SoC > has it's own set of quirks that are needed for an OPP - I know that at > TI, we have certain OPPs that can only be enabled *if* "custom > hardware driver" is enabled, and similar stories. - yet another > example is enable the OPP if efuse X, bit Y is set. > > Personally, looking at the various descriptions and bL, cpu-idle > states dependencies on OPPs, etc.. Option 2 is a non-scalable > approach. I agree with Nishanth here, that point 1 (as described by Viresh at [*]) is a more scalable approach. > > [...] -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group