linux-kernel - Re: [PATCH v3 03/17] arm64: dts: sdm845: Add OPP table for all qup devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cc425e51-9e27-76a3-8ce6-1a751960ff7a@codeaurora.org>
Date:   Wed, 29 Apr 2020 20:23:30 +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 7:45 PM, Rajendra Nayak wrote:
> 
> 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.

Looking into this some more, I see we do have..

static const struct of_device_id of_skipped_node_table[] = {
         { .compatible = "operating-points-v2", },
         {} /* Empty terminated list */
};

..in drivers/of/platform.c, so its not being added to the device list.

And atleast in case of qup, I am having to duplicate the OPP tables once for
each qup instance. Not to mention, having them inside the first qup device
just makes it a little confusing to read who the OPP table belongs to.

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation