From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752319AbdEHFhE (ORCPT ); Mon, 8 May 2017 01:37:04 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:52560 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751375AbdEHFhC (ORCPT ); Mon, 8 May 2017 01:37:02 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org B26CD606DC Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=rnayak@codeaurora.org Subject: Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property To: Viresh Kumar , Kevin Hilman References: <025acedb263eaa6089d354d9630214ada8013990.1493203884.git.viresh.kumar@linaro.org> <20170428204803.plu467okibtxga4d@rob-hp-laptop> <20170508041511.GB17010@vireshk-i7> Cc: Rob Herring , Rafael Wysocki , ulf.hansson@linaro.org, Viresh Kumar , Nishanth Menon , Stephen Boyd , linaro-kernel@lists.linaro.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Vincent Guittot , lina.iyer@linaro.org, sudeep.holla@arm.com, devicetree@vger.kernel.org From: Rajendra Nayak Message-ID: Date: Mon, 8 May 2017 11:06:54 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170508041511.GB17010@vireshk-i7> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/08/2017 09:45 AM, Viresh Kumar wrote: > On 06-05-17, 11:58, Kevin Hilman wrote: >> Rob Herring writes: >> >>> On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote: >>>> Power-domains need to express their active states in DT and the devices >>>> within the power-domain need to express their dependency on those active >>>> states. The power-domains can use the OPP tables without any >>>> modifications to the bindings. >>>> >>>> Add a new property "power-domain-opp", which will contain phandle to the >>>> OPP node of the parent power domain. This is required for devices which >>>> have dependency on the configured active state of the power domain for >>>> their working. >>>> >>>> For some platforms the actual frequency and voltages of the power >>>> domains are managed by the firmware and are so hidden from the high >>>> level operating system. The "opp-hz" property is relaxed a bit to >>>> contain indexes instead of actual frequency values to support such >>>> platforms. >>>> >>>> Signed-off-by: Viresh Kumar >>>> --- >>>> Documentation/devicetree/bindings/opp/opp.txt | 74 ++++++++++++++++++++++++++- >>>> 1 file changed, 73 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt >>>> index 63725498bd20..6e30cae2a936 100644 >>>> --- a/Documentation/devicetree/bindings/opp/opp.txt >>>> +++ b/Documentation/devicetree/bindings/opp/opp.txt >>>> @@ -77,7 +77,10 @@ This defines voltage-current-frequency combinations along with other related >>>> properties. >>>> >>>> Required properties: >>>> -- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. >>>> +- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer. In some >>>> + cases the exact frequency in Hz may be hidden from the OS by the firmware and >>>> + this field may contain values that represent the frequency in a firmware >>>> + dependent way, for example an index of an array in the firmware. >>> >>> Not really sure OPP binding makes sense here. >> >> I think OPP makes perfect sense here, because microcontroller firmware >> is managaging OPPs in hardware. We just may not know the exact voltage >> and/or frequency (and the firmware/hardware may even be doing AVS for >> micro-adjustments.) > > Yes, AVS is being done for the Qcom SoC as well. > >>> What about all the other properties. We expose voltage, but not freq? >> >> I had the same question. Seems the same comment about an abstract >> "index" is needed for voltage also. > > Why should we do that? Here are the cases that I had in mind while writing this: > > - DT only contains the performance-index and nothing else (i.e. voltages aren't > exposed). > > We wouldn't be required to fill the microvolt property as it is optional. So the performance-index is specified in opp-hz property? What if the microcontroller firmware maps the performance-index to voltage but expects linux to scale the frequency? There is no way to specify a performance-index *and* a frequency for a OPP now I guess? > > - DT contains both performance-index and voltages. > > The microvolts property will contain the actual voltages and opp-hz will > contain the index. So this is for cases where the performance-index maps to a freq managed by the microcontroller and voltages managed by linux? I have a case of exact opposite and I don't see now how to handle it now with these bindings. > > I don't see why would we like to put some index value in the microvolts > property. We are setting the index value in the opp-hz property to avoid adding > extra fields and making sure opp-hz is still the unique property for the nodes. Maybe to handle the case like what I described above? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation