[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fe4b60f9-8aa6-0173-a67f-2f0f8451ad85@codeaurora.org>
Date: Wed, 29 Apr 2020 19:45:27 +0530
From: Rajendra Nayak <rnayak@...eaurora.org>
To: Matthias Kaehlcke <mka@...omium.org>
Cc: viresh.kumar@...aro.org, sboyd@...nel.org,
bjorn.andersson@...aro.org, agross@...nel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH v3 03/17] arm64: dts: sdm845: Add OPP table for all qup
devices
On 4/29/2020 5:32 AM, Matthias Kaehlcke wrote:
> Hi Rajendra,
>
> On Tue, Apr 28, 2020 at 07:02:51PM +0530, Rajendra Nayak wrote:
>> qup has a requirement to vote on the performance state of the CX domain
>> in sdm845 devices. Add OPP tables for these and also add power-domains
>> property for all qup instances.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@...eaurora.org>
>> Signed-off-by: Stephen Boyd <swboyd@...omium.org>
>> ---
>> arch/arm64/boot/dts/qcom/sdm845.dtsi | 115 +++++++++++++++++++++++++++++++++++
>> 1 file changed, 115 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> index 8f926b5..36b9fb1 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
>> @@ -804,6 +804,25 @@
>> clock-names = "core";
>> };
>>
>> + qup_opp_table: qup-opp-table {
>> + compatible = "operating-points-v2";
>> +
>> + opp-19200000 {
>> + opp-hz = /bits/ 64 <19200000>;
>> + required-opps = <&rpmhpd_opp_min_svs>;
>> + };
>> +
>> + opp-75000000 {
>> + opp-hz = /bits/ 64 <75000000>;
>> + required-opps = <&rpmhpd_opp_low_svs>;
>> + };
>> +
>> + opp-100000000 {
>> + opp-hz = /bits/ 64 <100000000>;
>> + required-opps = <&rpmhpd_opp_svs>;
>> + };
>> + };
>> +
>
> Judging from SDM845 (which has more OPP tables) the convention seems to be
> to add OPP tables to the nodes that use them, which seems reasonable and
> keeps them out of the device list.
>
> Unfortunately this convention isn't completely suitable for cases like this
> (and the DSI OPPs later in this series), where the same OPP table is used by
> multiple devices. A possible compromise would be to add the table to the
> node of the first device that uses them.
Sounds fair, I will do that and respin. Thanks.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists